Ip used in games list incorrect (Question)

[Ewoodss]

everything works fine i use dirrect connect, but if i try to connect via the gameslist it trys to connect to the wrong ip, this is a internal ip.

i am using your docker container inside kubernetes with a node port. is there a way to tell the halo server what the external ip is, because everything else works fine?

or is this a unsopperted use case?

[antimomentum]

there is an ip switch for haloceded.exe, just like its -path and -port switches. -IP I think. But I would not expect this to fix the issue.

it sounds like either the master server or the natneg server (or both) are unable to reach the halo server for some reason. When the halo server starts, even if it gives a local ip or wrong ip in the data segment, as long as packets are getting to and from the master and halo server it will still get the public ip that the master/natneg see the halo packets coming from.

In fact the halo server running in just a basic Docker setup sends a local ip of 127.0.0.1 to the master server in the data if I recall correctly, this is why I don't think the -IP haloceded switch will matter.

Sounds more like maybe a port or ip address translation issue this is usually the cause. When starting a halo server, i recommend capturing on each interface (real and virtual) to see where the packet gets dropped, examples: tshark -i eth0 and tshark -i docker0

I've also found these rules helpful, especially when doing a reverse proxy setup (without Docker). Perhaps if nothing else they'll offer some insight to the needed ports. Ignore the source ip this was a reverse proxy for a wine halo server:

iptables -t nat -A PREROUTING -s 10.0.0.2 -m length --length 59 -m udp -p udp --dport 27900 -j DNAT --to-destination 54.82.252.156:27900

iptables -t nat -A PREROUTING -s 10.0.0.2 -m udp -p udp --dport 27900 -j DNAT --to-destination 34.197.71.170:27900

Make sure the port of the halo server, and that 27900 port for both ips remain correct accross the interfaces.

I would bet when the halo server starts one of those ips (34.197.71.170 and 54.82.252.156) are getting lost in translation if not the port number. In which case a rule like this for the interface may help: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Ewoodss]

i am using the default config, i am running inside of kubernetes. the ip that gets listed in the gameview is the pods ip address. the game works great if i just type in my ip by hand, i am using the default port. setting the -IP flag didn't change anything.

i understand my use case is not pure docker so np keeping this closed.

[Ewoodss]

HaloDump.zip I made a network dump of the network traffic during startup of the server. in this you can see it sends the wrong ip address to 34.197.71.170. is there a way to intercept this traffic and replace it with the correct ip address. the gamebrowser uses the ip it gets send in this package and not the ip the packet is comming from. i will try to find a solution myself if you have any input that would be grately appreciated

[Ewoodss]

direct connect with my public ip does work. also when not on the same network tested using 4g network. only the game browser connection doesn't work when not on same network. i got it work when on the same network by switching to host networking but then the gamelist just advertises the local ip so it work's but only because i am on the same network.

[Ewoodss]

setting the -ip flag doesn't work because it can't bind to my public ip address because it's inside a container, so i get an error and no one can connect not even locally.

[antimomentum]

HaloDump.zip I made a network dump of the network traffic during startup of the server. in this you can see it sends the wrong ip address to 34.197.71.170. is there a way to intercept this traffic and replace it with the correct ip address. the gamebrowser uses the ip it gets send in this package and not the ip the packet is comming from. i will try to find a solution myself if you have any input that would be grately appreciated

The first thing I'm noticing from the pcap is that there are no packets received from 54.82.252.156 Both 34.197.71.170 and 54.82.252.156 are required to be allowed in order for the server be joinable from the server list.

In fact, what your halo server says the ip is does not matter and I'll show you a pcap of this, you'll notice my server in the container also sends 34.197.71.170 a local docker ip as well which is 172.17.0.2 in this case. halotest.zip (the halo server should also respond to that ip, I think I stopped the capture buffer short by accident)

I think a firewall is blocking the 54 ip thus preventing nat negotiation for your server. If you're running it from a home or cell ISP their firewalls are typically based on "established" connections meaning you have to send a packet to the ip before the ip is allowed to be received. Cloud servers that I run my server on do not typically have this automatic "established" firewall setting in place so this isn't an issue I run into despite halo saying it's using that local docker ip.

Also halo servers do get DDoS'd from time to time especially when full so I would NOT try to run one through a cell connection or you could end up facing large charges. Even with "unlimited" data you could get throttled. Running from home will expose your public ip as well.