"Bridge address is not valid" error

Hello,

I’ve created a new Tor bridge in a FreeBSD jail, but the bridge status page tells me:

Bridge 4AD2EEA276C672B07B34E979A6109B97632ACA62 advertises:

* obfs4 IPv4: dysfunctional
  Error: Bridge address is not valid
  Last tested: 2025-11-24 01:44:16.48515592 +0000 UTC m=+457200.694247420 (16m23.431500714s ago)

The configuration is basically the same as what appears in the instructions for a FreeBSD bridge:

RunAsDaemon 1
BridgeRelay 1

# Replace "TODO1" with a Tor port of your choice.  This port must be externally
# reachable.  Avoid port 9001 because it's commonly associated with Tor and
# censors may be scanning the Internet for this port.
ORPort 9846 IPv4Only

ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy

# Replace "TODO2" with an obfs4 port of your choice.  This port must be
# externally reachable and must be different from the one specified for ORPort.
# Avoid port 9001 because it's commonly associated with
# Tor and censors may be scanning the Internet for this port.
ServerTransportListenAddr obfs4 0.0.0.0:9921

# Local communication port between Tor and obfs4.  Always set this to "auto".
# "Ext" means "extended", not "external".  Don't try to set a specific port
# number, nor listen on 0.0.0.0.
ExtORPort auto

# Replace "<address@email.com>" with your email address so we can contact you if
# there are problems with your bridge.  This is optional but encouraged.
ContactInfo REDACTED

# Pick a nickname that you like for your bridge.  This is optional.
#Nickname PickANickname

Log notice file /var/log/tor/notices.log

I think the only substantive change I’ve made to that config is setting the port numbers and adding IPv4Only, since the jail doesn’t have IPv6 configured and it was failing to start without that because it was trying to create an IPv6 listener.

I should note that this host is behind NAT, so the system’s IP address is in private IP space, and is not its public IP address. The public IP address is also dynamic, so although I can build some automation to reconfigure Tor and restart when it changes, it would be great if it’s possible for Tor to handle that gracefully on its own. I do have both the ORPort and obfs4 ports successfully forwarded, as confirmed by both the Tor TCP Reachability Test as well as my own testing from remote hosts opening the raw sockets.

I’ve tried several variations, including a different ORPort configuration:

ORPort 9846 IPv4Only
Address <DNS_NAME_OF_MY_HOST>

Alternately, I tried:

ORPort <PUBLIC_IP_OF_MY_HOST>:9846 NoListen
ORPort <LOCAL_IP_OF_MY_HOST>:9846 NoAdvertise

…but despite leaving for a few hours, neither resolved the error on the bridge status page.

I did find this similar post here, but its solution is already included in the configuration I’m using now.

Can anyone advise on what the correct configuration is for a bridge behind NAT is? I’ve exhausted all the suggestions I can find by searching and world appreciate any help. Thank you!

Hey!

I’m still learning the bridge side of things too, but happy to share what I’ve seen so far.

When a bridge is behind NAT, Tor usually needs to know the external address it should advertise — otherwise the checkers see the private IP and mark it as invalid. The two reliable fixes I’ve seen are:

1. Set Address <your-dns-name>, making sure that DNS record always resolves to your current public IP. Tor will advertise that instead of the internal jail IP.

2. Or set ORPort <public-ip>:9846 NoListen together with a local ORPort … NoAdvertise, but Tor still needs to detect or be told a routable address. Without that, obfs4 ends up publishing a non-public IP and fails the “bridge address is not valid” check.

Since your IP is dynamic, a hostname + update script tends to work more smoothly.

Hope that helps — still learning myself but happy to help…

~shdwcodr

Thank you for your reply! I went ahead and added the Address line as you suggested, first with a public DNS name that resolves to the public IP, then after a few days when that still didn’t work I tried just the public IP address itself, but neither changed the error I see on the bridge status page.

So, my current config is:

