Directory ignores --serverpublicip for servers behind a UDP proxy or load balancer

[stefan1000]

Describe the bug
--serverpublicip is ignored when a server registers through a UDP proxy or load balancer. The directory always advertises the backend's UDP source IP instead of the declared one, making the server unreachable for clients.

Seems historically --serverpublicip was only added for the same network use case, but I think it should be a general option to register with a given public IP.

To Reproduce

1. Put a Jamulus server behind a UDP proxy/LB
2. Register with a directory using --serverpublicip <your-public-ip>
3. Check what IP clients receive in the server list — it's the backend source IP, not the one you passed

Expected behavior
Clients get the IP from --serverpublicip.

Screenshots
N/A

Operating system
N/A — directory-side logic issue, OS independent

Version of Jamulus
3.11

Additional context
Root cause is in CServerListManager::RetrieveAll: the wantHostAddr condition always resolves to true for an external client + external server, so LHostAddr (where --serverpublicip ends up) is never consulted.

LHostAddr should take precedence when it is set to a public IP, bypassing the normal routing logic.

Something like an "hasExplicitPublicOverride" (serverlist.cpp):

bool hasExplicitPublicOverride =
    siCurListEntry.LHostAddr.InetAddr != CHostAddress().InetAddr &&
    !NetworkUtil::IsPrivateNetworkIP ( siCurListEntry.LHostAddr.InetAddr );

bool wantHostAddr = !hasExplicitPublicOverride &&
                    ( clientIsInternal ||
                      ( !serverIsInternal &&
                        InetAddr.InetAddr != siCurListEntry.HostAddr.InetAddr ) );```

[pljones]

I currently host a number of the public Directories and run several Servers. That's pretty much why the option exists, if I remember correctly. (So the Servers and Directories are all on the same LAN but all need exposing with the external IP, which then uses port-mapping to get to the right place.)

Can you try that set up out with your proposed fix to make sure nothing would break?

Also any changes should be made to the latest version main.

[softins]

@stefan1000 I'd like to understand why you need to use --serverpublicip at all? If your server is registering with a directory that is external to you, the directory will set your IP:port directly from the source IP address and port of the Register message it receives, and doesn't need the server to specify a public IP manually.

If just omitting --serverpublicip doesn't work for you, please could you explain the detail of your setup and the way in which it doesn't work?

[stefan1000]

@softins it is about situations where I want to direct clients to a specific IP to connect to my server, this is not necessarily the IP the registration requests comes from. Consider a setup with a layer 4 UDP load balancer with IP A and a jamulus server in the backend pool with IP B, which is not reachable via B:22124, only the front door is (A:22124). I dont want to open ports on the backend machine, everything is routed via the UDP LB in front. To me "--serverpublicip" was about this use case, basically saying "dont use the IP from UDP, I tell you where to connect to my server".

Looking at the code it has a restriction to only allow this override if server & directory are on the same network, but it is ok to broaden this check to just allow it whenever the servers registration message is advertising for a specific IP. I dont think it affects existing functionality, it was just the initial implementation was very focused on this one use case.

(I am currently testing the setups under different topologies)

[pljones]

You're needing to fit in with this (i.e. explain where you'd change things but not break it):

option	usage
--port	sets the port the server listens to locally
--serverbindip	sets the IP the server listens to locally
--serverpublicip	sets the public IP where server and directory are on the same LAN

Manual port forwarding is not supported: the internal port must be open to external requests. Where a router modem does automatic port forwarding, directory pings MAY open the server to requests from clients not on the same LAN as the directory.

• PROTMESSID_CLM_SERVER_LIST:

  • SERVER internal to DIRECTORY (list entry external IP same LAN)
    • CLIENT internal to DIRECTORY (CLM msg same LAN): use "external" fields (local LAN address)
    • CLIENT external to DIRECTORY (CLM msg not same LAN): use "internal" fields (registered server public IP)
  • SERVER external to DIRECTORY (list entry external IP not same LAN)
    • CLIENT internal to SERVER (CLM same IP as list entry external IP): use "internal" fields (local LAN address)
    • CLIENT external to SERVER (CLM not same IP as list entry external IP): use "external" fields (public IP address from protocol)

• PROTMESSID_CLM_REGISTER_SERVER

  • As SERVER create CLM message using "internal" fields (IP layer is the "external" fields):
    • DIRECTORY not on my LAN: self-determined IP address and --port value
    • DIRECTORY on my LAN: --serverpublicip IP address and --port value
  • As DIRECTORY store received CLM message as is (IP layer address is used to access the server list)