[tor-relays] Re: moria1 unreachable from AS202306

[Roger Dingledine via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx>]

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

_______________________________________________
tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx