This issue has been driving me insane! I have an OpenBSD box acting as a gateway with portforwarding to a Debian box to host Zandronum on, and I can verify that the forward works by manually connecting from the outside, but when I set my server to update to the master, I see my IP in the master server's list with a random port number, and (of course) no server info.
Does the master server decide which port a server is running on based on the source port the update comes from? If so, OpenBSD port randomization is probably causing this problem, and the master server should receive port number info from the server instead of by which port it came from. If this is the case, I'll file a bug report, because OpenBSD probably isn't the only NAT that randomizes ports. Any ideas?
Yep, it seems my guess was right.
If anyone else is running into this issue and using a pf-based firewall, I got things working by adding a new rule to my set before my normal nat rule:
match out on $ext_if from $doomserver to any nat-to ($ext_if) static-port
This issue also applies to skulltag. I'll write up a bug report on it, but for now, at least I have a workaround.
I've submitted it in the bug tracker at http://zandronum.com/tracker/view.php?id=992
Master server advertising the wrong port
Master server advertising the wrong port
Last edited by jummama on Sun Aug 26, 2012 6:18 pm, edited 1 time in total.
- Torr Samaho
- Lead Developer
- Posts: 1543
- Joined: Fri May 25, 2012 6:03 pm
- Location: Germany
RE: Master server advertising the wrong port
Yes. Why should the master take any other port on its own?jummama wrote: Does the master server decide which port a server is running on based on the source port the update comes from?
RE: Master server advertising the wrong port
Because of source port randomizing NAT. OpenBSD does this by default, and possibly FreeBSD, NetBSD, and anything else using OpenBSD's pf system. It's also possible that some consumer routers would do the same source randomization, and possibly without such a workaround available. What's happening is that Zandronum sends its packets from 10666 as expected for the master server, but pf on (at least) OpenBSD will send the packet on Zandronum's behalf from a random port with no relation, such as 60152. When this happens, the port forward for 10666 is ineffective because the master server ends up advertising the wrong port. Changing it so that Zandronum instructs the master server which port it's on would make it more robust for these situations, and it would still work fine under "normal" NAT. I'm not sure why this port randomization is default, but OpenBSD being "secure by default", I like leaving as many defaults in place as I can when possible.
If this becomes a won't fix, maybe I'll make a page on the wiki about the workaround because I couldn't find info anywhere about it, and I'm probably not the only one who has run into this issue.
Also, as I said before, with this randomization in place, the port forward still works and let's clients in. It's only the master server update that's affected.
If this becomes a won't fix, maybe I'll make a page on the wiki about the workaround because I couldn't find info anywhere about it, and I'm probably not the only one who has run into this issue.
Also, as I said before, with this randomization in place, the port forward still works and let's clients in. It's only the master server update that's affected.
Last edited by jummama on Sun Aug 26, 2012 7:10 pm, edited 1 time in total.
- Torr Samaho
- Lead Developer
- Posts: 1543
- Joined: Fri May 25, 2012 6:03 pm
- Location: Germany
RE: Master server advertising the wrong port
Let's do the technical discussion in your tracker ticket.
RE: Master server advertising the wrong port
Sorry, I saw the forum post and started writing that before I saw your ticket update. I'll continue on there.
- Torr Samaho
- Lead Developer
- Posts: 1543
- Joined: Fri May 25, 2012 6:03 pm
- Location: Germany
RE: Master server advertising the wrong port
No worries :).jummama wrote: Sorry, I saw the forum post and started writing that before I saw your ticket update.