Unexpected traceroute output over VPN
am 01.11.2006 14:58:44 von VeeDub
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
Re: Unexpected traceroute output over VPN
am 01.11.2006 20:39:48 von NETADMIN
> Local IP --> Local Internal Gateway --> Destination IP
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
> 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.
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:
> 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
Re: Unexpected traceroute output over VPN
am 02.11.2006 02:28:37 von VeeDub
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:
> > Local IP --> Local Internal Gateway --> Destination IP
> 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
>
> > 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.
>
> 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:
> > 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