Nintendo Switch - NAT Type D

[ggatten]

Hello, Customer participates in eSports leagues using Nintendo switches. When client connects to Nintendo, the NS switch status says NAT TYpe D; while NAT type A or B is required for proper operation. This is typically caused be port randomization on the firewall/NAT device. Other customers we've had to disable port-randomization to make it work, but as this one is using MX firewall I don't think we can do that? Is this something Meraki Support can do, or is there another option? TIA for any ideas!

[PhilipDAth]

I am thinking to achieve something like that you'll need one of these solutions:

• An IPv6 connection.  Each device can then get a public IPv6 address, and you can create an IPv6 firewall rule to allow all traffic in.  This will only work for communication to other IPv6 devices.
• A block of public IP addresses from your ISP, and do a 1:1 NAT to each device.
• You could try asking Meraki support to enable "Layer 3 Inbound Firewall Rules", which substantially disables a lot of the security.  Not as likely to work as the above two options.

Basically it requires all security to be disabled, and to allow anything in from the Internet.  It sounds like an incredibly bad idea to me.

[ggatten]

Hello, thanks for reply.  I sorta like the IPv6 idea.  But, let me explain a bit further:

 - Cisco routers/NAT do not randomize source ports by default.  

 - pfSense does randomize by default, but you can disable it - which we have.

Source port randomization is...   1.1.1.1 tcp 55555 to 2.2.2.2 tcp 443 when NAT'd becomes 1.1.1.1 tcp 31673* to 2.2.2.2 tcp 443.  * is the randomized source port.

I know in theory non-random ports are more vulnerable to certain attack vectors, but in practice - it's not even in my top 10 list of worries.

I opened a case with Meraki support.  We'll see... 

[RowellDomingo]

@ggatten i ran into the same problem and just resolved it. I have a meraki MX105. 

Solution: As per Meraki Team we can't disable the port randomization firewall/NAT but instead define a firewall/NAT port Session Persistence. Once a port is assigned to a session, that port will remain mapped to the session until the session is terminated or times out. During the life of the session, the port will not change, ensuring that the external service communicates with the same source port throughout. Achieved NAT A and B Nintendo switch perfectly working now. 9-26-2024 11:10. It took me a while to work with meraki support for almost 2hours

P.S this feature can be configured from the backend. So, you need to open a case with meraki support, and they will help you out. Only few individuals Meraki tech has knowledge on this as this is something new in their environment.

[ggatten]

Sounds similar to what they told me.  They made a change on one firewall in question, but the problem persists.  

I believe the issue is; any change in udp port for the NS will break it.  Ie:  I boot up a NS and it randomly decides to use udp 55000.  If it hits a NAT device, and 55000 is available - no problem - NAT type B everything is happy.  But what if 55000 is already used?  NAT device will pick something else, 55001 or whatever - now it's NAT type D and breaks.  (I have not done extensive testing on this - but I think it's what's happening)

There are two potential sources of the problem then; both break the 1:1 UDP port mapping NS's must have for some dumb reason:

 - Port Randomization on NAT device.

      - Disable Randomization

 - NS wants to use a port already in use.

    - Reboot NS until it grabs a UDP port not in use.

The problem with "in use" ports, the more devices/students - the more ports will likely be in use and higher probably your NS will get NAT-D.   Especially if using google QUIC or other apps using UDP vs TCP. The MX's don't support NAT pools (WHY?!?!_ , so you can't say...map the NS's to a different public IP address basically reserved for them.  (Less devices on an IP means more likely NAT will work correctly.)

I'm testing another solution now, but the only 100% solution I know of is 1:1 NAT for NS's: each NS gets its own unique public IP address.  Many schools I work with don't have large IP pools, sometimes just a single IP, so this can be problematic to say the least.

Will keep this list updated with my testing, but in general, try to limit the number of devices using the same public IP as the NS's.  And definitely disable port randomization - whatever Meraki calls it.

[ggatten]

PS: You have a case number I can reference?  Want to ensure the same changes that worked for you were applied to my customer.  When I stated the issues persisted after the change, of 5 NS's, only 2 got NAT B - other 3 got NAT D.  As mentioned, I believe if the UDP ports are already in use, one would have to reboot NS over and over until it works....  How many NS's you have?

[RJacklin]

We are having the same issue right now and when I contacted Meraki support I was basically told that our firewall (MX250 with firmware MX 18.211.2) is just not cable of allow a change to NAT type A or B connection. I was advised that our only solution was to put a switch on the Internet side of our firewall to create a DMZ that doesn't hit our firewall at all, allow for the appropriate NAT type to show when connecting the Nintendo device to the Internet. I can't imagine that this cannot be done within the current structure of our MX250. Can someone confirm or deny this? Thank you in Advance for your help. Our ESports team hasn't been able to compete for two weeks because I can't get this figured out.

[ggatten]

See my response to @RowellDomingo .

Adding a network switch does nothing - it's all about the NAT.  If adding that network switch helps you build another network and your NS's can then get a dedicated public IP address - sure - that will work.  Not the best option for sure...

if you have the public IP space, 1:1 NAT is your best bet.  If you don't...  Maybe the quickest/easiest option is a 5G WiFi HotSpot dedicated to eSports?  Not great either - as latency will be a bit higher, but it will at least work, and those are like $50/month - maybe less depending where you are.  OR - if someones phone has a good 5G hotspot and data plan, that may also be a temporary option.

I'll know a bit later if some of my other ideas may work - stay tuned.

[RJacklin]

After opening an additional case, and essentially asking for a second opinion, another support tech told me that they would be able to help. Unfortunately, I can't tell you exactly what they did, because when I asked them what they did to remedy the situation (so I could learn!), they just told me that it was a proprietary solution and they couldn't disclose the process. Maybe it was a special Meraki script that was run, I don't know, but within 15 minutes of making the call the Nintendo was showing NAT type B and we were able to connect.

What I'm really curious about is, why it took me almost two weeks to get to a 15 minute solution, especially when it wasn't something that I could fix??

I am just grateful it's working now!

[ggatten]

Glad it's working!

"Proprietary"....   🙂   Like the KFC recipe?  Hopefully they will publish a KB / tech-note / whatever on it soon.