C:
I'll look forward to an update, following an adequate observation period and/or
update from meskio, et al.
Thank you for the well laid out summary of the issues in question.
Respectfully,
G
On Thursday, August 7, 2025 at 09:46:55 AM MDT, C. Pe.
<[email protected]> wrote:
Correct.
In short, once again:
1. The below works fine for a normal relay with internal class-A IPv4 and a
reachable public IPv4 / IPv6 - it also works fine for the "Relay part" of a
bridge.
ORPort 7.8.9.10:1234 NoListen
ORPort 10.0.0.7:1234 NoAdvertise
ORPort [2345:bad:face::]:1234
2. Using the line "ServerTransportListenAddr obfs4 10.0.0.7:4321" (i.e. binding
the internal class-A IPv4) for an obfs4 bridge has the following effects:
- The respective bridge line for obfs4 using the external IPv4 works well, you
can immediately use the bridge line in TBB
- In metrics, the bridge at first appears with transport "none" and
https://bridges.torproject.org/status?id=<hashed fingerprint> indicates a
working "vanilla" bridge w/o plugable transport- A while later (one day or so),
metrics updates to plugable transport "obfs4" in "green", but
https://bridges.torproject.org/status?id=<hashed fingerprint> show a
dysfunctional obfs4 bridge!- The bridge distribution method shown in metrics
stays forever as "none", even specifying a different bridge distribution in
torrc has no impact
3. Using the line "ServerTransportListenAddr obfs4 [2345:bad:face::]:4321"
(i.e. specifying the externally reachable IPv6) has the following effects:
- The respective bridge line for obfs4 using the IPv6 works well, you can
immediately use the bridge line in TBB- In metrics and
https://bridges.torproject.org/status?id=<hashed fingerprint>, the bridge is
shown as "functional"- The bridge distribution method shown in metrics stays
forever as "none", even specifying a different bridge distribution in torrc has
no impact
HOWEVER - the "observation time window" may be "too short" / "impacted by an
independent issue":
We've had in the recent past a couple of times the issue, that the distribution
method for bridges wasn't updated for more than one week !See e.g. this bridge
E80088962F97FE190D734D67E0C656C2A6EADEE7, which is an ordinary webtunnel bridge
without any special config, (re-)created by me mid of last week.It still shows
"none" as distribution method and therefore does not get any traffic at all.
Also in other cases, manually setting the bridge distribution method in torrc
on other bridges does not seem to have any impact right now.
So it could very well be, that there is a general issue with bridge
distribution method not being updated, which in fact has nothing to do with the
above observations?@meskio - is there a general issue with bridge distribution
not being updated again?
So to summarize again, we have two topics:
A. Not possible to properly advertise an obfs4 bridge bound to an internal
class-A IPv4B. Potential/unclear issue of bridge distribution not being
updated, which either is an unrelated general issue currently affecting all
bridges, or specifically related to the above described observations.
Regards, C.
Am 06.08.2025 um 23:59, "Gary C. New via tor-relays"
<[email protected]> schrieb:
C:
To confirm... Configuration of the ORPort with Internal NoAdvertise IPv4 and
External IPv6 Advertise enables the Bridge Status functional? However, the
issue with the Bridge Distribution Mechanism remaining "None" is still not a
viable solution?
Respectfully,
G
On Tuesday, August 5, 2025 at 12:30:03 PM MDT, C. Pe. via tor-relays
<[email protected]> wrote:
Hello all,
I can give an update:
This example config for an OBFS4 Bridge behind IPv4-NAT using secondary
IPv4+IPv6 seems to fully work (as you may have noticed, the example values of
external IPv6 and IPv6 obviously are nonsense):
BridgeRelay 1
ORPort 7.8.9.10:1234 NoListen
ORPort 10.0.0.7:1234 NoAdvertise
ORPort [2345:bad:face::]:1234
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 [2345:bad:face::]:4321
ExtORPort auto
ContactInfo [email protected]
Nickname MyCoolBridge
As you can see, ...- it uses Non-NAT secondary IPv6 for the bridge line- The
Address statement previously discussed isn't necessary.
HOWEVER:When I use the below statement instead (tested with a brand-new bridge)
- hence the class-A internal IP for the port binding:ServerTransportListenAddr
obfs4 10.0.0.7:4321
the following can be observed:
1. Using the bridge line "obfs4 7.8.9.10:4321 <fingerprint> cert=<cert>
iat-mode=0" in the TOR Browser works perfectly fine
2. The bridge in metrics.torproject.org is shown with Transport protocols
"none" !
3. The page https://bridges.torproject.org/status?id=<hashed fingerprint> shows
"vanilla IPv4: functional"
The real-life example of my test is hashed fingerprint
50ACF3A9AF5A7980F4CFE6CF5F9B27E56B2E72EB
So my question to the experts:
- Is an IPv4 via NAT using a secondary IPv4 simply not foreseen/considered with
obfs4proxy?- Or is there a special (unknown to me) setting, maybe via
"ServerTransportOptions obfs4 <...?...>" in torrc to be set?
Looking forward to your reply. (Depending on it, I may have to convert it to an
obfs4 IPv6 bridge)
Thanks & regards, C.
Am 31.07.2025 um 22:09, "C. Pe. via tor-relays"
<[email protected]> schrieb:
Many thanks for the reply.
Thanks for the hint with the status check - it shows what I was suspecting
already, that my bridge is "dysfunctional", despite the config outlined in my
previous mail.
> I think you can reduce this by just:
> ORPort 1234Not exactly: "ORPort 1234" results in the below
> bindings:0.0.0.0:1234[::]:1234
whilst
ORPort 10.0.0.7:1234 NoAdvertise
ORPort [2345:bad:face::]:1234result in the below, intended bindings, which
leaves those posts free for the other IPs:10.0.0.7:1234
[2345:bad:face::]:1234And when I omit the "ORPort 7.8.9.10:1234 NoListen"
statement, then - despite the "Address 7.8.9.10" statement - I get the log line
below:External address seen and suggested by a directory authority: <the
default IPv4 address, which I don't want to use>
Those statements work perfectly well for a relay. But to me it seems, that the
obfs4 transport has a problem:* obfs4 IPv4: dysfunctional Error: Bridge
address is not valid Last tested: 2025-07-30 16:23:09.776330892 +0000 UTC
m=+115200.406981514 (26h41m55.597470102s ago)
It seems that NAT in combination with a secondary IPv4 creates issues with the
obfs4 transport. As said, my (intended) bridge line works in my browser,
but BridgeDB can't parse the proper bridge (i.e. obfs4) address, maybe it
parses the class-A private IP (which obviously won't work at all)?
I assume that an IPv6 obfs4 should work (I'll try now), but maybe there is a
ServerTransportOptions setting dealing with the needed IPv4 mapping?Or is the
combo NAT plus secondary IPv4 simply not possible for obfs4proxy ?
Regards, C.
Am 31.07.2025 um 13:12, meskio via tor-relays <[email protected]>
schrieb:
Quoting C. Pe. via tor-relays (2025-07-30 22:17:02)
> 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
I think you can reduce this by just:
ORPort 1234
As I believe Adress and OutboundBindAddress will do the rest for you. But
others
here might have a better torrc-fu than me.
>
> 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 [email protected]
> 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?
I think this configuration is correct. The published address will be the one
set
in the Address.
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.
--
meskio | https://meskio.net/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
My contact info: https://meskio.net/crypto.txt
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Sent with https://mailfence.com
Secure and private email
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Sent with https://mailfence.com
Secure and private email
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Sent with https://mailfence.com
Secure and private email
_______________________________________________
tor-relays mailing list -- [email protected]
To unsubscribe send an email to [email protected]
