On 18.08.2025 03:08 Roger Dingledine via tor-relays <tor-relays@lists.torproject.org> wrote:
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.
No, I can reach other systems properly, the relay runs fine for months. As you can see from my traceroute, the issue is not local at my hoster.
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
Can this be liftet again?
(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):
Why don't they emit ICMP no route/route rejected in this case at least for their internally originating traffic? It sees they either null-route or block my address/net as a destination. Can someone from them investigate that?
~> 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)
I know, many hosters that allow TOR can land there.
More info on the MIT behavior here: https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/90
Why are directory authorities operated in such networks? TOR exits are known to become listed on certain IP blacklists/DROP etc.
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.)
I can reach it from both my relays using telnet. For the traceroute situation, FreeBSD traceroute (different than traceroute6) I had to pass -e additional to -p 443 and -P tcp. Now the packet looks like this: 06:24:46.144934 IP teufel.dorfdsl.de.54759 > sungod.sysnet.ucsd.edu.https: Flags [S], seq 29087207, win 0, length 0 Last hop is 13 agg-b-mcore.ucsd.edu (132.239.254.44) 197.409 ms 200.302 ms 200.034 ms I assume traceroute doesn't really implement TCP here, so the packet will be dropped. Linux traceroute is different and works. -- kind regards Marco Send spam to abfall1755479317@stinkedores.dorfdsl.de