- tor-relays - lists.torproject.org

FW: Re: Tor
by C. Pe. 11 Aug '25

11 Aug '25

forgot to copy the list. ---------------------------------------- Betreff: FW: Re: [tor-relays] Tor Von: C. Pe. <peca-relay(a)mailfence.com> An: CIP <ciptorrelays(a)gmail.com> Datum: 09.08.2025, 17:10:51 Hi, after looking at the first five entries from your list, I observe one common pattern: - Each relay has got a reachable IPv6 address (next to IPv4) - Each relay has an IPv4 exit policy - Each relay has got NO IPv6 exit policy (i.e. "reject 1-65535") Could that be the reason? You have, so to say, an IPv4-exit and at the same time an IPv6 middle-only-relay. (Please note, that I am NOT a member of torproject.org, but just a bridge and non-exit relay operator, so I do not have any further insight) Regards, C. Am 08.08.2025 um 05:13, CIP via tor-relays <tor-relays(a)lists.torproject.org> schrieb: Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

3 3

No update of bridge distribution method?
by C. Pe. 09 Aug '25

09 Aug '25

Hello all, next to my posts about the NAT and non-default IP for bridges topic, I would like to draw your attention to my observation, that somehow, bridge distribution seems not updating and hence no distribution and no traffic. Please refer to the below examples, which all are configured properly without any "special" situation: E80088962F97FE190D734D67E0C656C2A6EADEE7 (webtunnel, on distribution method "none" since more than a week, despite method manually set in torrc) 45E1449B8B87ACFE6AF40CD33E91DFC3CB9B7488 (obfs4, this one is active way longer than indicated in "first seen", also shown as distribution "none") Is something wrong with the distribution DB ? Thanks & regards, C. -- Sent with https://mailfence.com Secure and private email

1 0

Tor
by CIP 09 Aug '25

09 Aug '25

Hello. We launched 20 Tor relays about a few weeks ago. We have learned that all of our relays have 2 strange flags: BadExit and MiddleOnly. Why are these flags assigned to our relays? Did we misconfigure something? Here is a list of our relays: E977DB4A822E3A949E6C2819AEBC3414CE214CF1 CBBAE95A4EE11633C435F7080BC6A03683045E09 06D96F28744B5E904E29A0E5B30EF6939200A657 999CA95B7F7ED9084360F8DA45CBD128FE677450 B6B64E54F1480F649F15E54DDC13E0CEE24117A1 4B55ED89F4DCF003EFEA1F899F6242D484A201CB C3E1511072DA6EFCF14232DB12D7E0B41B493A05 8E57FA4CCCCCA55D5E0DBCA6EEB63D7893CCAC9C 00A591A34E271E1A2BE595B03FA1F349E113589A BA20A8077D27CFE1701805920754867152C23863 4F1557DF7CD3E92880638BB72A0FCC5A30750794 66CE6400C5868EF548FB992D375D7CC8D61ABA4C DF70D38C775156A4662BC9BD9B2565D83663626B F2D902F0E8C40BE0E4328BA825DEAF7A72F0CCE7 C9BB71EA60EB1E5BBE6437E9F95426910E921940 E91A14923166F88221EF6AB9070C1C6702C3B293 81B242FE18D95A39535AFECEDADEBA8969C3FD3A C32A47FD85627A0D4F6EE121C9FA976D77F90160 3E7C2C3065EBAB57C9C1200BE26922F81DE67F16 AC80958B66FE21FAF5B6105F631BC4A7744F64EC

3 2

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

FW: RE: Re: Re: QUESTION: OBFS4 on secondary IP and NAT
by C. Pe. 05 Aug '25

05 Aug '25

