August 2025 - 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. 08 Aug '25

08 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