nftables NAT & Gaming Consoles

nftables NAT & Gaming Consoles

[Mike Dillinger]

Hello,

I tried to research this on the Internet, even using iptables, and I couldn't find anything conclusive so I thought I'd ask here.  There are conflicting reports regarding if this will work or not.

We have recently acquired a second Xbox and they will need to co-exist behind our nftables firewall.  We have an IPv4 setup on both sides (ISP/WAN, LAN) using NAT.  If both consoles are up and running at the same time, we need a way for NAT'd traffic to be routed to the proper console.

If I were to take a guess, I'm going to assume I need to mark packets using the nftables meta command, but I'm not sure.  I am assuming a generic NAT setup will not work for both consoles.

If I could get a starter example, I think I can take it from there. I can even take a working iptables example and migrate it to nftables using iptables-translate.

Thanks a lot!
-MikeD

Re: nftables NAT & Gaming Consoles

[zrm]

On 5/10/20 17:19, Mike Dillinger wrote:
> Hello,
> 
> I tried to research this on the Internet, even using iptables, and I 
> couldn't find anything conclusive so I thought I'd ask here.  There are 
> conflicting reports regarding if this will work or not.
> 
> We have recently acquired a second Xbox and they will need to co-exist 
> behind our nftables firewall.  We have an IPv4 setup on both sides 
> (ISP/WAN, LAN) using NAT.  If both consoles are up and running at the 
> same time, we need a way for NAT'd traffic to be routed to the proper 
> console.
> 
> If I were to take a guess, I'm going to assume I need to mark packets 
> using the nftables meta command, but I'm not sure.  I am assuming a 
> generic NAT setup will not work for both consoles.
> 
> If I could get a starter example, I think I can take it from there. I 
> can even take a working iptables example and migrate it to nftables 
> using iptables-translate.
> 
> Thanks a lot!
> -MikeD

I assume you're referring to incoming traffic, since in most ordinary 
network configurations you don't have to do anything special for 
outgoing traffic outside of the existing SNAT/MASQUERADE rule you 
probably already have. When one of the devices makes an outgoing 
connection, it gets a conntrack entry on the router which tells it where 
to translate reply packets. (You can watch this happen with 'conntrack 
-E' on the router).

For incoming traffic you would forward a port, which if you already have 
for your existing console, you just do the same thing for the other one, 
using a different port. Forward port 12345 to one console and port 12346 
to the other one. Then the port identifies which console gets the 
incoming connection.

This only gets really complicated if they both for some reason have to 
use the same port and you only have one public IPv4 address, but that's 
usually not the case.

Re: nftables NAT & Gaming Consoles

[zrm]

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.

Re: nftables NAT & Gaming Consoles

[Mike Dillinger]

> 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.

Thank you very much for the info.

 From my understanding, this is not an issue with IPv6 so I may enable IPv6 and try it out, although there may be other headaches associated with that.  I am also not sure if some of my older network devices support IPv6 so I'm likely looking at a hybrid LAN if I go in that direction.  My ISP supports IPv6 so the WAN side should be covered.  I'll have to think about this.  Thanks again.

-MikeD