Symmetric NAT and It’s Problems

This article continues on from where Types of NAT left off. A symmetric NAT applies restrictions exactly the same way as a port restricted cone NAT but handles the NAT translation differently. All types of NAT discussed so far don’t change the source port when NATing connections. For example when a client accesses the Internet using IP 192.168.0.1 and source port 56723 NAT changes the source IP to say 56.35.67.35 but keeps the port number the same; this is known as port preservation. A symmetric NAT NATs ports to new randomly generated ones. This even applies to connections from the same client to different destinations.

Example – Expanding on the example from the port restricted cone NAT my PC makes two outbound connections to website IP 217.87.69.8 and 56.76.87.98. My PC uses source IP192.168.0.1 with source port 56723 for both connections. On all types of NAT so far both these connections would be NATed to change the source IP address only and keep the source port the same. This time however instead of leaving the source port as 56723 a symmetric NAT changes it to 45765 for one connection and 53132 for the other connection (random). This has created unique mappings for each connection and traffic from those destinations must come in on the respective ports. So 217.87.69.8 must send packets to destination port 45765 and 56.76.87.98 must send packets to port 53132 in addition to the requirements of a port restricted cone NAT.

Why You Are Reading This

Has your Xbox or PS3 reported that your NAT is strict or symmetric NAT? Has your PC application, VoIP or other program reported your NAT as symmetric NAT? I suspect the answer to this is yes because symmetric NATs are the only types of NAT that cause connection problems with other devices also behind NATs.

The first part in understanding why this is an issue is to realise that PC’s, xboxes, PS3s and their associated games and applications DON’T know that they are being NATed. As far as you xbox is concerned it’s IP address is 192.168.0.1. Any devices that communicate with it on the Internet however use the public IP address of your router of say 5.45.4.21. NAT takes care of translating the IP addresses from the public IP to the internal IP when needed. So why is this a problem you ask? Well with any connection attempt the destination IP address and port must be known. In all the examples above you will see that the website IP address was known as well as the port, these are fixed and never change. Some programs however use a range of dynamic ports. When hosting computer games your console will choose a random port to host the game on. Because other consoles don’t know your IP address or port they must learn it somehow before connecting. Your console sends it’s IP address and port for the hosted game to xbox live or the PS3 network where other parties retrieve it and can now connect to you directly. The problem is that it sends it’s internal IP address of 192.168.0.1 and port of say 54324 rather than the Nated public ones. What it should send is (for example) the public IP address of 5.45.4.21 and port 54324. When using a symmetric NAT the port is also changed so it must send the NATed port of say 54254 rather than the internal port of the console itself (54324). This has been a problem with NAT long before gaming came along. So how does the console learn that it is behind a NAT and tell other consoles to send data to the NATted IP address and port rather than it’s own internal IP address and port?

STUN

There are several different protocols/solutions to the NAT problem but STUN is the most common one in use. Stun stands for Session Traversal Utilities for NAT and as you may have guessed by it’s name it is a collection of utilities to aid in the traversal of a NAT devices. Simply put STUN allows your console/PC or internal device to learn what it’s public NATed IP address and port is. Once this is achieved your device can now send out the correct details to other devices that want to connect to you. But…(and there is always a but) it doesn’t work with Symmetric NATs. With a symmetric NAT your console can learn it’s public IP address but it is impossible to learn it’s public port.

STUN is quite simple in how it works. You connect to a server running the STUN protocol (xbox live servers) and it reads the source IP address and source port from the incoming packets. These of course will be the NATed ones (which are the ones we need). STUN then sends this information back to the client and it’s job is now done. Your console now knows it’s NATed IP and port and will send this onto other devices. If you remember, with the exception of a symmetric NAT all other types of NAT don’t change the source port. What this means is that when my console creates a NAT mapping it will use it for ALL connections of this type; it uses the same ONE mapping when sending and receiving packets to several devices on the Internet therefore it uses the same public IP address and port. In the case of a symmetric NAT however every single connection has a different mapping with a different (randomly generated) port; the connection to the STUN server will have it’s own unique mapping as will every other console…which means different ports for each mapping. In this case the port that the STUN detected is now useless as this mapping is exclusive to the STUN server. Whatever port is used in the mapping to other devices is unknown and there is no way for STUN to detect it. Since your console can’t learn the public NATed port for each mapping to each console it can’t pass this information on therefore nothing can connect to your hosted game. This is the reason symmetric NATs cause so many gaming issues.

Step By Step Example Using A Port Restricted NAT

Explaining how and why symmetric NAT has problems is always easier with a step by step example. Here is the difference between a port restricted NAT and a symmetric NAT.

Port Restricted NAT

• My console with IP address 192.168.0.1 hosts a game using port 57433. It connects to xbox live to advertise this information.
• Xbox live (using STUN) detects my public IP address of 56.45.32.5 and public port of 57433 and informs my console of this.
• My console updates this information and advertises these details on xbox live.
• Another person browses xbox live for my game. Once he clicks “join” his console retrieves my public IP address and port and attempts to connect directly. It tries to connect on 56.45.32.5 with port 57433.
• The initial connection will be blocked by a port restricted NAT because I haven’t yet sent any data to that console. My console now sends data to the remote console (IP and port learnt through xbox live) using source port 57433 with source IP 5.45.32.5.
• All subsequent packets sent from the remote console to 56.45.32.5 using port 57433 will now be accepted by my port restricted NAT as I have now sent packets to it and he connects to me successfully.

Symmetric NAT

• My console with IP address 192.168.0.1 hosts a game using port 57433. It connects to xbox live to advertise this information.
• Xbox live (using STUN) detects my public IP address of 56.45.32.5 and public port of 57433 and informs my console of this.
• My console updates this information and advertises these details on xbox live.
• Another person browses xbox live for my game. Once he clicks “join” his console retrieves my public IP address and port and attempts to connect directly. It tries to connect on 56.45.32.5 with port 57433.
• Like a port restricted NAT the initial connection will be blocked because I haven’t yet sent any data to that console. My console now sends data to the remote console (IP and port learnt through xbox live) but a new mapping is used using port 45654 with source IP 56.45.32.5.
• The information the remote console received from xbox live was that the game is hosted on 57433 but the symmetric NAT opened up the port 45654 for this connection and not 57433. The remote console fails to connect.