RunAsDaemon 1
BridgeRelay 1
ORPort 9018 IPv4Only
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:8329
ExtORPort auto
ContactInfo <REDACTED_EMAIL>
Log notice file /var/log/tor/log
Address <PUBLIC_IP_OF_MY_HOST>

In case it’s helpful, the logs after startup are:

Nov 27 10:03:23.000 [notice] Tor 0.4.8.21 opening log file.
Nov 27 10:03:23.087 [notice] We compiled with OpenSSL 30000100: OpenSSL 3.0.16 11 Feb 2025 and we are running with OpenSSL 30000100: 3.0.16. These two versions should be binary compatible.
Nov 27 10:03:23.089 [notice] Tor 0.4.8.21 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 3.0.16, Zlib 1.3.1, Liblzma 5.8.1, Libzstd 1.5.7 and BSD 1403000 as libc.
Nov 27 10:03:23.089 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Nov 27 10:03:23.089 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Nov 27 10:03:23.091 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Nov 27 10:03:23.093 [notice] Opening Socks listener on 127.0.0.1:9050
Nov 27 10:03:23.093 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
Nov 27 10:03:23.093 [notice] Opening OR listener on 0.0.0.0:9018
Nov 27 10:03:23.093 [notice] Opened OR listener connection (ready) on 0.0.0.0:9018
Nov 27 10:03:23.093 [notice] Opening Extended OR listener on 127.0.0.1:0
Nov 27 10:03:23.093 [notice] Extended OR listener listening on port 30547.
Nov 27 10:03:23.093 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:30547
Nov 27 10:03:23.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Nov 27 10:03:23.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Nov 27 10:03:23.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Nov 27 10:03:24.000 [notice] Set list of supported TLS groups to: P-256:X25519:P-224
Nov 27 10:03:24.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed AF808B68D33405E241F107E3830A51B0A1F2CCD4'
Nov 27 10:03:24.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'Unnamed 4AD2EEA276C672B07B34E979A6109B97632ACA62'
Nov 27 10:03:24.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'Unnamed 99HzH2RVN4q6mOJWEbvBFPlZS/+q8Ue2WNMbAWF6eps'
Nov 27 10:03:24.000 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=4AD2EEA276C672B07B34E979A6109B97632ACA62
Nov 27 10:03:24.000 [notice] Bootstrapped 0% (starting): Starting
Nov 27 10:03:25.000 [notice] Starting with guard context "default"
Nov 27 10:03:34.000 [notice] Registered server transport 'obfs4' at '<LOCAL_IP_OF_MY_HOST>:8329'
Nov 27 10:03:35.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Nov 27 10:03:35.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Nov 27 10:03:35.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Nov 27 10:03:36.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Nov 27 10:03:36.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Nov 27 10:03:36.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Nov 27 10:03:36.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Nov 27 10:03:36.000 [notice] Bootstrapped 100% (done): Done
Nov 27 10:03:36.000 [notice] Now checking whether IPv4 ORPort <PUBLIC_IP_OF_MY_HOST>:9018 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Nov 27 10:03:37.000 [notice] Self-testing indicates your ORPort <PUBLIC_IP_OF_MY_HOST>:9018 is reachable from the outside. Excellent. Publishing server descriptor.
Nov 27 10:11:36.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
Nov 27 10:12:39.000 [notice] Performing bandwidth self-test...done.
Nov 27 11:33:48.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 124 buildtimes.
Nov 27 16:03:35.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 1 circuits open. I've sent 3.48 MB and received 17.10 MB. I've received 22 connections on IPv4 and 0 on IPv6. I've made 16 connections with IPv4 and 0 with IPv6.
Nov 27 16:03:35.000 [notice] While not bootstrapping, fetched this many bytes: 13961919 (server descriptor fetch); 360 (server descriptor upload); 368560 (consensus network-status fetch); 101760 (microdescriptor fetch)
Nov 27 16:03:35.000 [notice] Heartbeat: Since last heartbeat message, I have seen 22 unique clients.
Nov 27 22:03:35.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 0 circuits open. I've sent 5.26 MB and received 25.69 MB. I've received 23 connections on IPv4 and 0 on IPv6. I've made 30 connections with IPv4 and 0 with IPv6.
Nov 27 22:03:35.000 [notice] While not bootstrapping, fetched this many bytes: 20472836 (server descriptor fetch); 729 (server descriptor upload); 644852 (consensus network-status fetch); 270547 (microdescriptor fetch)
Nov 27 22:03:35.000 [notice] Heartbeat: Since last heartbeat message, I have seen 1 unique clients.
Nov 27 23:54:40.000 [warn] Detected possible compression bomb with input size = 18781 and output size = 507533 (compression factor = 27.02)
Nov 27 23:54:40.000 [warn] Possible compression bomb; abandoning stream.
Nov 27 23:54:40.000 [warn] Unable to decompress HTTP body (tried Zstandard compressed, on Directory connection (client reading) with 185.80.30.102:9001).
Nov 27 23:54:40.000 [warn] Detected possible compression bomb with input size = 18944 and output size = 509073 (compression factor = 26.87)
Nov 27 23:54:40.000 [warn] Possible compression bomb; abandoning stream.
Nov 28 04:03:35.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 0 circuits open. I've sent 7.35 MB and received 38.70 MB. I've received 23 connections on IPv4 and 0 on IPv6. I've made 44 connections with IPv4 and 0 with IPv6.
Nov 28 04:03:35.000 [notice] While not bootstrapping, fetched this many bytes: 28986449 (server descriptor fetch); 1082 (server descriptor upload); 965050 (consensus network-status fetch); 2714521 (microdescriptor fetch)
Nov 28 04:03:35.000 [notice] Heartbeat: Since last heartbeat message, I have seen 0 unique clients.
Nov 28 10:03:35.000 [notice] Heartbeat: Tor's uptime is 1 day 0:00 hours, with 0 circuits open. I've sent 9.23 MB and received 49.46 MB. I've received 24 connections on IPv4 and 0 on IPv6. I've made 61 connections with IPv4 and 0 with IPv6.
Nov 28 10:03:35.000 [notice] While not bootstrapping, fetched this many bytes: 37012446 (server descriptor fetch); 1436 (server descriptor upload); 1276332 (consensus network-status fetch); 3474160 (microdescriptor fetch)
Nov 28 10:03:35.000 [notice] Heartbeat: Since last heartbeat message, I have seen 1 unique clients.

