NAT Hairpinning (Loopback) / Other networking issues

[pnill]

There's obvious issues with devices which don't support NAT Hair-pinning in several instances.

One of these instances is if you host your own game on your own network you're unable to join it whether it's on the same computer or another.

The second instance of this issue in theory I believe is when two people from the same network which has no NAT hair-pinning support attempt to join a game together which is not being hosted on their network. The reason I believe this happens is due to the peer-to-peer communication halo2 seems to establish between users, I have not been able to confirm this yet but it's a possibility.

My proposed fix for these issues is when any client is running we create a separate network thread responsible for sending broadcast packets over the local network and receive them and store data about them on the other systems. In theory what this would allow us to do is determine internal IPs and ports of other clients on the network.

The only time this wouldn't work is when NAT Translation takes place and the router gives the user a different destination port for their WAN address... we'd need a more intelligent way to map from that port to an internal IP address for clients. I guess more thought needs to go into this.

The only other option I could imagine is having user specific data such as the XNADDR also map the internal IP of the user. The problem with this is we would have to detect the internal address of the user and with multiple network adapters this may fail (though halo 2 allows you to specify which network adapter it should use, so maybe we can detect which is selected).

This requires some more thought, on a moderate NAT it's possible that we talk to a remote server to get the port the client is using externally and map that to the WAN address for this specific client... then use that information to deliver it to other clients on the same network and assume WANIP+PORT = X Internal client. On a strict NAT however only the host we contacted would be able to contact the client back on that port meaning when connecting to other systems or ports it would most likely use a different port each time in NAT translation.

Regardless my current plan for fixing this is some how having clients tell each other about them selves on the local network so they're capable of translating the data in a way that it would avoid having to communicate through their WAN address avoiding NAT Hairpinning (Loopback) all together.

[iSupersniper]

Issue exists between client and dedi on same network.