- tor-relays - lists.torproject.org

Do nameservers ever block an entire /64 if a Tor exit is in there?
by forest-relay-contact＠cryptolab.net 20 Dec '25

20 Dec '25

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello. I'm aware that some nameservers block Tor, so running a recursive local resolver on the same IP that traffic exits can be a bad idea. The usual solution is to buy an extra IPv4 and bind the local resolver to it. What about IPv6? Is it safe to simply make a new IPv6 on the same /64 and use that for recursive lookups, or are there nameservers that block the entire /64 that a single Tor exit relay is on? I currently use Unbound with "do-ip6: no" because I do not want to fail lookups and receive a BadExit flag if my entire /64 is blocked. Regards, forest -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEvLrj6cuOL+I/KdxYBh18rEKN1gsFAmlFss8ACgkQBh18rEKN 1gugfA//UuYYhq7ATC1r3J/t5yHXB0bovAPzj519ICXGXaJ0TW86hY3PC5WzdYzk zKvKXArhQKm2Xdu9kh2w6YfETo3xTdUnTyLlBH1T/oeMamARUw1S+Osld4goiTS2 gsRzhN7hvzHw7NqMJLV+xEZQFBVLRg0Fi2E3oOqk5dBRbd5cMzpWZ4HiMqsY3jHH 6h5RY0HLk4HqPxGzAk0KRF056hDf4PmuGZuHSYsBR8PPMS4HwF/p6772KEK/ajBG VZr+v0Moi22dLMno+2SjkPy0rEOkRzOinOmqBLl6ajakn5lff0vR83eANTl3Vz2t bfP4PJ8bbraMVVdUEa5VobdDD8pGTbrryiB71gWO2AwS0GVnq8JIBK8pGSMAXmfc FNqxN/owYDSC+N3SlbOvK4YtIqbt5VKcU7nOuPzfBzm1cLMMq1NogzVN+FAdW9vr l9WD3AnKon6REM4ZpimDOZX8/5k0WKhhPm1TWmPa7ZB9NYyzQlbxEUmIIkQIXasW W0sVTeZ3vUwVQrUPilA8M0o8/cuWZleXs7RKNJP2T2r74olwUOw9E/afZXKxG9Hj daA1yUeD6tnUYk/pITddKHQ2V7Qd0BdHO2DMqQ71Bkcb7vTm/Ni45/jDaScaivz0 7vdCwPkC9k/sLEHHZ1kd33fjsGddILf7azSBRameI+9tgKZdw3E= =Z0tl -----END PGP SIGNATURE-----

1 0

Fwd: Potential vulnerability found in your Tor Relay
by krishna e bera 19 Dec '25

19 Dec '25

Hi all, Just got the below notice from researchers. Is the stated vulnerability an actively exploited problem or is this a DoS attack by scaremongering? This topic seems to have been covered in https://nusenu.medium.com/how-vulnerable-is-the-tor-network-to-bgp-hijackin… but i am not sure how to apply it to my situation. I have turned off the Guard capability for now. Doubtful i can influence the service provider to get them to publish a new ROA. Is there another mitigation? Regrets to all who were using the service :( -------- Forwarded Message -------- Subject: Potential vulnerability found in your Tor Relay Date: Thu, 18 Dec 2025 23:57:20 +0000 From: ENGR - SIDR Hello, We are writing to alert you that your Tor relay(s) (Pasquino3) is/are vulnerable to active BGP attacks that could be used to de-anonymize users. The best mitigation to help protect your relay is to have your service provider publish a ROA for prefix(es) 209.44.96.0/19 at AS(es) 10929 with a maxLength(s) of 19. We are researchers from the University of Connecticut reaching out to inform you that your Tor guard relay with IP address(es) 209.44.114.178 (Pasquino3) is/are currently covered by a Route Origin Authorization (ROA) which has an improperly configured maxLength attribute. This makes it vulnerable to BGP subprefix origin hijacks, where a malicious autonomous-system-level attacker may announce a subprefix of 209.44.96.0/19 and misdirect traffic destined with a high (>99%) rate of success. Guidance on how to correctly set the maxLength attribute is contained in https://datatracker.ietf.org/doc/html/rfc9319. We determined this vulnerability using public data sets including relay information from the Tor consensus, the RIPEStat data for IP prefix, and ROA coverage information. Feel free to contact us if you have further questions. For further information on ROAs, see https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/bgp-origi… If you are not a Tor relay operator and this message reached you in error, please let us know. Thank you, UConn Secure Interdomain Routing Group

