Re: Unexpected traceroute output over VPN
- From: "VeeDub" <veedubius@xxxxxxxxxxx>
- Date: 1 Nov 2006 17:28:37 -0800
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 IPThis 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
.
- References:
- Unexpected traceroute output over VPN
- From: VeeDub
- Re: Unexpected traceroute output over VPN
- From: CK
- Unexpected traceroute output over VPN
- Prev by Date: Re: hardware firewall buying
- Next by Date: Re: hardware firewall buying
- Previous by thread: Re: Unexpected traceroute output over VPN
- Next by thread: WRT54GL throughput/connenction capability
- Index(es):
Relevant Pages
|
