On 18.08.2025 03:08 Roger Dingledine via tor-relays <tor-relays@xxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxx
Attachment:
pgpAjsTGF84l2.pgp
Description: Digitale Signatur von OpenPGP
_______________________________________________ tor-relays mailing list -- tor-relays@xxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to tor-relays-leave@xxxxxxxxxxxxxxxxxxxx