Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 551
  • Last Modified:

VPN gives two different types of IPs

I have two sites PDX and AST connected by a S2S VPN, Juniper at PDX and NetGear at AST. Both sites says the VPN connecttion is active. When I log into a PC on the AST network and ping a PC on the PDX LAN i get a response. When I do a tracert from the same two machines, I get  two hops: 192.168.3.1 (AST gateway) and 192.168.4.1 (PDX Gateway).
When I ping from a PC on PDX LAN to a PC on the AST LAN, I get
reply from 76.139.77.52 (fictitious)  destination host unreachable. When I do a tracert fom the same PDX LAN PC to the same AST LAN PC it GOES TO THE INTERNET (public IP addresses) at stops at 76.139.77.52.
Three questions (in order of importance)
What is the likely cause of this?
Why do I get Private IP addresses when I tracert from AST to PDX?
Why would the VPN say it is up at both ends and yet I am not able to  ping internally from PDX to AST?
0
evault
Asked:
evault
  • 3
2 Solutions
 
evaultAuthor Commented:
By the way, there are three telcos involved in this, Vendor1 which provides service at PDX, Vendor2 which provides service at AST and Vendor3 which provides connectivity between the two other vendors. Vendors 1 & 2 both claim their network are delivering the packets sucessfully as far as their borders.
0
 
Sanga CollinsSystems AdminCommented:
This definitely sunds like a missing route statement is the cause of the issue. In the juniper do you have a route defined that implicitly says traffic for ip 192.168.3.0/24 should go out through VPN tunnel?
0
 
QlemoC++ DeveloperCommented:
The difference for whether you initiate traffic from AST -> PDX or PDX -> AST is that in the first case the session object already exists for the ICMP reply in the first case.
That is:
* traffic originates from AST,
* passes the VPN tunnel,
* arrives at the Juniper (and a corresponding session object is created).
When the reply from PDX is sent, the session object is used as a shortcut - no routes or policies to check. So it will pass.

The other way the session object does not yet exist, so routes and policies need to be checked. And obviously there is a route or policy taking precedence, forwarding the packet to public interface instead of passing it thru a tunnel.

Without seeing the config (or the relevant part of it, at least), that is all we can guess about.
A simple test is if you allow traffic logging for the VPN policy PDX -> AST. If you see traffic, the policy is hit, and can be excempt from being the culprit.
0
 
evaultAuthor Commented:
Thank you both. Each of you have some merit to your suggestions. I will check both and get back to you.
0
 
evaultAuthor Commented:
Replaced the Juniper/NetGear firewalls with two SonicWALL units and everything is working just fine.
0

Featured Post

Who's Defending Your Organization from Threats?

Protecting against advanced threats requires an IT dream team – a well-oiled machine of people and solutions working together to defend your organization. Download our resource kit today to learn more about the tools you need to build you IT Dream Team!

  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now