On Sun, Aug 17, 2025 at 08:13:45AM +0200, Marco Moock via tor-relays wrote:

Hello!

I cannot communicate with moria1 from 78.153.140.44 and it cannot reach my system. I can communicate with the rest of the world.

For me, it looks like a firewall is blocking it, as traceroute clearly indicates a different behaviour for ICMP echo request and TCP.

I think we have two problems here: (A) You seem to have a firewall on your side which is blocking TCP connections to moria1's IP address. You could compare traceroutes to 128.31.0.24 (same box, different address) to see if some of them get farther. Some of these blocks around the internet of 128.31.0.39 come from the ddos events of 2021, where some jerk tried to overload the directory authorities by requesting directory info via Tor circuits (i.e. via exit relays). See this ticket which was a theoretical issue for many years until suddenly it was a concrete issue: https://bugs.torproject.org/tpo/core/tor/2667 The attack resulted in a bunch of admins around the internet deciding that blackholing the directory authorities was the right answer, e.g. here is a case where Verizon fios blackholed me for five years until I finally used enough back-channels to get them to stop: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/98 (B) But it's worse than that! All of MIT seems to null-route your address too. That is, here is the traceroute from one of the MIT shared dialups (not my computer there in particular): ~> traceroute 78.153.140.44 traceroute to 78.153.140.44 (78.153.140.44), 30 hops max, 60 byte packets 1 18.9.64.3 (18.9.64.3) 0.643 ms 0.717 ms 0.772 ms 2 BACKBONE-RTR-2-OC11-RTR-1.MIT.EDU (18.0.194.85) 1.718 ms 1.777 ms 1.729 ms 3 DMZ-RTR-2-BACKBONE-RTR-2.MIT.EDU (18.0.162.1) 0.819 ms 0.885 ms 0.842 ms 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * [...continues on for 20 more failed hops] I believe this is because MIT auto pulls in the spamhaus blocklists and nullroutes based on them. Your whole /24 is on the SBL: https://check.spamhaus.org/results?query=78.153.140.44 (click on 'more info' at the bottom) More info on the MIT behavior here: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90 and initial analysis about similar UCSD behavior here: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/97 (You could see whether you can reach SunGod from your relay too.)

What are your opinions about this?

It is sad that this happens and sad that it seems like it's happening more often lately. (Or maybe it has been happening like this for a while and we have only become better at noticing it lately?) Connectivity between relays is getting increasingly messy as more pieces of the internet decide to censor other pieces of the internet. We could imagine just abandoning all the parts of the internet that do these filters, and the Tor network would shrink to a smaller and smaller subset of the internet -- which is bad for scalability and bad for security. It is especially important to consider filters to/from the directory authorities, since if a majority of them can't reach your relay then users won't learn about you. So far, moria1 is the one where we've identified and understood the filters best, but the issue pops up on other dir auths too, e.g. https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/92 It is definitely a topic we are continuing to track and have been discussing among the dir auth operators. So long as it only affects a small minority of the directory authorities at any given time, the Tor network can tolerate it. And hey, having a small minority impacted can even (in a sense) be helpful since it helps us track how bad the problem is getting around the world. The part that makes me more worried is the increasing trend of filtering traffic to/from Tor exit relays. For example, at KAIST (the Korean technical institute) they block like 20% of the Tor network, not because they have explicitly chosen to block Tor but because they filter using third-party firewall lists which add a Tor exit as soon as it makes a connection to some secret honeypot address. The result is that Tor kind-of-mostly works as a client on that network (you can reach a guard after a few tries), but if they run a relay it can't make circuits to a lot of the rest of the network, leading to performance problems and maybe also anonymity problems for users. Hope this helps, --Roger