I'm trying to do a "traceroute -6 " to one of my hosts behind an openroute 18.06.0 Netgear 3700v4. I've temporarily disabled the ipv6 firewall with: ip6tables -F INPUT; ip6tables -F OUTPUT; ip6tables -F FORWARD and checked that the default rule for falling off the end of the table is ACCEPT for each of the 3 tables affected. When I do a IPv6 traceroute into the remote site's lan from the internet I never see the router itself answering with an ICMP time exceeded. This is happening for both "traceroute -6" and "traceroute -6 -I" (that's the capital i). Are other people seeing the same thing? Is there some filtering I forgot to turn off or enable like a kernel variable?
This is dangerous...and likely not done yet...
Did you permit IPv6 forward from WAN to LAN?
Yes. That is what the "ip6tables -F FORWARD" does. It cleared any iptables filtering for forwarding on the ipv6 side. I'm not sure how it is dangerous. Every other router in the world seems to implement the ttl expired correctly these days. It is pretty much needed for getting a correctly functioning traceroute.
Then, you must not be familiar with what you're doing. Such a rule opens your LAN to the world on IPv6...and every machine has its own Public IP.
You could lock this down and only permit forwarding to the ICMP and UDP ports in question (Linux implementations of traceroute use UDP).
EDIT: Also, if your testing outbound trace, it should already work (ESTABLISHED, RELATED), so likely you need to permit UDP.
I think the flushing firewall rules was just for testing purposes not a proposed permanent situation.
Do your pings into the remote lan work if ttl isn't exceeded? @wolfgangrupprecht
1 Like
As I said, this is a temporary test to rule out any firewall issue. I knew people would assume it was the firewall if I didn't state it was off.
Yes ipv6 pings into the lan work as do pings of the router itself. It is just the TTL exceeded that never get generated by the router. Note the lightly redacted traceroute and traceroute -I. The final host inside the network responds correctly.
traceroute -I 2601:603::x
traceroute to 2601:603:: (2601:603::), 30 hops max, 80 byte packets
1 2601:641::x (2601:641::x) 0.559 ms 0.553 ms 0.768 ms
2 2001:558:4000:74::1 (2001:558:4000:74::1) 8.323 ms 14.000 ms 14.227 ms
3 po-104-rur01.fremont.ca.sfba.comcast.net (2001:558:82:137::1) 13.901 ms 13.961 ms 13.962 ms
4 2001:558:80:1e6::1 (2001:558:80:1e6::1) 15.205 ms 15.264 ms 15.263 ms
5 * * *
6 be-7922-ar01.burien.wa.seattle.comcast.net (2001:558:0:f747::2) 32.167 ms 30.585 ms 30.575 ms
7 po-1-rur01.tumwater.wa.seattle.comcast.net (2001:558:a0:c::1) 34.182 ms 29.536 ms 30.053 ms
8 po-1-1-cbr07.tumwater.wa.seattle.comcast.net (2001:558:a2:f5e3::2) 108.922 ms 108.986 ms 108.990 ms
9 * * *
10 2601:603::x (2601:603::x) 44.567 ms 44.616 ms 44.639 ms
traceroute 2601:603::x
traceroute to 2601:603:: (2601:603::), 30 hops max, 80 byte packets
1 2601:641::x (2601:641::x) 0.577 ms 0.745 ms 0.965 ms
2 2001:558:4000:74::1 (2001:558:4000:74::1) 8.743 ms 15.221 ms 15.406 ms
3 po-104-rur01.fremont.ca.sfba.comcast.net (2001:558:82:137::1) 15.066 ms 15.097 ms 15.070 ms
4 2001:558:80:1e6::1 (2001:558:80:1e6::1) 16.245 ms 16.238 ms 16.209 ms
5 be-3651-cr02.sunnyvale.ca.ibone.comcast.net (2001:558:0:f6d2::1) 16.595 ms * *
6 be-7922-ar01.burien.wa.seattle.comcast.net (2001:558:0:f747::2) 33.221 ms 31.787 ms 31.769 ms
7 po-1-rur01.tumwater.wa.seattle.comcast.net (2001:558:a0:c::1) 35.346 ms 32.919 ms 33.005 ms
8 po-1-1-cbr07.tumwater.wa.seattle.comcast.net (2001:558:a2:f5e3::2) 387.007 ms 387.054 ms 387.043 ms
9 * * *
10 2601:603::x (2601:603::x) 38.504 ms !X 37.979 ms !X 43.355 ms !X
The traceroute is the same with the firewall totally disabled or running normally. I was a bit concerned that there might have been some confusion as to which table applied to ttl exceeded (FORWARD, INPUT, OUTPUT or potentially all 3).
Actually linux traceroute uses either UDP or ICMP depending on which one you request. You will notice, as I previously mentioned, I had tried both.
As for dangerous, I believe all correctly configured hosts already have per host firewalls blocking any ports that aren't safely exposed to the internet. Assuming the local lan is secure is a big mistake as companies like TJ Max discovered the hard way. Most of the large scale break ins were caused by such thinking. So for this test the only thing exposed was the router itself and that was for a minute or two. I put the openwrt default INPUT and OUTPUT tables in place again right away. Thanks for the concern though. My machines have been on the IPv6 net since the late 90's when everybody had 3ffe:ffff::/32 addresses. This isn't my first rodeo.
I never said it wouldn't be temporary. I'm saying that you may have not allowed UDP, but it seems you're allowing all IPv6 for this testing (which is dangerous; but only temporary, so, I guess OK).
Try: icmp_errors_use_inbound_ifaddr
Thanks for the idea. I only see that on the ipv4 side of things and don't see any icmp* vars on the ipv6 side of things.
echo 1 > /proc/sys/net/ipv4/icmp_errors_use_inbound_ifaddr
I did try setting the ipv4 variable, but it had no effect on the ipv6 traceroute. That is a great idea though. I wonder if that is the problem, the router replying with the wrong source address. I'm going to have to see how I can log the outbound ipv6 ICMP's on the remote router.
Interesting, there is no /ipv6 directory for the same setting...
I set this on my router in order for IPv4 tunnels to work with traceroute. I'm out of ideas...
Your idea that it is an address problem is a great one. I'm trying to set up the test now.
I think I see what is doing on. Openwrt appears to be passing the packet with expired TTL on anyway. The replies from hop #9 (the router) are actually being returned by the target host behind the router. I'm seeing the exact same error for udp and icmp traceroutes. In both cases the hop 9 requests are being answered by the remote host at hop 10. Interesting! I wonder if this is an upstream linux bug.