Seems I only answered to George, instead of all, sorry. ---------------------------------------- Betreff: FW: RE: Re: [tor-relays] Re: QUESTION: OBFS4 on secondary IP and NAT Von: C. Pe. <peca-relay(a)mailfence.com> An: George Hartley <hartley_george(a)proton.me> Datum: 05.08.2025, 14:41:41 I am of course not the expert here. However - NoAdvertise and NoListen are usually combined in two consecutive ORPort statements. This is done to in fact to tell Tor to "listen to ip:port A, but advertise ip:port B", so there definitely is an advertisement of the relay. A relay works fine with that and the "relay piece of a bridge" (so to say) also works well. But yes, there indeed IS some hassle with the bridge distribution (see also my other post, which still waits moderator approval). Question remains: Is that a known "shortcoming" for pluggable transports, or is there a special way needed to configure this properly? So we seem to have two issues with bridge setup, NAT and binding to specific IP: 1. Not possible to properly advertise/distribute obfs4 external IP, if obfs4 port binding to internal IP. 2. In such cases, bridge distribution does not happen. I have, based an observation from another bridge without NAT, even the impression, that specifying a specific IP instead of 0.0.0.0 or [::] in the ServerTransportListenAddr causes a bridge distribution "none". Maybe a bug? C. On August 5, 2025 at 4:46 AM, George Hartley <hartley_george(a)proton.me> wrote: Is this not the purpose of NoAdvertise? You use that flag if you want a private bridge (for example, to give to your friends). Using both NoAdvertise and NoListen on an OBFS4 bridge behind NAT can make BridgeDB treat your bridge as “no distribution.” Because NoAdvertise strips the bridge descriptor from publication, and NoListen prevents the ORPort from binding on your public interface, BridgeDB can’t see or test your bridge. As a result, it marks its distribution status as “None.” The easiest fix is to forward your ORPort through NAT and remove (or at least temporarily disable) those flags so your bridge descriptor is published and reachable. Once BridgeDB can reach and verify your ORPort, it will resume distributing your bridge normally. If you’d like more control, you can also set a specific BridgeDistribution method (for example, moat) in your torrc. Regards George On Tuesday, August 5th, 2025 at 3:46 AM, Gary C. New via tor-relays <tor-relays(a)lists.torproject.org> wrote: I'm seeing a similar issue with a recently configured OBFS4 bridge using NAT, NoAdvertise, NoListen, and distribution status displaying as "None." On Sunday, August 3, 2025 at 12:36:37 PM MDT, C. Pe. via tor-relays <tor-relays(a)lists.torproject.org> wrote: Is there maybe another issue with rdsys being "stuck" ? I have again a new/renewed bridge in distribution status "None" since some days and https://bridges.torproject.org/status?id=<fingerprint> shows for all bridges the last testing two days ago (According to your below statement, updates should appear latest after 4h) Thanks & regards, C. Am 31.07.2025 um 13:12, meskio via tor-relays <tor-relays(a)lists.torproject.org> schrieb: You can always check if the bridgeline distributed by rdsys is correct by visiting: https://bridges.torproject.org/status?id=<your hashed or not fingerprint> This should display one bullet point per IP/transport, so in your case two, one for IPv6 and another for IPv4. Take into account that it might take up to 4h for this page to be updated when you do changes. -- Sent with https://mailfence.com Secure and private email _______________________________________________ tor-relays mailing list -- tor-relays(a)lists.torproject.org To unsubscribe send an email to tor-relays-leave(a)lists.torproject.org -- Sent with https://mailfence.com Secure and private email -- Sent with https://mailfence.com Secure and private email

2 1

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

new OBFS4 bridges with bridge distribution method "None" since a couple of days
by C. Pe. 15 Jul '25

15 Jul '25

Dear experts, according to the documentation, a new obfs4 bridge should get a bridge distribution method assigned after running a day. The two bridges listed below are running since more than a week and both still show "none" as bridge distribution method. (Probably due to that, they even don't get up to speed) Attempting to manually set the method in torrc does not change the situation... https://metrics.torproject.org/rs.html#details/76ADDDFD1C70D60BE6F524B111A3… https://metrics.torproject.org/rs.html#details/4FB2FA7B6678169B609B771F240B… Thanks in advance for any advice. C. -- Sent with https://mailfence.com Secure and private email

2 1