Hey, thanks for the update — super helpful info.

From what you’ve tried so far, the ORPort looks fine (Tor even says it’s reachable), so the issue is probably on the obfs4 side. The part that stands out is this line:

Registered server transport 'obfs4' at '<LOCAL_IP>:8329'

That usually means Tor is still advertising the internal IP for obfs4 instead of your public one, which will make BridgeDB mark it as invalid.

A couple things to try/check:

1. Force obfs4 to use the public IP
Sometimes Tor doesn’t automatically pick it up, so you can help it along with:

ServerTransportListenAddr obfs4 0.0.0.0:8329
ServerTransportOptions obfs4 extorport=auto

Plus keep your Address <public-ip-or-dns> (which you already set).

2. Double-check your NAT/firewall
Even if 9018 works, 8329 might not be forwarded the same way. obfs4 failing reachability is a super common cause of the status page errors.

3. Might need a fresh identity
If you changed the Address after the relay was already running, BridgeDB sometimes hangs onto the old descriptor. If you don’t mind losing the current fingerprint, nuking the keys/ directory forces Tor to republish cleanly.

If you want, feel free to paste the exact message from the status page — that usually narrows down whether it’s an address mismatch or obfs4 reachability.

Happy to dig into it more if you want!

~shdwcodr

Thanks for your continued help! I really appreciate it.

I went ahead and added the line you suggested:

ServerTransportOptions obfs4 extorport=auto

(The ServerTransportListenAddr line you mentioned is already present in my config.) I checked the ability to open both ports from the outside (using both Tor’s own TCP Reachability Test as well as just opening the socket with telnet from a different system elsewhere on the Internet), so my port forwarding appears to be working for both ports. I also deleted the keys/ directory, which I see from the logs did indeed prompt it to recreate its keys.

