Traceroute response endless?

[Bevan C. Bennett]

John Maxwell wrote:
> Forgive me if this is obvious or has been covered, but I'm puzzled.
> 
> I recently upgraded a webserver to FC1... it's a simple athlon with an 
> onboard eth0. I have a static IP address and very little running (just 
> sshd, httpd, and sendmail). When I traceroute to this machine, I get an 
> endlessly repeating last hop (when I run traceroute from OS X/bsd) or a 
> !<10> diagnostic on the last one (when I run it from an RH8 machine).
> 
> As far as I can tell from preliminary reading, this indicates a kernel 
> bug, but I'm up2dated to the latest 2.4.22.
> 
> Everything's working fine, but these traceroute results are worrying me 
> a little. Any insights?

Ok, it's definately caused by the default iptables rules.

Here's a tcpdump of a happy (iptables disabled) exchange:
17:58:52.806711 dionaea.internal.avlsi.com.49344 > wallace.33435: udp 10 
[ttl 1]17:58:52.806744 wallace > dionaea.internal.avlsi.com: icmp: 
wallace udp port 33435 unreachable [tos 0xc0]
17:58:52.807193 dionaea.internal.avlsi.com.49344 > wallace.33436: udp 10 
[ttl 1]17:58:52.807215 wallace > dionaea.internal.avlsi.com: icmp: 
wallace udp port 33436 unreachable [tos 0xc0]
17:58:52.807439 dionaea.internal.avlsi.com.49344 > wallace.33437: udp 10 
[ttl 1]17:58:52.807448 wallace > dionaea.internal.avlsi.com: icmp: 
wallace udp port 33437 unreachable [tos 0xc0]

And here's with iptables turned back on:
17:59:41.843532 dionaea.internal.avlsi.com.49345 > wallace.33435: udp 10 
[ttl 1]17:59:41.843560 wallace > dionaea.internal.avlsi.com: icmp: host 
wallace unreachable - admin prohibited [tos 0xc0]
17:59:41.843987 dionaea.internal.avlsi.com.49345 > wallace.33436: udp 10 
[ttl 1]17:59:41.844017 wallace > dionaea.internal.avlsi.com: icmp: host 
wallace unreachable - admin prohibited [tos 0xc0]
17:59:41.844246 dionaea.internal.avlsi.com.49345 > wallace.33437: udp 10 
[ttl 1]17:59:41.844260 wallace > dionaea.internal.avlsi.com: icmp: host 
wallace unreachable - admin prohibited [tos 0xc0]

The problem appears to be that traceroute uses normal UDP packets as 
probes rather than ICMP packets, and the new 'admin prohibited' message 
(rather than port XXXXX unreachable) causes it to display the extra 
!<10> (indicating that a code 10 ICMP packet was received).

I don't think there is anything actually wrong here, although traceroute 
is slightly upset.

You can use the -I flag to traceroute to specify that ICMP echo packets 
be used as probes rather than UDP packets.

You could also craft a more traceroute-friendly iptables by changing the 
error for UDP packets to ports 33434 - 33484 or so back from admin 
prohibited to port unreachable. In fact, a simple-minded set of lines like:
-A RH-Firewall-1-INPUT -m udp -p udp --dport 33435 -j REJECT

appear to work fine.

All in all, it's probably not worth worrying about unless you depend 
heavily on automatically parsed traceroute output or something like that.
you could also change your default reject back to the default (which 
-is- port unreachable) from admin prohibited.

Is there a good reason why they chose to change the default here?

-Bevan Bennett