Simon Kissel
2006-Feb-22 13:33 UTC
ICMP time exceeded in-transit sent from wrong interface
Hi, I''ve got a rather confusing problem. My linux router box has several internet uplinks of various kinds (pppoe, ippp, ethernet). These uplinks are used by a tunnel to another location. It kinda looks like this: eth0 - internet uplink eth1 - LAN tun0 - tunnel device ppp0 - another internet uplink ... Routing is setup with iproute2 in a way that pakets with a source IP from the LAN are routed to the tun0 device. Both the tunnel and the LAN use public IP addresses. All of this works just fine. Pakets come in via the tunnel (phyiscally that would be eth0-tun0) and then get sent to eth1 (lan). So, eth0-tun0-eth1. It also works in the other direction: There is just one slight annoyance. Doing a traceroute from the outside, one would expect to see the following hops: far tunnel endpoint eth1 target in LAN. Instead, I see: far tunnel endpoint eth0 target in LAN. In other words (sorry, I''m not perfect at this): During the traceroute, a paket should arrive through tun0, and during forward to eth1 the TTL should get decremented, the kernel should notice the TTL has exceeded, and then it should back an "ICMP time exceeded in-transit" message. Well, that message gets generated, but it does not get sent from the interface IP of eth1, but instead of eth0. This makes it look like the route goes like tun0-eth0-eth1 instead of tun0-eth1. Checking with tcpdump I can see that in reality nothing gets routed to eth0 and back - it''s only the ICMP message that gets sent from the wrong interface. My question now is: WHY does that happen, and what could I do against it? Is there some kernel setting or mechanism that decides which interface is used when sending ICMP time exceeded in-transit messages? My goal is that the message gets generated for the correct hop... Thanks in advance for any help and pointers! Simon
Simon Kissel
2006-Feb-23 14:18 UTC
Re: ICMP time exceeded in-transit sent from wrong interface
Just in case someone else in the future googles for this problem: SK> My question now is: WHY does that happen, and what could I do against SK> it? Is there some kernel setting or mechanism that decides which SK> interface is used when sending ICMP time exceeded in-transit messages? SK> My goal is that the message gets generated for the correct hop... This seems to be as designed by the kernel. The ICMP message gets sent from the target address of the original paket, if that address is local. If not, the ICMP message gets sent from 0, the default interface (which in my case is eth0). IMHO this is totally broken logic in the Kernel. For a router, the target address of the original paket will never be local. Instead the address of the interface the paket gets forwarded to should be used as the source address for the ICMP message. Simon