Is this expected behaviour of traceroute in VPN tunnel?

Simple site-to-site VPN configured, no GRE/DMVPN/EasyVPN.

 

<protected subnet 10.10.0.0/24> ---- 10.10.0.1:GW1:1.2.3.4<--WAN-->5.6.7.8:GW2:10.20.20.1 --<protected network 10.20.20.0/24>

The interesting traffic to be protected is between 10.10.0.0/24 and 10.20.20.0/24.

The tunnel is setup and working, and hosts on the subnets can access each other.

Now using Windows traceroute (ICMP based?) - a PC, 10.10.0.2, does a  traceroute to 10.20.20.1

(which is the interface of GW2 on the other protected subnet)

!!Case 1

1. 3ms 3ms 3ms 10.10.0.1

2. 3ms 3ms 3ms 10.20.20.1

This behaves exactly like a non-VPN situation and shows 2 hops to the destination.

However if I traceroute to a host on the other protected subnet (i.e. not GW2's protected interface):

!!Case 2

1. 3ms 3ms 3ms 10.10.0.1

2. * * * timeout

3. 3ms 3ms 3ms 10.20.20.10

Note that the traceroute "succeeds" and shows 3 hops to destination (as one would expect).

My question is why does the 2nd hop (i.e. the other gateway/tunnel endpoint) timeout, more precisely,

I certainly wouldn't expect it to reveal it's public addresses, but why doesn't it discern a 2nd hop node of 10.20.20.1

that it did  in the 2-hop Case 1?

 

 

 

 

Sign In or Register to comment.