A solution to the NAT traversal problem between a Nintendo Switch and the Juniper SRX Firewall.

I recently had to solve a problem with my son’s Nintendo Switch where the game called “Splatoon” would not find any Internet players because “there was a NAT traversal problem”. Googling told me the wildest stories from completely exposing the Switch to the Internet in a DMZ deployment  to using Static NAT on either the SRX or PFsense.

Since I only have one public IPv4 address (already used for hosting various services) and the Switch does NOT support IPv6 (ridiculous, I know) this seemed like a tough problem to crack.

I found complete cookbooks on the Internet where several large UDP port-ranges were suggested for Port-Forwarding as the Switch does not support UPNP for reverse pin-holing.

Apparently Nintendo distinguishes between S-NAT types A-D, where only types A and B would suffice. This is the information I found so far, although I can’t vouch for it’s accuracy:

-type A complies to DMZ exposure and provides optimal performance when performing online gaming.

-type B is S-NAT with port-forwarding in the reverse direction for the relevant UDP ports. (e.g. 40,000-65535). It should still be sufficient for online gaming.

-Type C is regular NAT and is supposedly insufficient.

-Type D is – for whatever reason – useless. And guess.. this is the one I got by using regular PAT.

I have tried changing the DNS IP address to google, changing the MTU, changing policies, using Wireshark to snoop the traffic between the Access-Point and the internet in trying to find out what I was missing..

Then I noticed that once I configured STATIC NAT for the Nintendo Switch, all was well and I reached “NAT Type A”. But then I could not forward my services for mail etc. on this IP address.

So.. what was the difference between S-NAT + Port-Forwarding the UDP ports I found towards the Nintendo Switch (40,000-65535 or so..) and a straight DMZ deployment?…..!

Then it hit me: the Source Port is NAT translated to another Source Port once the Public IP Datagram leaves the SRX on it’s way to the Internet. This is Randomized behavior on the SRX. Like IKE Phase 1 in IPsec, the changing of Source Ports seems to break the NAT traversal for the Nintendo Switch.

So if the Nintendo Switch uses e.g. Source Port 60,000, this Source port becomes e.g. 48,000 after translation. THAT does not happen with DMZ deployments, where straight NAT is used without PAT.

But.. what to do about this?!.. Then I found an poorly described feature of the SRX called “port-randomization disable” which does not generate Random ports after translation. I think it hands them out sequentially, but I didn’t bother to check.

So now the Source NAT is configured as follows:

pool my-nat-pool {

    address {

        <Internet IP/32>;

    }

    port {

        range {

            1024;

            to {

                63487;

            }

        }

    }

}

port-randomization disable;

 

The very strange thing is.. that the Nintendo Switch still claims that I have NAT Type C, but the game works.

And.. even better: I do NOT USE PORT FORWARDING on the SRX towards the Nintendo Switch! Just S-NAT seems to do the trick.

I hope this helps you on your quest.. it took me quit a while to figure this out.

Leave a comment if this helped you.

This entry was posted in Nintendo Switch. Bookmark the permalink.

One Response to A solution to the NAT traversal problem between a Nintendo Switch and the Juniper SRX Firewall.

  1. rootuser says:

    Good article man, this saved my day!

Leave a Reply

Your email address will not be published. Required fields are marked *


eight + 7 =

IMPORTANT! To be able to proceed, you need to solve the following simple math (so we know that you are a human) :-)

What is 7 + 14 ?
Please leave these two fields as-is: