On 5/10/20 19:39, Mike Dillinger wrote:
Thanks for the expeditious response!
Xbox wants the following ports open: 88 (UDP), 3074 (UDP and TCP), 53
(UDP and TCP), 80 (TCP), 500 (UDP), 3544 (UDP), 4500 (UDP). 53 and 80
are for outgoing only as far as I know, so we're really focused on 88,
3074, 500, 3544, and 4500. I know when the ports were closed, many of
the multiplayer features didn't work. For instance, joining a group
game and in-game chat were two of them. Once the ports were opened,
everything worked great.
Now add a second console and the need to mimic the behavior. That seems
to be the challenge. I don't know how to get incoming NAT to route
properly to the source Xbox, and specifically when both are up and
running at the same time. Changing ports is not an option since
Microsoft controls the ports. To my knowledge, I can't change incoming
ports on the console nor can I change the ports coming from the WAN side.
I have only one public IPv4 address.
-MikeD
So the way NAT works for outgoing connections is that the first packet
of the connection has a 5-tuple, e.g. UDP 192.168.0.2:12345 to
203.0.113.53:53, and the NAT translates it to a different one, e.g. UDP
198.51.100.42:12345 (your public IP) to 203.0.113.53:53. Then when a UDP
packet comes back from 203.0.113.53:53 to 198.51.100.42:12345, the NAT
knows to forward it to 192.168.0.2:12345.
If at the same time it sees a UDP packet from 192.168.0.3:34567 to
8.8.8.8:53, it'll translate that to 198.51.100.42:34567 and everything
is fine. It can tell the difference between packets from 203.0.113.53:53
because they'll either be to 198.51.100.42:12345 or 198.51.100.42:23456
and thereby know where to forward it. Even if the original packet is
from 192.168.0.3:12345, then it'll translate the port too and use e.g.
198.51.100.42:12346 and still have an unambiguous translation.
For incoming connections, that doesn't work. The first packet is from
the remote peer. You get a packet from UDP 192.0.2.10:12345 to
198.51.100.42:4500, which internal host should it go to? There is no
connection tracking entry yet and now the first packet doesn't contain
the address of either internal host.
The normal solution to this is to either use a different public IP
address or a different port for each internal host. Alternative
solutions are inherently protocol-specific and not even guaranteed to
actually exist. I don't know anything specific to tell you about what
protocol(s) Xbox uses. There doesn't appear to be a conntrack helper for
this.
The simplest solution if it really has to use specific ports is to get
another public IP address. ISPs often offer these on business-class
connections, or you may be able to get one from a VPN provider.
