* nftables NAT & Gaming Consoles
@ 2020-05-10 21:19 Mike Dillinger
2020-05-10 21:37 ` zrm
0 siblings, 1 reply; 4+ messages in thread
From: Mike Dillinger @ 2020-05-10 21:19 UTC (permalink / raw)
To: netfilter
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nftables NAT & Gaming Consoles
2020-05-10 21:19 nftables NAT & Gaming Consoles Mike Dillinger
@ 2020-05-10 21:37 ` zrm
[not found] ` <d7d787bb-6e8b-2657-eca7-3c98a1b3d8ee@softtalker.com>
0 siblings, 1 reply; 4+ messages in thread
From: zrm @ 2020-05-10 21:37 UTC (permalink / raw)
To: Mike Dillinger, netfilter
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nftables NAT & Gaming Consoles
[not found] ` <d7d787bb-6e8b-2657-eca7-3c98a1b3d8ee@softtalker.com>
@ 2020-05-11 0:10 ` zrm
2020-05-11 15:01 ` Mike Dillinger
0 siblings, 1 reply; 4+ messages in thread
From: zrm @ 2020-05-11 0:10 UTC (permalink / raw)
To: Mike Dillinger, netfilter
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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: nftables NAT & Gaming Consoles
2020-05-11 0:10 ` zrm
@ 2020-05-11 15:01 ` Mike Dillinger
0 siblings, 0 replies; 4+ messages in thread
From: Mike Dillinger @ 2020-05-11 15:01 UTC (permalink / raw)
To: zrm, netfilter
> 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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-05-11 15:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-10 21:19 nftables NAT & Gaming Consoles Mike Dillinger
2020-05-10 21:37 ` zrm
[not found] ` <d7d787bb-6e8b-2657-eca7-3c98a1b3d8ee@softtalker.com>
2020-05-11 0:10 ` zrm
2020-05-11 15:01 ` Mike Dillinger
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.