How to Set Up a Router's Port Forwarding for a Nintendo Switch Console(en-americas-support.nintendo.com) |
How to Set Up a Router's Port Forwarding for a Nintendo Switch Console(en-americas-support.nintendo.com) |
Apparently, the "Nintendo WiFi Network Adapter" was once a thing in Japan, and it did have a router mode.
https://www.wired.com/2008/09/nintendo-announ-2/
https://www.famitsu.com/game/news/1217892_1124.html
https://kotaku.com/nintendo-announces-wii-ds-wifi-router-bwa...
This obviously doesn’t help DS users though.
I went through this when setting up the switch to talk to someone behind heavy NAT over the holidays. 45000+ worked for me.
....which makes this even more ridiculous if it never uses them.
And let's not ever talk about two people in the same home playing the same game together. I loved splinter cell blacklist's multiplayer but damn did it take long to get anything connected.
I'm not even sure why I mean this was with internet gaming already being the norm, I assume it's because they made games for console and then ported, and on console port issue are handled for them or whatever ? Anyway this was stupid
The wide port range I think is Nintendo throwing their hands in the air and not actually knowing what ports third party switch software uses
Among the 4 first links, 3 explicitly tell me that UPnP is dangerous.
The most common problem I have seen over and over is double NAT or CGNAT. For the home networks I manage (my parents, in-laws, and my own), I put the ISP modems in bridge mode or passthrough mode.
Other problems will go to other vendors - and if their advice stops your switch from working, that's on them.
Perfect business sense.
> 4. Enter the IP address you found on the network device, but add 20 to the last section of digits, and then select OK.
> As an example, if your computer's IP address displays as 192.168.2.5, enter 192.168.2.25 on the Nintendo Switch.
Hope you don't have more than 20 devices on your network (after your PC), and that they're not configured to be close to 255 there...
The main dhcp server used in most routers, dnsmasq, also assigns IPs using a MAC algorithm by default for consistent IP addressing of devices in a LAN. You would need to explicitly configure it for sequential first come first serve.
Forwarding all these ports was the recommended solution in Nintendo’s docs. However, it did nothing to resolve this problem. What helped was to ensure not to modify source ports in the NAT setup (“static-port” in pf).
It does make me wonder if all ISP provided routers are pretty insecure in some way?
Hell it took years for them to implement Bluetooth audio on the Switch, and that's output-only, no microphone. What stuff is their software division smoking?
The buggy firmware that allowed control from outside had nothing to do with UPnP, it was... just buggy firmware implementing it wrong. And it can be easily detected with online testers.
I always leave UPnP on, and I've never seen it disabled by default, nor would I ever want them to do that.
When the router does it right, it's just a small extra convenience for malware that can only be used when they already compromised your system. If they are in your network already, they can already do whatever they want.
You just can't play networked games with Switch, or what?
The Router will keep track of network package going through to the Internet and store it in a table. in case there is an answer from outside of your network the router will look up whether a client started this conversation (there is a corresponding entry in his table) and will forward the incoming packet to the client that started the conversation.
What nintendo is asking you to allow here is to allow any outside packet coming in over UDP to get to the switch whether it first asked for it or not.
This means in practice you won't be able to run any other service which needs an UDP port fowarded in your network. It also means anyone can talk directly to your switch on any port they like whether you want to or not.
And it means, that should something ever take/get the same IP as the switch it will be exposed to the Internet directly
I'm not sure if most routers prioritize port forwarding rules or NAT tables. That's really up to implementation.
Is the Switch able to do other stuff which is not reported or mentioned anywhere?
When i use a router from my ISP it always just works.
I will not elaborate
Solid advice, redirect all incoming UDP traffic to your Switch, and your Switch alone...
I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
Something like putting your Switch on a /30 or Configuring DHCP to assign IPs in decreasing order.
> I feel like it would be a fun excercise to intentionally subvert the assumptions they made and see how they handle it.
[1] https://en-americas-support.nintendo.com/app/answers/detail/...
https://en.wikipedia.org/wiki/Family_Computer_Network_System (1988)
https://en.wikipedia.org/wiki/Satellaview (1995)
https://en.wikipedia.org/wiki/64DD (1999)
They don't understand a lot of things, even some of which they've lucked into, like the competitive Smash scene. Or fan remakes and tributes (of which Sega notoriously doesn't send their lawyers after).
But they still make some incredibly compelling games.
Maybe the DNA of the company is just too focused on games specifically
It's not just that the UX is a bit clunky, it's that it's a veritable morass of junk, a lot of which is regurgitated ports of PC titles...
They didn't understand how online shops work, to be fair all titles still at least play, but there is not as high quality control as I would have expected.
I say this as, Nintendo has a reputation and clout as a games developer (honestly none of their consoles have ever been great - they have mishaps in the software world but it is rarer), looking at their store you see a suspicious similarity to steam with sales - in fact as far as software goes a humble bundle subscription is probably a better value proposition. It's just not the rich and high quality, unique catalog people have come to associate with them. Maybe it was always like that regarding 3rd party games, but it just underlines how much they don't understand the internet...
Next, just about all real-time communications uses UDP, so your Skype, Zoom, &c. are all broken. And it just goes on. Some, like HTTP/3, will happily fall back to TCP when they observe it’s broken (HTTP/3 will fall back to HTTP/1 or HTTP/2), but various things will just be broken.
Take a look at everything in https://www.iana.org/assignments/service-names-port-numbers/... that uses UDP. This will break just about all of it.
And even if you didn’t need any of those things: what if you want to have two Switches on your network?
This is just mind-bogglingly stupid advice.
Switch is requesting ALL of the ports, which is going to make the above a bit difficult, to say the least.
https://www.reddit.com/r/NintendoSwitch/comments/agv6hw/fixi...
https://docs.netgate.com/pfsense/en/latest/services/upnp.htm...
https://www.sciencedirect.com/topics/computer-science/regist...
Problem one: Nintendo wants you to take your IP and add 20. So if you live in blahstreet 1 box 7, they tell you to send all Switch post to blahstreet 1 box 27. If someone else happens to own that box, bad luck for him. Worse, the IPs are dynamic via DHCP, so a box unused today may be used tomorrow. But that's the minor part.
Problem 2: Nintendo wants you to tape a big paper above the pidgeon holes, saying: Postmaster, please drop all mail in box 27, no matter what box it specifies. Technically only for UDP, so the TCP traffic will be delivered. Even so, a lot of post will be wrongly delivered to the Switch and thrown away. Other tenants will wonder why they don't get their mail.
Problem 3: You become very vulnerable. The router will send every hacking attempt to the Switch. The tiniest bug in its networking is now critical, as outsiders can just assume your Switch will receive anything they send.
To recap, Nintendo is making sure their device receives traffic by throwing every other device you own under the bus. Even a second Switch will suffer. The advice is Dilbert PHB level idiotic but will seem to work for a while.
But these days most users don't connect to remote servers directly. Instead, they're on a local network that connects through a router that only has a single world-routable IPv4 address. That means that while the combination of local and remote IPs and ports is still nominally a unique identifier, the local IP could now refer to multiple different devices. NAT handles this by keeping track of which machine behind the NAT triggered a local connection, mapping its local port to a local port on the publicly routable IP, and then rewriting traffic and forwarding it appropriately so this is mostly invisible (eg, you send traffic to 142.250.189.174 on port 80, and your local port is 31337. Someone else on your network may also be using port 31337 to talk to port 80 on 142.250.189.174, so your NAT router rewrites your local port to 31338. When it sees incoming traffic on port 31338 from 142.250.189.174, it rewrites the packet to be sent to you and as far as you're concerned you're directly communicating with 142.250.189.174)
This basically works fine for TCP, because TCP requires you to explicitly make a connection. That means the NAT router can tie the combination of a remote host and a local port to a unique mapping to an internal machine. But UDP is, at the transport layer, stateless - when you send traffic to a remote machine over UDP, the expectation is that that remote machine can just send traffic back to the same UDP port at some arbitrary point in the future and, if the local client is still listening, that'll got through.
If you port-forward literally every UDP port to a specific device, when another local device tries to connect to an external service over UDP, your router will probably be confused - it can't just say "Ok, you connected to something over UDP, I rewrote your local port to 31337, traffic to 31337 will be sent to you", because 31337 is already configured to be forwarded to the Switch. You can potentially send traffic to a remote service, but the responses may be forwarded to the wrong device.
In theory you could say that because a machine with a specific internal IP sent traffic to a specific remote IP and you rewrote that to a specific port, any traffic from that remote IP to that port should be forwarded to that internal IP even if there's a general port forwarding rule that would instead forward it to the Switch. I have no idea whether that's how routers behave, and it's far too late for me to dig into the kernel source to check that (I've spent the evening fighting Linux's in-kernel ASN1 parser, I'm not inclined to do more)
For torrents I don't know... If I were to torrent I would not do it without VPN anyhow.
It doesn't stop it per se but it makes it a lot harder. Part of security is not being the easiest target on the block.
My naivity says that its either NAT handles it or the swithces are choosing random ports (or maybe negotiating through plug and play).
This is my fiance and I constantly struggling with Halo:MCC. At least once a night one of us fails to join a game, and I'm convinced it's some poor NAT punch through solution that doesn't always work.
Get ready to relive the past by brushing up on the particulars of the IPX protocol...
UDP hole punching via STUN requires continuous work on the part of a malicious app to keep that port open. Work that could be noticed much easier than a rogue UPnP-using bit of malware. And it can't open ports to other devices on your network.
Although I will say that if you are forwarding all ports, at least it’s to a device you know about. Not some random IoT or PC software or whatever opening up ports without your knowledge.
Full access to the user's data, and ability to run 99% of code that one might want to run, is plenty bad enough already.
(Oh.... and it resets randomly...)
https://forums.att.com/conversations/att-internet-features/h...
I have early 2000s routers that would basically forward all UDP traffic from $IP to the last computer that had sent any traffic to $IP. This did wonders for most games, but you were in for a nasty surprise if you were relying on NAT to protect your fragile Win9x network...
This setup could make some sense for a DMZ but not a gaming console connected to your local lan.
The point is that even without manual port forwarding your Switch is _already_ exposed to the public internet. You can't assume that NAT is going to forever hide your device from the public internet because the role of NAT is to pass traffic, not prevent it. The example I mentioned is to show that NAT's heuristics may end up exposing your device anyway, manual port forwarding or not. So if you really run a device with vulnerable services, you either add a real firewall or disable NAT.
If the Switch had any vulnerable ports, they were exposed already long ago. Not to mention: IPv6 networks, public Wi-Fi hotspots, etc.
Should NAT be the only layer, no. But I absolutely can be a layer, just like obfuscation can be a layer.
for example Changing ssh port from 22 to something else is not "security" per say, but it can prevent drive buys and general non-targeted events.
https://lifehacks.stackexchange.com/questions/4280/how-to-cl...
But still, I'm pretty sure we can all agree that Nintendo is giving a terrible advice for the sake of simplicity.
AT&T does a lot to make me angry, but removing uPnP is the right call IMHO.
Most readers of HN will understand (or at least understand the goal of) the checklist for debugging network issues.
Skipping straight to Port Forwarding eliminates any issues on whether UPnP is actually working correctly. Growing up, some of my friends had routers struggled to handle UPnP correctly. If I knew they were the only one needing port forwarding, I'd simply turn that on for them instead of trying to figure out if UPnP was actually working correctly.
more than likely i'd think this is for enabling inbound responses to outbound ephemeral ports given the port range
Unless you're doing something like active FTP where it's replying to a different port than the one the request originated from. Which would be a interesting choice for a console designed in like 2018.
Stateless firewalls, however, need to have explicit rules for UDP traffic. So that’s what Nintendo are addressing here.
Malware running on your network requests port over UPnP. Router accepts it. Hacker has direct inbound access to code they control.
* Scenario 2:
Malware running on your network requests port over UPnP. Router denies it (UPnP is disabled). Malware doesn't know how to open a reverse tunnel. No inbound access.
* Scenario 3:
Same as 2, but malware sets up reverse tunnel. Hacker is in.
* Scenario 4:
Buggy and/or sloppy firmware that's not otherwise malicious requests port over UPnP even though it doesn't need to receive connections from the Internet. Router allows it. Hackers know about this slop and other CVEs on device. Network compromised.
* Scenario 5:
Same firmware from 4, but this time UPnP is disabled on router. It's safe to say this non-malicious firmware doesn't set up a reverse tunnel. No inbound access.
This is obviously a very simple threat model but from here you can see that 2 out of 5 attack scenarios would have been prevented by disabling UPnP on the router.
So this is useful if malware authors are just incredibly dumb?
Unconvincing. The only reason to disable UPnP seems to be "it might be really buggy" but that's true of all software and we don't disable all software. Yes, security in depth but that's taking it to a ridiculous extreme.
Physical security works the same way. The point is to have better locks on your bike than the one beside it.
And opening ports reduces the need for central infrastructure for the malware makers, which leads to less chance of being discovered (no money trails etc).
PS Speaking of run of the mill malware/ransomware here obviously. If you get targeted by state actors you can kiss your ass goodbye either way :)
By many many orders of magnitude the most common scenarios are 4 and 5.
This is not a ridiculous extreme. It is the easiest and most effective thing you could do.
It's a convenience over control item. Most things do NAT traversal pretty well anyway, UPnP IGD has run it's course at this point. PCP is better in every way, push for that instead.
PCP is better than UPnP IGD, most importantly because it time limits the opening so port reuse is easier. I wouldn't use either in practice. I wouldn't suggest NAT-PMP either. I wouldn't use port forwarding if I could avoid it as well. I'd use destination NAT with a source IP range I knew in advance so it wouldn't show as easily in port scans. Someone is likely to tell me why that's a terrible idea, but it's my (current) preferred method.
Edit: and to add on that, programmers are the absolutely only people on earth that wish it wasn't dead.
Sure, the protocol is connectionless, that doesn't mean a firewall can't reason about which side the traffic is originating from in its session table.
1: Do you want to hear a joke about TCP?
2: Yes I do want to hear it.
1: I confirm you want to hear it.
1: I am now going to tell the joke.
2: I acknowledge you are now going to tell the joke.
1: I will now start the first sentence of the joke.
2: I acknowledge I am now ready to hear the first sentence of the joke.
1: So a network packet walks into a bar
2: Sorry I couldn't quite here you. Please start over.
1: Do you want to hear a joke about TCP?
(I dunno, I’m not a network engineer, perhaps routers ignore the port forwarding and keep doing their normal NAT stuff in cases like this, but I would expect them not to because… well, you told them you wanted all the ports to go to a certain place, and nothing says UDP has to symmetrical anyway, maybe you honestly do only want tot send UDP from other machines and not receive it.)
Operating systems do. You can associate remote & local port-ip tuples with UDP just as much as you can with TCP.
I suspect that most routers will support a “DMOZ” host, while at the same time supporting srcnat for outgoing connections, but I’m not sure whether it’ll recognize it as such when you also set a port range.
Scenario A:
I've forwarded anything sent to UDP/80 to 192.168.1.20.
You're on 192.168.1.30 and you send a packet to 10.20.30.40:50 using UDP, source port 80.
An incoming packet from 10.20.30.40:50 now goes where? 192.168.1.20:80 or 192.168.1.30:80?
What stops me at 192.168.1.30:80 sending out packets to every IP, flooding the connection state table and effectively DoSing 192.168.1.20:80 without ever touching it?
...or should the connection actually go to 192.168.1.20:80 always, because that's what I've statically defined for all traffic on UDP/80 to do?
I guess the question is: which should take precendence, the dynamic session table, or the static configuration?
If you haven't sent anything at all, then you're not a normal client, you're a server and need port forwarding anyway (or you're ftp and should be shot).