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?
LVL 1
evaultAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Hardware Firewalls

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.