[tor-relays] QUESTION: OBFS4 on secondary IP and NAT

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@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

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 johndoe@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?

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=&lt;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 -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

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 1234

Not 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::]:1234

result in the below, intended bindings, which leaves those posts free for the other IPs:

10.0.0.7:1234
[2345:bad:face::]:1234

And 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 tor-relays@lists.torproject.org 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 [johndoe@nowhere.org](mailto:johndoe@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?

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](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](https://meskio.net)/
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 My contact info: [https://meskio.net/crypto.txt](https://meskio.net/crypto.txt)
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Nos vamos a Croatan.
_______________________________________________
tor-relays mailing list -- [tor-relays@lists.torproject.org](mailto:tor-relays@lists.torproject.org)
To unsubscribe send an email to [tor-relays-leave@lists.torproject.org](mailto:tor-relays-leave@lists.torproject.org)


Sent with https://mailfence.com
Secure and private email

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= 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@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](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