Discussion:
[Openvpn-users] traceroute through a VPN tunnel
Lindsay Haisley
2007-11-06 19:22:55 UTC
Permalink
This is more an annoyance and a matter of curiosity than it is a
problem, but the answer may have implications elsewhere in my OpenVPN
setup.

I have a VPN set up using OpenVPN from my desktop to my server in
another location. The VPN works fine! I can ping the server through
the VPN, connect to it, mount filesystems via NFS, whatever I need to
do. The VPN passes through the server's firewall with iptables rules
that give complete trust to the tap0 IF and any boxes on the other end
of the tunnel.

If I traceroute to the server, from my desktop, the UDP traceroute
packets are being received, but no ICMP Unreachable (type 3) message is
being sent from the server to indicate that the UDP packets are being
received at the server, so traceroute simply cycles, sending packets to
successively higher ports until it gives up after 90 tries. I've
verified rcpt of the UDP packets and the non-issuance of the proper ICMP
message with tcpdump on the server.

I can traceroute to the server from other boxes, not on the VPN, and the
proper ICMP message packet is sent back when the packet TTL allows a
traceroute packet to reach the server. Ports 33434 and up are not
otherwise occupied, so the server should respond properly.

I can traceroute using ICMP packets instead of UDP packets (traceroute
-I ...) which works fine, but I should be able to use UDP packets for
this through the VPN tunnel just as I can from points elsewhere on the
Internet.

Anyone have any idea what's going on here?
--
Lindsay Haisley | "Everything works | PGP public key
FMP Computer Services | if you let it" | available at
512-259-1190 | (The Roadie) | http://pubkeys.fmp.com
http://www.fmp.com | |
Prasanna Krishnamoorthy
2007-11-07 03:12:42 UTC
Permalink
Post by Lindsay Haisley
I can traceroute using ICMP packets instead of UDP packets (traceroute
-I ...) which works fine, but I should be able to use UDP packets for
this through the VPN tunnel just as I can from points elsewhere on the
Internet.
I've done plain traceroute and tracepath through multi-hop VPN
tunnels. So certainly there's no issue with openvpn. I would expect
that it's a routing issue, except for the fact that you're getting
back replies if you do traceroute -l.

So there may be something specific in your firewall config which
disallows replies to the UDP requests. You'll need to check your
config.

Prasanna.
--
www.elinanetworks.com
Seamless, secure delivery of applications.
Lindsay Haisley
2007-11-07 15:25:14 UTC
Permalink
Post by Prasanna Krishnamoorthy
I've done plain traceroute and tracepath through multi-hop VPN
tunnels. So certainly there's no issue with openvpn. I would expect
that it's a routing issue, except for the fact that you're getting
back replies if you do traceroute -l.
It's actually "traceroute -I hostname" which uses ICMP packets for the
traceroute instead of UDP packets. The routing seems to be OK. The VPN
works as expected, except for this one issue.
Post by Prasanna Krishnamoorthy
So there may be something specific in your firewall config which
disallows replies to the UDP requests. You'll need to check your
config.
Well I went through the available OpenVPN config options and couldn't
find anything relevant. A tcpdump on the tap0 IF on the server clearly
shows UDP packets coming it, addressed to ports 33434 and up, but no
corresponding ICMP "unreachable" packets being sent out in reply. I
would suspect an IF-specific kernel issue, maybe in the TAP/TUN module.
iptables rules specifically allow _all_ traffic from the tap0 IF to pass
through the firewall, so the traceroute UDP packets aren't being
dropped, just ignored.

I also looked through the sysctl params in and above /proc/sys/net/ipv4
and the documentation on them in the kernel docs, but found nothing
there, either.

I have a couple of client boxes on the same VPN, also running OpenVPN,
and they exhibit the same phenomenon. I can ping them, log into them,
traceroute -I to them, but a traceroute using UDP packets goes nowhere.
--
Lindsay Haisley | "In an open world, | PGP public key
FMP Computer Services | who needs Windows | available at
512-259-1190 | or Gates" | http://pubkeys.fmp.com
http://www.fmp.com | |
Erich Titl
2007-11-07 15:31:56 UTC
Permalink
Hi
Post by Lindsay Haisley
Post by Prasanna Krishnamoorthy
I've done plain traceroute and tracepath through multi-hop VPN
tunnels. So certainly there's no issue with openvpn. I would expect
that it's a routing issue, except for the fact that you're getting
back replies if you do traceroute -l.
It's actually "traceroute -I hostname" which uses ICMP packets for the
traceroute instead of UDP packets. The routing seems to be OK. The VPN
works as expected, except for this one issue.
Post by Prasanna Krishnamoorthy
So there may be something specific in your firewall config which
disallows replies to the UDP requests. You'll need to check your
config.
Well I went through the available OpenVPN config options and couldn't
find anything relevant. A tcpdump on the tap0 IF on the server clearly
shows UDP packets coming it, addressed to ports 33434 and up, but no
corresponding ICMP "unreachable" packets being sent out in reply. I
would suspect an IF-specific kernel issue, maybe in the TAP/TUN module.
iptables rules specifically allow _all_ traffic from the tap0 IF to pass
through the firewall, so the traceroute UDP packets aren't being
dropped, just ignored.
What are the TTL values on these packets? A TTL of 0 should trigger the
ICMP.

cheers

Erich
Lindsay Haisley
2007-11-07 15:52:32 UTC
Permalink
Post by Erich Titl
What are the TTL values on these packets? A TTL of 0 should trigger the
ICMP.
This is a different kind of ICMP reply. Addressing an unmonitored port
with a UDP packet should return a type 3 ICMP packet (Destination
Unreachable). If the TTL goes to 0 on a packet, a type 11 (Time
Exceeded) ICMP message is generated in reply. The former is independent
of the packet TTL.
--
Lindsay Haisley | "The voice of dissent | PGP public key
FMP Computer Services | was arrested before the | available at
512-259-1190 | president cleared his | http://pubkeys.fmp.com
http://www.fmp.com | throat to speak |
| of freedom" |
| (Chris Chandler) |
Continue reading on narkive:
Loading...