However, even after restarting and waiting a few hours, I’m still getting the same error from the bridge status page:

Bridge 802616772E0CD5C28C53C1F70A0A022EE661C6E3 advertises:

* obfs4 IPv4: dysfunctional
  Error: Bridge address is not valid
  Last tested: 2025-12-04 19:44:16.666453736 +0000 UTC m=+1386000.703135538 (22m21.833984522s ago)

And here are the latest logs:

Dec 04 11:15:51.000 [notice] Tor 0.4.8.21 opening log file.
Dec 04 11:15:51.695 [notice] We compiled with OpenSSL 30000100: OpenSSL 3.0.16 11 Feb 2025 and we are running with OpenSSL 30000100: 3.0.16. These two versions should be binary compatible.
Dec 04 11:15:51.698 [notice] Tor 0.4.8.21 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 3.0.16, Zlib 1.3.1, Liblzma 5.8.1, Libzstd 1.5.7 and BSD 1403000 as libc.
Dec 04 11:15:51.698 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Dec 04 11:15:51.698 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Dec 04 11:15:51.699 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 04 11:15:51.702 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 04 11:15:51.702 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
Dec 04 11:15:51.702 [notice] Opening OR listener on 0.0.0.0:9018
Dec 04 11:15:51.702 [notice] Opened OR listener connection (ready) on 0.0.0.0:9018
Dec 04 11:15:51.702 [notice] Opening Extended OR listener on 127.0.0.1:0
Dec 04 11:15:51.702 [notice] Extended OR listener listening on port 41314.
Dec 04 11:15:51.702 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:41314
Dec 04 11:15:52.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Dec 04 11:15:52.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Dec 04 11:15:52.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 04 11:15:52.000 [notice] You are running a new relay. Thanks for helping the Tor network! If you wish to know what will happen in the upcoming weeks regarding its usage, have a look at https://blog.torproject.org/lifecycle-of-a-new-relay
Dec 04 11:15:52.000 [notice] It looks like I need to generate and sign a new medium-term signing key, because I don't have one. To do that, I need to load (or create) the permanent master identity key. If the master identity key was not moved or encrypted with a passphrase, this will be done automatically and no further action is required. Otherwise, provide the necessary data using 'tor --keygen' to do it manually.
Dec 04 11:15:52.000 [notice] Set list of supported TLS groups to: P-256:X25519:P-224
Dec 04 11:15:52.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 9E6938F8D898693D8C6CE2E29C2C11CC104713F4'
Dec 04 11:15:52.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'Unnamed 802616772E0CD5C28C53C1F70A0A022EE661C6E3'
Dec 04 11:15:52.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'Unnamed slc3HfJTLLSlvZNcGNNwf+nQ+ckzOnEph4C7cDJlq1A'
Dec 04 11:15:52.000 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=802616772E0CD5C28C53C1F70A0A022EE661C6E3
Dec 04 11:15:52.000 [notice] Bootstrapped 0% (starting): Starting
Dec 04 11:15:53.000 [notice] Starting with guard context "default"
Dec 04 11:16:00.000 [notice] Registered server transport 'obfs4' at '<LOCAL_IP_OF_MY_HOST>:8329'
Dec 04 11:16:01.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Dec 04 11:16:01.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Dec 04 11:16:01.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Dec 04 11:16:01.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Dec 04 11:16:01.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Dec 04 11:16:01.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Dec 04 11:16:01.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Dec 04 11:16:02.000 [notice] Bootstrapped 100% (done): Done
Dec 04 11:16:02.000 [notice] Now checking whether IPv4 ORPort <PUBLIC_IP_OF_MY_HOST>:9018 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Dec 04 11:16:03.000 [notice] Self-testing indicates your ORPort <PUBLIC_IP_OF_MY_HOST>:9018 is reachable from the outside. Excellent. Publishing server descriptor.
Dec 04 11:34:02.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.
Dec 04 11:35:13.000 [notice] Performing bandwidth self-test...done.