6 5

automatic exit restriction policy does not include IPv6
by Marco Moock 19 Dec '25

19 Dec '25

Hello! I noticed that the implicit exit policy includes IPv4 localhost, RFC1918 IPv4 ranges etc, but does not include IPv6 by default, e.g. ::1, fe80::/10, fec0::/10 and not the public IPv6 itself. Is that a bug or a configuration issue? -- kind regards Marco Send spam to abfall1766003955(a)stinkedores.dorfdsl.de

2 3

Re: DirPort IPv6
by Marco Moock 05 Dec '25

05 Dec '25

On 04.12.2025 20:22 DiffieHellman <mailing_list(a)middlendian.com> wrote: > Reviewing a lot of contradictory information online and the tor > ChangeLog and torrc.sample, it appears that the DirPort supports > IPv6, but only authorities actually advertise directory information > anymore. > > There is still the secondary DirPort use, to serve the tor exit > notice (DirPort 80\n DirPortFrontPage /etc/tor/tor-exit-notice.html) > - which seems to be only targeted at those who see abuse and decide > to put the IPv4 address into a search engine and realise that it's a > tor exit (it seems that an assumption has been made that such sort > typically manages broken networks that are IPv4-only and therefore > listening on IPv6 wouldn't achieve anything). Thanks for the clarification. The note about this in the default torrc is outdated. -- kind regards Marco Send spam to abfall1764876123(a)stinkedores.dorfdsl.de

1 0

My exit isn't listed at https://check.torproject.org/exit-addresses
by Jon 04 Dec '25

04 Dec '25

Hi All, My exit 128.31.0.13 https://metrics.torproject.org/rs.html#details/A53C46F5B157DD83366D45A8E99A… is no longer listed in https://check.torproject.org/exit-addresses This is causing an uptick in abuse complaints to my upstream provider and making their stock response to check there a bit of a lie. metrics seem to show the relay is in good health and has a 14d uptime (since last package update). any idea what's going on with that? Thanks, -Jon

2 1

Re: Out-of-Memory-Attack & DoS from Tor-Client
by ProSecureRelays 04 Dec '25

04 Dec '25

Hi there, It's very unfortunate, but I don't have the Logs due to initial mistake I made, not setting up a Logfile. In the updated torrc file, i recently added it but I thought it is not worth a restart to implement this. Now it works. But I saw the relay logs in the cmd during the attack, and there was nothing unusal at all, except for the high rejection rates. The Out-of-Memory was also an Error that came from Windows, not the tor-process itself. I'm a bit positive surprised by the Windows Memory Management, all System Processes and the OS were unaffected by the attack. Additionally I have an powershell-script that monitores the tor.exe and restarts it after 2 minutes of "cool-down" if it crashes for 3 times. This was the first time it was ever needed, and I hope next time is not soon. Then I will also try the stupid oversize approach.. ;) About the Firewall Topic: I've read this manual you sent before, but I think its impossible with the windows firewall implementation. That's one weakness of closed source, either it matches the use case or you have to go for something completely different. The Windows Firewall is not statefull, but I had implemented very restrictive rules since the first day. However, this is limited by allowing only the tor.exe and related stuff to send and recieve traffic. If you would try to open a new process not listed, communication would fail. But fancy "real-time" stuff - not a chance. I mean creating some rules via powershell no prob, but how to analyse the concurrent, tor related connections (grabbing netstat?!) - sounds difficult and ressource heavy to me, and I'm sadly not a coding expert. In total there are 3 Firewalls between Internet and Tor, one Open-Source, one proprietary and the Windows Firewall, maybe I can stop this happening at another point in the network. I'll dig a bit deeper when I have the time, next step planned is implement Windows Applikation Control, so only the tor.exe I've made a checksum beforehand, is allowed to run. But thats a different topic. Thank you very much for your suggestions and maybe other hints/tips! Best regards, Joker

