hbbs sends local network IP instead of WAN IP, causing connection to hbbr to fail

[doragasu]

I have deployed hbbs and hbbr on a RPi board at home, and installed RustDesk on several machines on the local network.

When I run the client on the same local network everything works great. I can connect to any machine, no problem. But if I run the client from outside my local network, connection to hbbs succeeds but connection to hbbr fails, even though all related ports are open and NATed on the router. I have been diagnosing the problem using Wireshark on the machine running the client doing the connection, and the problem is the connetion to hbbs uses the correct global IP address (e.g. 37.123.123.123:21115) but the hbbr connection uses a local IP address (e.g. 192.168.229.32:21117).

This is a Wireshark capture taken on the client and showing the problem:

At first, I thouth my problem could be related to this: NAT Loopback issues. But since I'm also running pi-hole on the server machine, I tried method 2 without success, same behavior.

Also tried manually starting hbbs with -r WAN_IP_OF_HBBR, but again it didn't work. And I'm out of ideas.

How can I make sure hbbs sends the WAN IP instead of the local IP? Is this configuration not supported? Am I missing some config to achieve this?

[Niko11111]

Same issue here. Running hbbs/hbbr on a Raspberry Pi 4 behind a consumer router (NAT). External clients can reach hbbs successfully, but the relay connection always fails because hbbs sends the local LAN IP (e.g. 192.168.x.x) instead of the public WAN IP to the client.

Tested with:
• network_mode: host in Docker compose
• -r flag
• -R flag
• RELAY_SERVER= environment variable

None of these caused hbbs to send the correct external address. Verified via tcpdump on the Pi – the relay address in the hbbs response packet always contains the local LAN IP.

Workaround: Installed Tailscale on all devices (Pi, Mac, PC). With all clients pointing to the Pi’s Tailscale IP (100.x.x.x) as both ID and relay server, the connection works perfectly and performance is excellent.
This seems like a fundamental limitation when self-hosting behind NAT. A proper fix would be a reliable flag or env variable that forces hbbs to advertise a specific external address for the relay.