July 2025 - tor-relays - lists.torproject.org

GeoIPFile option warning
by krishna e bera 27 Jun '26

27 Jun '26

I am seeing these warnings in Tor's notices.log: Mar 24 09:42:21.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Mar 24 09:42:21.000 [notice] Configured to measure entry node statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. However the option is set in torrc and i verified the files are at those locations and readable by all: GeoIPFile /usr/local/share/tor/geoip GeoIPv6File /usr/local/share/tor/geoip6 Any hints how i could check whether the warnings are spurious or dump what the running config actually is? I know it is reading the torrc because introducing an error in the file stops it from loading.

2 2

upcoming CIISS update
by nusenu 01 Feb '26

01 Feb '26

Hi, I'm working on a new contactinfo information sharing specification version. Current version (2): https://nusenu.github.io/ContactInfo-Information-Sharing-Specification/ Some likely changes will be: * add happy family proof https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/407/diffs * add signal username field https://support.signal.org/hc/en-us/articles/6712070553754-Phone-Number-Pri… * maybe add keyoxide field as suggested by boldsuck: https://github.com/nusenu/ContactInfo-Information-Sharing-Specification/iss… Feel free to send me your suggestions and opinions before 2025-06-30 by creating github issues or by replying to this thread. kind regards, nusenu -- https://nusenu.github.io

3 5

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

03 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

authority bandwidth measurements and latency
by Marco Moock 20 Aug '25

20 Aug '25

Hello! I operate 94DEAD24492D6D01E3DE614E8BE6B4035329A4D7 and I've seen various changes in the measured bandwidth in atlas. At the beginning, more than 10 MB/s were measured, now below 3. The machine itself didn't change, I can reach high up- and download rates if I transfer stuff via HTTP/FTP etc. I see that latency isn't that low (50ms https://atlas.ripe.net/measurements/116107380/results) and want to ask if that might be part of this situation. I dunno about the TCP settings of the authority bandwidth testing machines. Can anybody give some hints what's going on? -- Gruß Marco Send unsolicited bulk mail to 1751988041muell(a)stinkedores.dorfdsl.de

3 4

Tor People @ WHY2025
by Alexander Hansen Færøy 11 Aug '25

11 Aug '25

Hey Relay Operators, I'll be at the upcoming WHY2025 hacker camp in the Netherlands. WHY2025 is an excellent opportunity to do a Relay Operator meetup at some point during the camp days. Who else from here is going? At the latest CCCamp, we did a meetup at the BornHack village, but we did receive some negative feedback on the noise level in that general area, so I was thinking of investigating if there is a quieter place with some good seating where we could host the meetup this time, and announce the time and location here on the list. Suggestions of locations are most welcome. I recently received a link from tornth on #tor-relays on IRC/Matrix to https://wiki.why2025.org/Project:Tor_Relays, where it's relatively easy to add "Tor Relays" as a project from your WHY2025 wiki account. Cheers, Alex -- Alexander Hansen Færøy

4 6

QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 07 Aug '25

07 Aug '25

Dear experts, I have a special question, for which I could not find 100% clear documentation after a research. Situation: - VPS with more than one IPv4 and IPv6 address - IPv4 within the VPS is private class-A only (i.e. 10.x address), so port binding happens to the private Class-A - External IPv4 is linked outside the VPS to the private Class-A - of course, VPS is externally reachable by the external IPv4 - I would like to use a secondary IPv4, i.e. NOT the one, which is shown, when you run the command 'curl -4 icanhazip.com' from within the VPS) - I would like to use a secondary IPv6, i.e. NOT the one, which is shown, when you run the command 'curl -6 icanhazip.com' from within the VPS) Let's assume, for my example only, I have the following secondary IP addresses : - external IPv4 7.8.9.10 - internal IPv4 10.0.0.7 - IPv6 [2345:bad:face::] Let's further assume, my ORPort was 1234 and the obfs4 port was 4321 In order to have TOR distribute the correct bridge line "obfs4 7.8.9.10:4321 <...>", is the following torrc config correct? BridgeRelay 1 ORPort 7.8.9.10:1234 NoListen ORPort 10.0.0.7:1234 NoAdvertise ORPort [2345:bad:face::]:1234 Address 7.8.9.10 Address [2345:bad:face::] OutboundBindAddress 10.0.0.7 OutboundBindAddress [2345:bad:face::] ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs4 10.0.0.7:4321 ExtORPort auto ContactInfo johndoe(a)nowhere.org Nickname MyCoolBridge With this config, I indeed am able to connect to the bridge using the "obfs4 7.8.9.10:4321 <...>" bridge line, but is this line also communicated like that by the bridge distributor, or do I need to adapt the above config to ensure proper distribution? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

5 10

Usefulness of independent Snowflake network?
by Jonah Aragon 27 Jul '25

27 Jul '25