The log line about Registered server transport 'obfs4' appears to have not changed, for what it’s worth: would we have expected the IP address to have changed to the public one as a result of the new ServerTransportOptions configuration?

Hey! Happy to help — I’m also learning this stuff, so we can debug it together :slight_smile:

From your logs, the key problem is this line:

Registered server transport 'obfs4' at '<LOCAL_IP>:8329'

Even after changing the config, obfs4 is still advertising your local/internal IP, and BridgeDB marks that as invalid. On FreeBSD that often happens — obfs4proxy can pick the wrong interface unless you force it.

Try adding these to your torrc (replace <PUBLIC_IP> with your real public IP or DNS name):

ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:8329
ServerTransportOptions obfs4 address=<PUBLIC_IP> port=8329
ServerTransportOptions obfs4 extorport=auto

That address=<PUBLIC_IP> forces obfs4 to publish the public address instead of auto-detecting.

Restart Tor and watch the logs (for example: tail -f /var/log/tor.log) — you should see:

Registered server transport 'obfs4' at '<PUBLIC_IP>:8329'

If that changes, BridgeDB should accept the bridge on the next test. If it still shows the local IP, let me know and we’ll try clearing transport-state and any cached descriptors and double-check outbound source IP settings.

We’ll solve it step by step — tell me what the logs show after the restart :slight_smile:

~shdwcodr

Unfortunately, that didn’t seem to change anything. I added the new line you suggested, so my config is now:

RunAsDaemon 1
BridgeRelay 1
ORPort 9018 IPv4Only
ServerTransportPlugin obfs4 exec /usr/local/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:8329
ServerTransportOptions obfs4 extorport=auto
ServerTransportOptions obfs4 address=<PUBLIC_IP> port=8329
ExtORPort auto
ContactInfo <MY_EMAIL>
Log notice file /var/log/tor/log
Address <PUBLIC_IP>

…but the bridge status is still:

Bridge 802616772E0CD5C28C53C1F70A0A022EE661C6E3 advertises:

* obfs4 IPv4: dysfunctional
  Error: Bridge address is not valid
  Last tested: 2025-12-06 06:44:16.592375969 +0000 UTC m=+1512000.629057770 (28m25.208569953s ago)

The logs are:

