Hi all,
over a speedfusion PEPVPN connection between peplink devices (Site to Site), if I do a traceroute:
First hop is the gateway IP on peplink
second hop shows up as unresponsive/asterisk
third hop is the gateway IP of the other side peplink
Is there a way to remove unresponsive hops for traceroute/mtr, or make them respond? Or should they show up in tracert, but not respond to tracert, because of how vpn tunnels work?
This is normal.
There are hidden PepVPN interfaces your traffic passes through when using the PepVPN /SpeedFusion tunnel.
The router needs to know what they are so it can use them when you send traffic over the tunnels, but you don’t want those interfaces advertised anywhere else otherwise they could clash with other user defined subnets.
Without advertisement there can be no response to tracert / ping.
Hi Martin,
thank you for your explanation. is there a way to show the second hop? like using ip loopback? or is there a way to hide the second hop?
No there is not. We can’t show it or hide it because it is there in the path but we don’t want it routable in the user context, its just needed in the speedfusion / pepvpn context.
1 Like
Hi Marthin,
Thank you for your explanation.
I had this same concern – I can live with it, but it does make the tracert tool on windows less usable.
Also new cloud and server providers are starting to do similar things where there are sometimes 2 or several hops in a tracert that now show *** which makes especially windows tracert worse because it does the hops sequentially which slows it down dramatically to have so many * hops.
I don’t think tunnels will go away so I’m not sure what this is to say, other than the traditional tools like tracert and mtr, etc. now can’t show a route with tunnels involved so they show you “something unknown” is there in an increasing frequency whereas once-upon-a-time routing was simpler in terms of traceroute.
Is there a better tool to use on a windows machine than tracert in this modern era that is available on any machine you are troubleshooting? That would be ideal.
I’m not sure that its a big issue, the first hop and the second hop are on the same device and the virtual interface doesn’t respond to icmp so isn’t seen. As long as the next hops are seen the results of traceroute or MTR is still useful.
The bigger thing to think about, if you are doing MTR, is that the tunnel is actually masking a whole load of hops, so the better test is to have the MTR run outside the tunnel to the same end point meaning you can get metrics on all the outbound hops that the tunnel passes over.