I have figured it out. Tor is fine. TTL=1 mentioned in incoming ICMP 11 messages is just the destination host's perspective, not what the relay originally sent out. I have traceroute'd to some hosts the relay was trying to connect to, and there are indeed infinite routing loops (misconfigured networks) over there, so TTL gets decremented to 1 and the ICMP error is delivered, as it should.
I am going to allow both ICMP type 11 and type 3 then. (Need to figure out what to do with incoming fragmented packets, but that's another story altogether, perhaps for tor-relays@) Thanks! On Sun, Oct 22, 2017 at 1:55 PM, teor <teor2...@gmail.com> wrote: > >> On 23 Oct 2017, at 05:14, Igor Mitrofanov <igor.n.mitrofa...@gmail.com> >> wrote: >> >> On my relays I am dropping any traffic that Tor itself does not rely on. >> I wonder if I should allow or block incoming and/outgoing ICMP type 11 >> (time exceeded / timeout in transit)? > > Try it and see? > >> My host does receive some ICMP type 11 packets, and does seem to send >> some out, but I am not sure if Tor is the source or destination. >> Do Tor relays use some 'traceroute'-like mechanism to detect unreachable >> relays? > > Not as far as I am aware. > >> "netstat -s: >> ... >> ICMP input histogram: >> ... >> timeout in transit: 1923 >> ... >> ICMP output histogram: >> ... >> timeout in transit: 1277 >> " >> I remember seeing outgoing TCP packets with TTL set to 1 - those were >> the ones triggering incoming ICMP type 11 packets. > > Are you running an exit? > Do you have multiple IP addresses? > Using OutboundBindAddressExit can help you to find out if it's tor relaying > traffic, or tor exit traffic from clients that are doing TCP traceroutes. > > T > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
