So Christmas has come and gone a few days ago and if you’re anything like me, which if you’re reading this blog you probably are, then you might have gotten yourself or kids a new gaming console. I personally bought an Xbox Series S for my kids [read me] and spend the day after Christmas getting it all set up. I have to give Microsoft some credit here, they really made setting up the Xbox a simple process now. There’s no more trying to sign in by putting in a password on a screen keyboard, everything can be done from the phone app, but that’s besides the point. If you were like me you might have been a bit shocked to see your brand new Xbox get hit with the dreaded “NAT Type Strict” message. I knew what this message meant but I never really knew what caused it or how to fix it, so I did some research and discovered that it’s actually not that complicated.
For those of you who aren’t familiar there are three types of “NAT Types” for Xbox and PlayStation; Open, Moderate, and Strict (or as PlayStation puts it 1, 2, and 3 respectively). These “NAT Types”, and yes I’m putting NAT Types in quotes it’s not really a thing but they keep using the term, correspond to how connected your Xbox is to the network. Or more specifically they refer to how easy it will be for the Xbox to use Peer-to-Peer services. Ok, some background time.
Client-Server or P2P, What’s the Difference.
There are two main systems of communication that your Xbox uses when it’s using the Internet; client-server and Peer-to-Peer (P2P) but “NAT Type” really only affects one of them.
Client-Server Model
This is the “newer” model for gaming but it’s existed in computing for a long time. With the Client-Server model all of the clients (Xboxs) send their data to server which collects it all, correlates it, merges it, and then redistributes the merged data back to the clients.
Think about it like this; in a video game your character is in position X and my character is in position Y. Our individual positions are being processed on our individual machines with no knowledge of the location of the other person. Your Xbox sends a message to the server saying that you are at X and my Xbox sends a message saying I’m at position Y. The server gets both of those messages, merges them together, and then sends a message back to both of us that you are at X and I am at Y. The Xbox receives that and adds you to X on my system and me to Y on your system.
This process happens hundreds of times a second when you’re playing online multiplayer and it’s what makes the other characters move in near real time. It’s also what we refer to as LAG when playing. If that communication is delayed even slightly then the data you have on your Xbox is not in sync with the data on the server. You’re Xbox will be sending incorrect information to the server at the same time someone else’s Xbox is sending correct information. This is referred to as a Race Condition. Whatever data reaches the server first is usually what the server accepts as valid and processes. Essentially if you tell the server you’re at X and I tell the server that I see your character at Z then the server usually accepts whichever of us sends the response first, resulting in characters teleporting across the screen.
Peer-to-peer model
P2P works roughly the same except all players are connecting to another player directly who acts as the host. The host player is not collecting and aggregating all the data instead of a server. This gives the host an advantage as they are the first person to process all the data. This also solves the race condition issue as the host player is the authority.
Ok, so why does this matter?
You might be saying “But Crowfather you said NAT Type affects P2P but games are mostly Client-Server now so why does a Strict NAT type still impact me?” and you’d be right to ask that. While the actually game portion of most multiplayer games is client server based the chat portion is mostly P2P. This again probably comes down to a cost saving features. Developers and publishers don’t need to build in a VoIP or WebRTC system into their games to handle voice chat when they can just outsource that to Xbox Live’s existing voice chat. This is where most of the problems lie, although some indie games still use P2P for multiplayer.
With a “NAT Type” of Open you can expect to be able to host and join parties with ease, if Moderate you might be able to join and talk, with Strict you can join but you probably won’t be able to talk or hear.
So how do we fix this? Googling this will tell you to place your Xbox in the DMZ, but this is a bad idea. Your Xbox is essentially a miniature Windows 10 at this point. While the Xbox doesn’t run half as many services as a standard Windows 10 you still don’t want to have it exposed on the internet. Thankfully if you’re reading this then you have a pfSense so you don’t have to.
Step 1: Assign a Static IP to the Xbox
In your pfSense go to Services -> DHCP Server -> [DHCP Static Mappings for this Interface] Add. Fill in this information and provide your Xbox with a static IP. The only fields you need to fill out are;
- MAC address
- IP address
- Host Name
- Description (Optional but recommended)
Everything else is optional.
Technically creating a Static IP is also optional but I recommend it for the things we’re going to do here. It simply makes it easier as you would otherwise have to modify all of this information every time the Xbox Changed IPs.
Step 2: Enable UPnP & NAT-PMP
You’ll need to enable Universal Plug and Play (UPnP) and NAT Port Mapping Protocol (NAT-PMP). UPnP and NAT- PMP are features in the router that allow client devices to request the router automatically open a port forward for different services. Your Windows computer probably does this without you noticing so that it can Teredo Tunnel IPv6 over IPv4. Your Xbox will also use this service to open ports needed for voice chat and then close them when the chat is done (ideally). We want this for the Xbox but we don’t want every device on the network to be able to simply open a port whenever they want.
UPnP can be dangerous. When not properly configured it can allow outside devices to connect to inside devices like what happened with the 2019 PewDiePie Chromecast “hack”, but it can also cause other issues from attackers inside a network. A hacker inside the network can use UPnP to open ports for their malware so we’ll be locking this down.
Step 2.1: Enable UPnP & NAT-PMP
On your pfSense go to Services -> UPnP & NAT-PMP
From here you will need to enable a few features specifically;
- Check: Enable UPnP & NAT-PMP
- Check: Allow UPnP Port Mapping
- Check: Allow NAT-PMP Port Mapping
- External Interface: WAN
- Interfaces: LAN (or whatever your Xbox is on)
- Default Deny
After that we also want to set some Access Control Lists
Step 2.2: Set the ACLs
At the bottom of the page fine UPnP Access Control Lists and then the box for ACL Entries. We’ll be entering the following information there (replace $IP with the static IP you set for your Xbox earlier).
allow 1025-65535 $ip/32 1025-65535It should look something like this when finished.
What we’re saying here is that the Xbox is allowed to open ports between 1025 and 65535. I specified this ports specifically because there’s very little reason the Xbox should be expecting connections on the well known ports. If you aren’t sure what those are go check out my Ports post.
These steps are required so the Xbox can tell the router to open a port and listen for incoming voice data from other players. This really becomes important when you are the party host as other players are connecting to you so the router has to know to forward their traffic to the Xbox; however there’s a different process for joining a party.
Step 3: Create a custom routing policy
When joining a party you are establishing a connection to a host but the way the Xbox handles this is a bit strange and we need to talk about how routers work for a minute.
NAT/PAT
By this point most people understand that NAT is the process by which your router converts one public IP address into many private IP addresses, but PAT is a lesser known feature. Port address translation (PAT) is the process by which your router maps connections back to client devices based off of what source port they’re using. With PAT the router changes the source port of the traffic and creates a mapping that says “replies from this Port go to this client over this port”.
This might seem silly but it helps when you have a lot of clients as it reduces the chances of collision where two devices are using the same source port simultaneously and now the router has to figure out who get’s what. pfSense, and a lot of home routers, use PAT by default now.
The issue is that PAT causes problems with XBL voice chat because voice chat expects to receive data on the same source port that it sent on since it’s P2P. That is what we’re going to fix here.
Step 3.1 Outbound rule
Go to Firewall -> NAT -> Outbound.
You’ll need to do two things here; first you’ll need to mark the outbound routing policy as hybrid, and second you’ll need to create a new routing policy. In this routing policy you’ll want to set the following settings:
- Interface: WAN
- Protocol: Any
- Source: Network: $IP [the IP of your Xbox]: /32
- Destination: Any
In the Translation setting
- Address: Interface Address
- Port or Range: Check Static Port
Step 4: Reboot the Xbox.
Rebooting the Xbox is really just to make sure it get’s its new static IP faster. You could wait for it’s DHCP lease to expire but that could be a while depending on how your pfSense DHCP server is set.
That’s all there is to it. Once you do these steps when you rerun the Xbox “NAT Type” test it should come back as Open while at the same time keeping the Xbox internal to the network and protected behind the firewall.