3 2

Out-of-Memory-Attack & DoS from Tor-Client
by ProSecureRelays 04 Dec '25

04 Dec '25

Hi there, i just want to report two partially successfull DoS Attacks on my Relay: First attack: Occured yesterday. The tor process showed massive traffic, much more my upload ( 45 Mbits) could handle. I don't know how in detail this worked, but I had receiving traffic at about 40Mbits and the relay tried to send about 100Mbits towards WAN. Because I didn't know if this was harmful traffic for the tor network, I finally pulled the plug and obtained a new IP after about 4 hours into the attack. I had the feeling that a short time, there was still unusual sending/recieving ratio, but all related to tor.exe and it stabilized soon after. My Guess ist hat a malformed packet was sent by tor, resulting in uncontrolled, unknown traffic to the WAN-Side. The Realy had 3 DDoS Circuits killed, rejected circuits and introduce 2 at unnormal high rate, also like 117 marked addresses. It sent about 250GB more then it recieved. The attack is also clearly visible in Tor Metrics, a massive spike in written Bytes can be seen. Fingerprint: 8AFE4E6F05234B0184327C052B09F10191EAFAF3 Second Attack (today): Today at about 2 p.m., the memory of the relay spiked to maximum (8GB) and additionally 22GB of virtual memory was used. This caused the process to die, with an out-of-memory Error. This also must came from a malformed packet in tor. Is there any known method to circumvent both of these Issues? In the first event, i don't know if the error could have cleared self after some more hours. Regarding the memory issue, i think this must be resolved in the tor software itself, allthough I thought about adding 64GB of RAM and 256GB Page-File, just to see if it makes any difference in case of attacks. But I don't think so. Best regards, Joker

6 7

Add CGNAT 100.64.0.0/10 to Default Exit Relay Reject Policy
by admin＠likogan.dev 04 Dec '25

04 Dec '25

Hello, I've noticed that the non-publicly routable CGNAT subnet of 100.64.0.0/10 is not in the default exit policy reject list like 192.168/16 and 10/8 are. This range is not publicly routed, and should never need to be accessed from a Tor exit. Tailscale and other ISPs use this block. How many exit relays connected to a Tailscale network are unknowingly exposing all of their other Tailscale devices to the Tor network? ISPs may be less willing to allow exit relays if there are bots using Tor to toy with the ISPs 100.64/10 range. Maybe there is something I am missing for it to not be included? Thanks, Likogan.Dev

3 2

DirPort IPv6
by Marco Moock 03 Dec '25

03 Dec '25

Hello! Does DirPort support IPv6? If I use it without address, it only listend on the IPv4 socket. If I use DirPort [::]:9030, it cannot start up. -- kind regards Marco Send spam to abfall1764741021(a)stinkedores.dorfdsl.de

1 0

Small update to Relay Operator Expectations Policy
by Georg Koppen 02 Dec '25

02 Dec '25

Hello! We just pushed a commit to update our Relay Operator Expectations Policy[1] to version 2.1. It comes with a clarification for section "3. Make sure your relay isn't broken", where we now say "Don't block outgoing connections." instead of "Don't firewall outgoing connections." This makes the point we try to convey in that particular part of the policy clearer. For context, this topic got raised in a recent thread about Hetzner related issues[2] and, while we improved the wording of our expectations document and updated the bad-relay criteria accordingly, we are not done on that front yet. There is still a ticket open for investigating potentially acceptable solutions dealing with the underlying issue at Hetzner on a technical level[3]. Depending on that outcome and after thinking through filtering/rate-limiting concerns we might need to update the expectations document in the future again. Thanks to everyone who helped so far both with the technical investigation and policy discussion. Georg [1] https://community.torproject.org/policies/relays/expectations-for-relay-ope… [2] https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torp… [3] https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/105

1 0