Unexpected traceroute output over VPN

Hi

I have a VPN created between two Netscreen 5GT firewalls. Out of interest, I performed some traceroutes between clients on the private networks on either side of the VPN tunnel. I was expecting to get output identical to that I would have received if the destination IP was on a different subnet divided by a local router as below:

Local IP --> Local Internal Gateway --> Destination IP

I am however getting the following:

Local IP --> Local Internal Gateway --> Public Interface of Remote Firewall --> Destination IP

The details of the output are below:

C:\\Documents and Settings\\administrator>ipconfig

Windows IP Configuration

Ethernet adapter Wireless Network Connection:

Connection-specific DNS Suffix . : home.local IP Address. . . . . . . . . . . . : 10.100.100.100 Subnet Mask . . . . . . . . . . . : 255.255.255.0 Default Gateway . . . . . . . . . : 10.100.100.1

C:\\Documents and Settings\\administrator>tracert 192.168.1.14

Tracing route to 192.168.1.14 over a maximum of 30 hops

1 13 ms 6 ms 7 ms 10.100.100.1 2 46 ms 46 ms 46 ms x.x.233.220.exetel.com.au [220.233.x.x] 3 47 ms 43 ms 47 ms 192.168.1.14

Trace complete.

Can anyone tell me why this is. I was under the assumption that the VPN encapsulation of the ICMP traffic would make it obvlious to any of the public internet routing occuring and it would not see the public IP of the remote firewall as it would not be until it was inside the firewall that it would be unencapsulated. This also makes me think that possibly the traffic is not being fully encrypted throughout its entire travel.

Thanks

Reply to
VeeDub
Loading thread data ...

This is not VPN Working.Site ti Site vpn work s on Tunnel End points that is gateway firewalls or gateway VPN Devices.Like Local IP --> Local Internal Gateway --> Destination Gateway -->

Destination IP

Its becasue in Site to Site VPN Tunneling Secure IPSEC works after completion of IPSEC Phase-2. After completion both networks are on same path and secure with encryption method used for VPN Tunneling.After Completion of phase - 2 of VPN every packet leaving outside interface of Firewall will get the WAN NAT IP automatically searching for next VPN Hope at default route.

Ck

VeeDub wrote:

Reply to
CK

Thanks CK

sorry though, your response makes little sense to me.

I am aware that the packet will go from the local machine, to the local gateway, to the remote gateway and then to the destination IP.

However, in terms of traceroute output, as the ICMP packet is encapsulated/encrypted once it enters the inside interface of the local gateway but before it leaves the outside interface and then unencapsulated/unencrypted after it enters the outside interface of the remote gateway but before it leaves the inside interface it should not be aware of the IP addresses of any devices between and including the outside interfaces of each VPN end-point.

Because of this, my impression is that the traceroute responses should only reflect the hops in which the ICMP packet is actually in an unencapsulated state, ie not while traversing the VPN.

The reason why I am suprised the IP address of the remote gateway is in the traceroute output is two-fold. One - It is represented by the outside/public interface, which the ICMP packet should still be encrypted when going through this so it should not be aware of this interface. Two - as the ICMP packet should really only see the local gateway inside interface and remote gateway inside interface, it presumes that these interfaces are both members of the same router, and just like when a traceroute is performed on a LAN divided by routers, the output does not show the entrance and exit interface IP of each router along a path, it only shows the entrance interface IP of each hop.

So basically, while I know the packets goes from local source to local gateway to remote gateway to destination (and many invisible hops in between along the VPN) I still expected to get a traceroute output like this:

C:\\Documents and Settings\\administrator>tracert 192.168.1.14

Tracing route to 192.168.1.14 over a maximum of 30 hops

1 13 ms 6 ms 7 ms 10.100.100.1 3 47 ms 43 ms 47 ms 192.168.1.14

Trace complete.

I am still not sure why I am not getting this?

Thanks

CK wrote:

Reply to
VeeDub

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.