Dec 05 16:42:01.000 [notice] Tor 0.4.8.21 opening log file.
Dec 05 16:42:01.601 [notice] We compiled with OpenSSL 30000100: OpenSSL 3.0.16 11 Feb 2025 and we are running with OpenSSL 30000100: 3.0.16. These two versions should be binary compatible.
Dec 05 16:42:01.603 [notice] Tor 0.4.8.21 running on FreeBSD with Libevent 2.1.12-stable, OpenSSL 3.0.16, Zlib 1.3.1, Liblzma 5.8.1, Libzstd 1.5.7 and BSD 1403000 as libc.
Dec 05 16:42:01.603 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Dec 05 16:42:01.603 [notice] Read configuration file "/usr/local/etc/tor/torrc".
Dec 05 16:42:01.605 [notice] Based on detected system memory, MaxMemInQueues is set to 8192 MB. You can override this by setting MaxMemInQueues by hand.
Dec 05 16:42:01.607 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 05 16:42:01.607 [notice] Opened Socks listener connection (ready) on 127.0.0.1:9050
Dec 05 16:42:01.607 [notice] Opening OR listener on 0.0.0.0:9018
Dec 05 16:42:01.607 [notice] Opened OR listener connection (ready) on 0.0.0.0:9018
Dec 05 16:42:01.607 [notice] Opening Extended OR listener on 127.0.0.1:0
Dec 05 16:42:01.607 [notice] Extended OR listener listening on port 23046.
Dec 05 16:42:01.607 [notice] Opened Extended OR listener connection (ready) on 127.0.0.1:23046
Dec 05 16:42:02.000 [notice] Parsing GEOIP IPv4 file /usr/local/share/tor/geoip.
Dec 05 16:42:02.000 [notice] Parsing GEOIP IPv6 file /usr/local/share/tor/geoip6.
Dec 05 16:42:02.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 05 16:42:02.000 [notice] Set list of supported TLS groups to: P-256:X25519:P-224
Dec 05 16:42:02.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 9E6938F8D898693D8C6CE2E29C2C11CC104713F4'
Dec 05 16:42:02.000 [notice] Your Tor bridge's hashed identity key fingerprint is 'Unnamed 802616772E0CD5C28C53C1F70A0A022EE661C6E3'
Dec 05 16:42:02.000 [notice] Your Tor server's identity key ed25519 fingerprint is 'Unnamed slc3HfJTLLSlvZNcGNNwf+nQ+ckzOnEph4C7cDJlq1A'
Dec 05 16:42:02.000 [notice] You can check the status of your bridge relay at https://bridges.torproject.org/status?id=802616772E0CD5C28C53C1F70A0A022EE661C6E3
Dec 05 16:42:02.000 [notice] Bootstrapped 0% (starting): Starting
Dec 05 16:42:03.000 [notice] Starting with guard context "default"
Dec 05 16:42:11.000 [notice] Registered server transport 'obfs4' at '<PRIVATE_IP>:8329'
Dec 05 16:42:12.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
Dec 05 16:42:12.000 [notice] Bootstrapped 10% (conn_done): Connected to a relay
Dec 05 16:42:12.000 [notice] Bootstrapped 14% (handshake): Handshaking with a relay
Dec 05 16:42:13.000 [notice] Bootstrapped 15% (handshake_done): Handshake with a relay done
Dec 05 16:42:13.000 [notice] Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Dec 05 16:42:13.000 [notice] Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Dec 05 16:42:13.000 [notice] Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Dec 05 16:42:13.000 [notice] Bootstrapped 100% (done): Done
Dec 05 16:42:13.000 [notice] Now checking whether IPv4 ORPort <PUBLIC_IP>:9018 is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Dec 05 16:42:14.000 [notice] Self-testing indicates your ORPort <PUBLIC_IP>:9018 is reachable from the outside. Excellent. Publishing server descriptor.
Dec 05 17:00:13.000 [notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 628 buildtimes.
Dec 05 17:01:16.000 [notice] Performing bandwidth self-test...done.
Dec 05 22:42:12.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 3.05 MB and received 11.50 MB. I've received 25 connections on IPv4 and 0 on IPv6. I've made 13 connections with IPv4 and 0 with IPv6.
Dec 05 22:42:12.000 [notice] While bootstrapping, fetched this many bytes: 11850 (microdescriptor fetch)
Dec 05 22:42:12.000 [notice] While not bootstrapping, fetched this many bytes: 8258602 (server descriptor fetch); 361 (server descriptor upload); 312529 (consensus network-status fetch); 366253 (microdescriptor fetch)
Dec 05 22:42:12.000 [notice] Heartbeat: Since last heartbeat message, I have seen 25 unique clients.

Notably, the Registered server transport line still has the private IP, not the public one.

Do you have any other suggestions? Thanks again!

You’re super close — the issue is that obfs4proxy on FreeBSD keeps auto-detecting the wrong interface and ignores the address= option. That’s why it still shows your private IP.

A couple things to try that usually fix this:

1. Clear Tor’s cached transport state (important!)

service tor stop
rm -rf /var/db/tor/pt_state
service tor start

If Tor had already registered the transport once, it keeps using the old settings.

2. Replace ExtORPort auto with:

ExtORPort <PUBLIC_IP>:0

This helps obfs4proxy pick up the correct address from Tor.

3. Use the obfs4proxy override that works on BSD:

ServerTransportOptions obfs4 IPOverride=<PUBLIC_IP>

(Use that instead of address=.)

After restarting you should see:

Registered server transport ‘obfs4’ at ‘<PUBLIC_IP>:8329’

If it still shows the private IP after those three changes, post the new log line and we’ll keep digging.

~shdwcodr