Hi all, I’ve spent some time setting up a standalone Snowflake network this week, mainly for my own practice. Basically what I have is: - A Snowflake broker working with domain fronting on a CDN other than CDN77, and of course Amp Cache. - Two Snowflake bridges, https://metrics.torproject.org/rs.html#search/Triplebit%20transport:snowfla… - A handful of proxies with high-speed/no-NAT connections configured to use this network instead of the default. And everything works perfectly in stable Tor Browser. I was mostly curious about what the performance would look like, and of course it is better since I’m the only one using it :) I was thinking that a potential use could be to have a Snowflake network that has no browser extension proxies or proxies behind NAT, only standalone daemons on high-performance networks from operators willing to contribute. My theory is that there are some people who would benefit from a Snowflake bridge with performance more in line with obfs4 or WebTunnel, which may or may not really be true. What I’m wondering is, do you think this is a concept worth pursuing, or do I just leave it as a weekend experiment? Obviously a big advantage is lost by having fewer proxies compared to the current Snowflake network, which would make it easier to enumerate. I think a big advantage gained as a bridge operator is being able to publish the bridge line publicly and take advantage of domain fronting without actually proxying Tor traffic through a CDN. I can change the IPs of my bridges by swapping out proxies, without bridge users needing to update their bridges in their client, which seems like a win. What I don’t know: - Could this actually provide the same or greater value than just contributing more standalone Snowflake proxies to the public network? - Is this worthwhile compared to simply running WebTunnel bridges? - Is there one other relay association perhaps willing to volunteer to run a bridge on this network, and are there other relay associations or individuals willing and able to contribute only high-performing and standalone proxies to it? Let me know what you think! Best, Jonah

1 0

Re: webtunnel bridges for the telegram distributor
by George Hartley 24 Jul '25

24 Jul '25

Thanks, I agree that obfs4 looks like "random data" so it is relatively easy to block with middle-boxes or deep packet inspection. George On Monday, July 21st, 2025 at 1:19 PM, meskio <meskio(a)torproject.org> wrote: > Quoting George Hartley (2025-07-18 05:32:28) > > > > Russia is extending their Tor block[0]. Currently, they block Fully > > > Encrypted >Protocols like obfs4 on some mobile networks[1]. > > > > Does this also apply to obfs4 bridges with timing and packet-size obfuscation > > enabled on both client and server side (iat-mode=2)? > > > Yes, is not that they are detecting obfs4 as a protocol, but they block anything > that looks like random and they can't recognize. > > > -- > meskio | https://meskio.net/ > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > My contact info: https://meskio.net/crypto.txt > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Nos vamos a Croatan.

1 0

facing out the moat bridge distributor
by meskio 23 Jul '25

23 Jul '25

tl;rd: if you have a bridge configured with "BridgeDistribution moat" remove this config option from torrc so it can be reassigned to another distributor or replace "moat" by "settings". In December we shutted down bridgedb[0] and stopped distributing "moat" bridges. The distributor that the Tor Browser uses automatically "settings"[1]. We hold the existing moat bridges without being distributed as they were still used by people around the world. So censors can't find them and users can still use them without getting blocked. As the usage of those bridges has declined now we decided to redistribute those bridges and automatically assign them either to the "settings" or "telegram"[2]. The only bridges that are not automatically reassigned are the ones with a configuration "BridgeDistribution moat". rdsys will not assign to any distributor bridges that have "BridgeDistribution" assigned to an unexisting distributor. If you run such bridge please remove the BridgeDistribution config line in torrc or change it an existing distributor so your bridge get distributed. If you want to hold your bridge undistributed is better to configure it with "BridgeDistribution none". Thank you. [0] https://blog.torproject.org/making-connections-from-bridgedb-to-rdsys/ [1] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/blob/main/doc/dis… [2] https://gitlab.torproject.org/tpo/anti-censorship/rdsys/-/issues/233 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

1 0

webtunnel bridges for the telegram distributor
by meskio 21 Jul '25

21 Jul '25

Hello, Russia is extending their Tor block[0]. Currently, they block Fully Encrypted Protocols like obfs4 on some mobile networks[1]. For a while, WebTunnel has been a good alternative, but since June, Roskomnadzor has enumerated some WebTunnel bridges and blocked them by domain name[2]. Bridge operators can bypass this block by creating a new subdomain or using a new domain for their WebTunnel bridge. We are working on multiple solutions for this problem. And one of them is to start distributing WebTunnel bridges over Telegram[3]. In the past, our Telegram distribution bot has proved to be fairly resistant to the attempts to enumerate bridges made by the Russian censor. But to be able to do that, we first need to have enough bridges assigned to that distributor. We are looking for a minimum of 30 bridges assigned to this distributor. If you are in the capacity to host a WebTunnel bridge, please do so! You can follow the documentation on the Community portal[4] and configure your WebTunnel bridge with this option in your torrc: BridgeDistribution telegram Or if you're using our Docker container, you will need to add the lines below to your .env file: OBFS4_ENABLE_ADDITIONAL_VARIABLES=1 OBFS4V_BridgeDistribution=telegram It is ok if your WebTunnel bridge is on the same IP address of another existing WebTunnel bridge as long as is in a different subdomain name, for example www1.example.com. As the censor is blocking the bridges by domain name and not by IP. Please avoid hosting your bridge with Hetzner, Digital Ocean, OVH and do not use Cloudflare DNS, as there are reports of these are being targeted and blocked by DPI[5]. Thank you. [0]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [1]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [2]https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/i… [3]https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/158 [4]https://community.torproject.org/relay/setup/webtunnel/ [5]https://github.com/net4people/bbs/issues/490 -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.

5 6