How to Set Up a Router's Port Forwarding for a Nintendo Switch Console(en-americas-support.nintendo.com)
en-americas-support.nintendo.com
How to Set Up a Router's Port Forwarding for a Nintendo Switch Console
https://en-americas-support.nintendo.com/app/answers/detail/a_id/22272/~/how-to-set-up-a-routers-port-forwarding-for-a-nintendo-switch-console
181 comments
If they need all your incoming traffic they should probably have called it a "router" not a "switch".
I am ashamed that this has never occurred to me and shocked that I have never heard it elsewhere. Brilliant.
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...
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...
You can also use a USB Ethernet dongle with the Wii (that’s exactly my set up in fact).
This obviously doesn’t help DS users though.
This obviously doesn’t help DS users though.
They did sell a USB dongle that would take a PC's net connection and use that to make a WiFi access point for the DS or Wii.
A joke that could really only happen here, I happily give my upvote.
Ba dum tzz... sigh take my upvote.
I'm sure "Nintendo Router" would be much more terrible product...
Nintendo Firewall sounds good though.
Among other problems, it would be pronounced differently in different countries...
Apparently you only _need_ to forward 45000~65535: https://www.reddit.com/r/NintendoSwitch/comments/6qjhjy/i_ha...
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.
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.
_only_? That’s, give or take, ⅓ of the full range. If everything in your network did something similar, you couldn’t have more than 3 devices in your network (and with 3, the stars would have to align for there to be no overlap between the ranges. If, for example, your tv needs 15000-35000, the largest contiguous range remaining would have about 15000 ports.
Try getting ~10 years old uplay game to work and despair. Not sure what network engine they used at the time but there is an entire set of games that basically can't connect properly without using random ports anywhere in the 10k/60k range, it's ridiculous.
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
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
"And let's not ever talk about two people in the same home playing the same game together."
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.
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.
Ever wanted to relive the past by playing Red Alert 2?
Get ready to relive the past by brushing up on the particulars of the IPX protocol...
Get ready to relive the past by brushing up on the particulars of the IPX protocol...
That makes it worse. That means this is not actually a mistake in the documentation. JFC. Does it not support UPnP?
It does, these docs are for people for whom upnp has failed.
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
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
If it supports UPnP why do the docs not say: turn on UPnP? If you search for UPnP in the docs, you get exactly zero results back.
I don't think anybody here (including me) claims these are _good_ docs.
Is there any evidence that the Switch supports UPnP? Because some quick googling did not suggest it does.
My router has never seen the switch use upnp.
IMO, because they're trying to keep it simple.
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.
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.
> not actually knowing what ports third party switch software
more than likely i'd think this is for enabling inbound responses to outbound ephemeral ports given the port range
more than likely i'd think this is for enabling inbound responses to outbound ephemeral ports given the port range
Even a restricted NAT should allow for this without explicit port forwarding configuration?
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.
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.
It’s a firewall thing not a batting thing. You need a stateful firewall to do that kind of smart port forwarding. Which, to be fair, all consumer routers should have.
Stateless firewalls, however, need to have explicit rules for UDP traffic. So that’s what Nintendo are addressing here.
Stateless firewalls, however, need to have explicit rules for UDP traffic. So that’s what Nintendo are addressing here.
NAT functionality especially for UDP can be incredibly flaky in a lot of consumer hardware, mangling payloads, randomly dropping associations or having extremely short timeouts, and other plain buggy behaviour.
[deleted]
I think even their first-party games use random ports.
Probably because of this: https://duckduckgo.com/?t=ffab&q=UPnP
Among the 4 first links, 3 explicitly tell me that UPnP is dangerous.
Among the 4 first links, 3 explicitly tell me that UPnP is dangerous.
UPnP is significantly less dangerous than forwarding all UDP ports to a single device.
Came here to say this. UPnP is a security vulnerability, not a feature.
Worse than forwarding all ports?
Neither is an acceptable solution.
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.
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.
Who has UPnP enabled anymore?
My Verizon Router resets and defaults to it.
(Oh.... and it resets randomly...)
(Oh.... and it resets randomly...)
My AT&T router (Arris) doesn't even have that setting.
https://forums.att.com/conversations/att-internet-features/h...
https://forums.att.com/conversations/att-internet-features/h...
This is made doubly frustrating by the fact that AT&T does not allow you to use your own router.
You can put your own router behind the AT&T gateway and then tell the gateway it's a DMZ.
AT&T does a lot to make me angry, but removing uPnP is the right call IMHO.
AT&T does a lot to make me angry, but removing uPnP is the right call IMHO.
Using DMZ doesn't completely solve my problem, the AT&T gateway is still routing every packet (at less than line speed) and randomly dropping some of them.
is this maybe to get around a double NAT problem? I'm not sure how UPnP works with double NAT
UPnP is a security risk (as is forwarding all UDP ports to a single device). Nintendo should set up STUN servers so the Switch can do UDP hole punching.
How is hole punching more secure than UPnP? They both achieve exactly the same thing.
Enabling UPnP on your router enables a malicious app to permanently forward ports from the outside to the inside. The malicious app could also forward ports to other devices on your network. For example, installing a bit of malware on your laptop could set up a port forwarding rule from the internet to your NAS's web interface.
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.
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.
That user has pfSense, and they are doing it wrong. I would follow the config and guidance from the pfSense dev on this one: https://forum.netgate.com/topic/112631/nintendo-switch-needs...
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.
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.
The linux kernel uses 32768-60999 for ephemeral ports so you've really cut into them
It's pretty good advice, if you're Nintendo and spending a fortune trying to provide support advice to people with crappy router config/connections. Yes it's entirely likely to cause other problems - but probably going to get that switch working.
Other problems will go to other vendors - and if their advice stops your switch from working, that's on them.
Other problems will go to other vendors - and if their advice stops your switch from working, that's on them.
Exactly. Just like on the Apple's website: "If someone starts shooting at your iPhone: guard it with your body. Layers of tissue and fat should prevent the bullets from scratching iPhone's screen."
Perfect business sense.
Perfect business sense.
Is this on their website, or is it a joke. Seriously, I cant tell anymore.
It's not on their website - all bullets know that even scratching an iPhone offends Jony Ives design sensibilities so if someone is shooting at you, show them you've got an iPhone and the bullets will refuse to leave the barrel.
Of course it's a joke, everyone knows shards of bone are sharp enough to scratch iPhone's screen.
The bone is softer than you might think:
https://lifehacks.stackexchange.com/questions/4280/how-to-cl...
https://lifehacks.stackexchange.com/questions/4280/how-to-cl...
The opening line of that post is priceless.
I guess they don't like it.
If the device is not broken, but the user is dead, they have fewer consumers and more good devices in the secondhand market, no profit.
But if the user survives and the device is broken, he or she continues to buy Apple products, at least the next one immediately, profit!
This seems like an obvious case of Support-Team knowledge topic: people are having issues with their switch getting on to the Internet, here is a support article describing a one size fits all solutions. But as a network guy I hatte the assumptions they made. It's the same as telling a user: Just disable the Firewall and it will work.
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.
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/...
A shocking number of game publisher troubleshooting instructions include "just run it as administrator" among their troubleshooting steps, which is pretty horrifying. It's considered standard advice in PC gaming circles among the 20-and-under or tech-uneducated adult segments.
On a single-user machine, there really isn't much "security" difference between user vs root.
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.
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.
Relevant Xkcd: https://xkcd.com/1200/
So… what if you have two switches?
You obviously need a separate ISP package for every Switch you own
At that point it would be easier if it just came with its own 5g modem and ipv6 support.
This whole article is... optimistic.
> 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...
> 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...
It also assumes that your DHCP range is the top half of the last byte. That's a de facto convention in consumer routers, but not codified anywhere and the kind of thing that could change and probably isn't even correct for some routers shipping today.
Definitely not codified anywhere, and not in any of the routers I’ve used (to be fair they are more prosumer).
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.
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.
Tbf, this is the fault of network people, not the poor support guys left holding the bag of shit. The whole stack is still dangerous and obscure, 25 years after the internet went mainstream. UPnP was an effort at simplifying the situation and seems to have failed, so now we're back trying to teach IT toddlers to spell "characteristic" when they don't even know the ABC (nor do they care about it). It's inevitable that shortcuts will be taken.
Just a quick advice, as I struggled with this as my daughter complained that she could not join network games in Animal Crossing because she had only “NAT Type D”.
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).
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).
When i use routers provided by my ISP the switches always just work. when i was running pfsense (i need to set it up again soon :) ).. I just had to set a rule for them to always get the same IP and the correct NAT type and it worked perfectly.
It does make me wonder if all ISP provided routers are pretty insecure in some way?
It does make me wonder if all ISP provided routers are pretty insecure in some way?
What is this needed for? I never set up any port forwarding and don't remember having any issues with network connectivity. But then again I don't play that much online.
I came to ask the same thing - I haven't picked up my Switch in a couple of months but I never touched my router settings for this and it was always working fine. Maybe it's just something from a recent Switch firmware update? Or perhaps just for online play in specific games.
Typically you'd do this for enabling peer-to-peer connections. I run some Minecraft servers in my house this way. I have no idea what kind of peer-to-peer gaming Switch enables. Social gaming is done over the internet with a cloud subscription that costs like $20/year.
I dunno if this had anything to do with it but there is peer to peer online gaming with Divinity Original Sin 2, and I tried grouping up with many folks I friended online and not in the same time zone and it never worked for us. Borderlands also appears to use peer to peer connections.
Yeah this is what I thought, I remember fiddling around with this to make Soulseek (or something) work on my old Linksys WRT54G back when I was at university. I wonder what Switch services/games work this way
My s/o and her sister (CS student) regularly play Animal Crossing over the Internet. I (and the SIL) wanted to curse Nintendo to hell and back for requiring users to essentially put their Switches available to the wide Internet (meaning, as long as the Switch is powered on, any RCE exploit on the Switch turns it into a full, unrestricted gateway into my home network!) simply because Nintendo doesn't want to follow basic Internet standards like UPnP or, heaven forbid, provide STUN/TURN proxies paid for by the Nintendo Online subscription.
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?
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?
Nintendo, despite making some of the first attempts at networked play in the late 80's and 90's, does not really understand the internet.
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.
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.
Yes networking is def not a core competency. Strange though, the senior people are super technical (I recall the stories of Iwata writing compression algos in Pokemon)
Maybe the DNA of the company is just too focused on games specifically
Maybe the DNA of the company is just too focused on games specifically
This is just an aside, but this might explain why their (online) shop sucks so hard (and no browser on what amounts to a phone without a SIM card?)...
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...
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...
I’ve played Animal Crossing with friends over the internet and I certainly didn’t touch anything on our router to do so. Any idea if there is a particular scenario where this becomes required?
What, they can't use UPnP like a good citizen?
Because UPnP is disabled by default on a lot of routers.
Maybe if the network administrator has disabled UPnP that is a hint that they don't want to allow random devices to expose themselves to the entire internet?!
[deleted]
Because it wound up with the sufficient complexity and implementational discohesion as to be broken, existentially insecure, or both: https://computer.rip/2021-11-26-no-u-pnp.html (https://news.ycombinator.com/item?id=29356874)
[deleted]
I don't think upnp is used a lot anymore as it's also really handy for malware makers
Programmers need to stop trying to kill UPnP.
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.
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.
* Scenario 1:
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.
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.
> Malware doesn't know how to open a reverse tunnel.
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.
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.
No, the malware authors just target the least secure userbase. Because there's plenty of them to exploit. Why put in the extra work if you have plenty of weak targets?
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 :)
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 :)
No, it's insanely useful in the vast majority of cases.
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.
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 disabled on all AT&T Residential Gateways and can't be enabled, you have to use port forwarding or put another router behind it using IP Passthrough. It's also disabled by default on EdgeRouters and can only be enabled in the ConfigTree or CLI. On UniFi it's disabled, but can be enabled in the GUI.
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.
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.
How is PCP any better? It would allow malware to open ports just the same.
I don't think that's really a problem you can solve regardless. A STUN server would make most NAT irrelevant anyway. Most firewalls are setup to allow established connections, so you just need to create an outbound connection to allow the inbound. You can basically use the same techniques as SIP/RTP when they do NAT traversal.
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.
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.
Doesn't seem worth it.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=UPnP
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=UPnP
No need. UPnP is already dead.
Edit: and to add on that, programmers are the absolutely only people on earth that wish it wasn't dead.
Edit: and to add on that, programmers are the absolutely only people on earth that wish it wasn't dead.
Malware that's already on your system can do whatever it wants. NAT punching is not some complicated dark art for people who already have working exploits...
No but it stops them using your system as a C&C node accepting connections from external systems.
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.
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.
What? It's used by tons of legitimate applications as well. Not only malware benefits from being able to accept connections from the Internet. Games, torrents and other p2p services, etc.
I play a lot of games and I've never had any issues not having UPnP. They got used to working around it. Probably with centralised servers. I never liked the P2P model anyway, dedicated servers are more fun because you can influence the gamemode, add mods etc.
For torrents I don't know... If I were to torrent I would not do it without VPN anyhow.
For torrents I don't know... If I were to torrent I would not do it without VPN anyhow.
That's not portforwarding, that's moving to the DMZ...
Darn, I hope this isn't the solution to the problem I have where my switch won't join other worlds on minecraft.
PlayStation is pretty bad too, they want 80, 443 (and 1935, 3074, 3478-3479), if you don't you can get all sorts of really annoying problems joining games, delays joining voice chats etc....
Yeah except of course they do not actually need most of these. It’s all BS and it’s my favorite pet peeve with port forwarding guides. For whatever reason they almost always put all ports for both incoming and outgoing traffic in a list and call it a day.
Cox (US residential ISP) recently started blocking all port 80 inbound to residential IPs.
Don't most ISPs already use NAT and therefore disallow all inbound traffic to devices behind it? I personally had to use WireGuard to work around it for some of my homelab servers that i wanted to publish: https://blog.kronis.dev/tutorials/how-to-publicly-access-you...
I don't know about "most", but in the US, the residential broadband I've seen has public IPs. LTE/5G mobile networks do not.
Some use CGNAT, but you can disable it if you need to run servers.
You can disable it IF the ISP has an opt-out
Sorry yes that is what I should have said
That's common in Australia and New Zealand along with some other potentially high risk ports, usually you can opt out of it in your settings.
Just curious, what if you have another layer of NAT, or your router is out of your control (and no UPnP)?
You just can't play networked games with Switch, or what?
You just can't play networked games with Switch, or what?
doesn't ipv6 fixes those issue?
Do you mean the need to configure your CPE to allow incoming traffic to specific devices? Not really, with v6 you have to put in allow-rules too if you have the normal default-deny firewall rules in the CPE. It could be automatic with UPnP, but it could be automatic with v4 + NAT too. The article doesn't say if the Switch supports that.
It will, I guess. In the same sense that fusion power will fix our energy issues.
What's the reason not to open all ports btw? Outing myself as naive by asking
In a normal NATed setup your ports are closed from the outside until a client from inside your network Starts sending packets to the outside.
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
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
It's not a firewall acl, it's a port forwarding rule. In a NAT, UDP connections you initiate will be added to NAT table temporarily to handle replies. Nintendo's port range covers all the ephemeral ports that OS will naturally give to UDP connections. So your computer may attempt to start a UDP communication but the reply traffic will be forwarded to your switch instead of using NAT table. So nothing else can use UDP properly. That DNS request to port 53 has a source port of 42981 (for example), and the switch gets the reply.
I'm not sure if most routers prioritize port forwarding rules or NAT tables. That's really up to implementation.
I'm not sure if most routers prioritize port forwarding rules or NAT tables. That's really up to implementation.
It’s about redirecting. Following these instructions means that the Switch, and only the Switch, can receive UDP on behalf of the other network. Which will break a lot of things. Supposedly this also means that more than one Switch on the same network is a no-go.
I cant believe a company this size could suggest such a thing, so has anyone tried doing this and then monitored what happens?
Is the Switch able to do other stuff which is not reported or mentioned anywhere?
Is the Switch able to do other stuff which is not reported or mentioned anywhere?
does anyone know why? I don't have this set up on my network haven't had any issues.
I have only seen this issue when running pfsense. and then to fix it i set up rules for the switch to ahve the type of NAT it wants.
When i use a router from my ISP it always just works.
When i use a router from my ISP it always just works.
makes sense but what happens if you have multi switch's? do routers support forwarding to multiple hosts?
I know very little about networking, but i know that my kids can play multiplayer at the smae time together that wont work until i set up thier NAT correctly.
My naivity says that its either NAT handles it or the swithces are choosing random ports (or maybe negotiating through plug and play).
My naivity says that its either NAT handles it or the swithces are choosing random ports (or maybe negotiating through plug and play).
You allways have to, why? And I was so close to buy a Switch. But no .. never gona happen to may home Network.
What if I have two switches?
on the first switch you redirect all ports to the second one
I will not elaborate
I will not elaborate
set up rules in your firewall for the correct NAT type either for your whole network or just those devices - unless something has changed recently.
You’ll have to switch between them
As a network engineer, this made me audibly sigh.
Solid advice, redirect all incoming UDP traffic to your Switch, and your Switch alone...
Solid advice, redirect all incoming UDP traffic to your Switch, and your Switch alone...
Can you explain the consequences to the plebs? :)
Absolutely nothing else on the network will be able to receive anything over UDP. To begin with, this completely breaks DNS, though maybe if your devices use the router as the DNS server and it does the recursion it’ll be OK.
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.
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.
This does not break DNS, HTTP/3, whatever. It does not affect outgoing connections at all, only incoming connections from the WAN to your router.
They are talking about UDP, which is connectionless. There are just packets, going in or out. So you can send a DNS request, but the response will go to the switch, not to you.
modern firewalls do however match on tuple in their session table.
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.
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.
True, those instructions are for those users for whom UPNP failed.
That's not a UPnP feature, it's NAT.
Which is arguably a security issue if things do work as you've described.
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?
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?
[deleted]
If all ephemeral ports (1024-65535) are forwarded to the Nintendo Switch, it means that the NAT gateway can't allocate ports for the other devices that require to send or receive something on UDP. Also, even if "it did only affect incoming connections", where do you expect to receive your reply if all UDP traffic is redirected to the Switch?
I'd tell you the joke about UDP but you might not get it.
Or that joke about TCP:
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?
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’ve always wanted to add an HTTP joke to these sorts of networking humor threads but the prospect makes me feel mildly insecure.
Perhaps you should go with an HTTPS one instead then.
Do we start with a handshake then?
Sure, you can send a DNS query, but how do you propose to receive the response? The response is an incoming connection from the WAN to your router. (UDP doesn’t do sessions, remember.)
(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.)
(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.)
Ehm, no? Your router still do kind-of connection tracking while NATting UDP requests to, say, outside DNS servers, otherwise UDP would not work at all in a NATted environment. There might be stupid or very stupid home routers but I'd expect the port forwarding rules to be applied only if an incoming UDP packet doesn't match any NAT connection tracking tuple in the router.
As I say, I don’t know, but I would expect port forwarding rules that essentially reserve all the ports to cause connection tracking to give up and go home. zaarn cites personal experience of this being the case on smaller ranges.
Completely up to your router’s firewall implementation whether it prioritizes explicit dstnat port forwards (as suggested in the OP) over srcnat connection tracking.
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.
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.
> (UDP doesn’t do sessions, remember.)
Operating systems do. You can associate remote & local port-ip tuples with UDP just as much as you can with TCP.
Operating systems do. You can associate remote & local port-ip tuples with UDP just as much as you can with TCP.
And the router has a clue about those UDP "sessions"? They're not sessions either, it's just an application declaring that incoming UDP packets with a certain destination port (and optionally destination IP, source IP or source Port) be delivered to it. Nothing about sessions.
If you send from local ip/port X to remote ip/port Y, your router will see both pairs. The router has no problem sending responses back your way after it has stored the tuple, assuming you're receiving responses on the same port you sent from. UDP connection tracking is nothing new at all.
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).
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).
UDP Connection Tracking is not well implemented on all routers, more than once I've found that forwarding a UDP port makes that UDP port unavailable for other devices to use.
If connection tracking wasn’t a thing, every UDP reply would be sent to every device on the network.
Yes but your router might not interact well with Connection Tracking and UDP port forwards. Especially with such wide range ones. I know more than one case where port forwarding disables connection tracking for UDP on those ports.
[deleted]
So, you are sure this is a mind-bogglingly stupid advice, but in fact you don't know ?
Switch wants all the common ports, and then some. If this is requested via UPnP/NAT-PMP via the router, other services which rely on those ports may be negatively impacted if they are not designed to allocate ports outside this range.
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...
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...
I'll try an analogy. Your router is an apartment building. The switch is one of the many tenants. The problem: Mail for the switch does not arrive in the correct pidgeon hole of the building.
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.
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.
It is also a massive security liability as any vulnerable software running on the Switch could be used to compromise the console remotely and by extension compromise your home network since your Switch is likely connected directly on it.
No, it is not. NAT is not a firewall; its goal is to let traffic through, not prevent it. The fact that it sometimes happens to behave like a firewall is very dangerous since it leads people into a false sense of security.
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...
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...
If you follow Nintendo steps, what happens is that anybody will hit your Switch directly if they connect to any port on your public IP. If some services on the Switch are running and listening on the Switch public interface, they will answer. If one of the those service has a security vulnerability, you are in trouble. You just don't want to expose your entertainment devices to the whole world like this.
This setup could make some sense for a DMZ but not a gaming console connected to your local lan.
This setup could make some sense for a DMZ but not a gaming console connected to your local lan.
This is exactly why I say that NAT gives a false sense of security.
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.
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.
OK, I get what you meant.
But still, I'm pretty sure we can all agree that Nintendo is giving a terrible advice for the sake of simplicity.
But still, I'm pretty sure we can all agree that Nintendo is giving a terrible advice for the sake of simplicity.
Security is an Onion, built on layers.
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.
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.
[deleted]
Also it would be really nice bot network...
consoles are one of the most secure systems due to the fact they're alwyas unnder attack for ajilbreak
From the little I understand of networking, this might mean that other machines on the network will never get that traffic (unless the Switch routes it and those machines use it as gateway, which is unlikely).
I think we can safely assume something that needs 20k odd ports forwarded to it won't be doing anything like re-routing and acting as a secondary gateway on the network. It doesn't strike me that a lot of thought went into how a Switch would be used behind a firewall during the design if you need that many ports.
No port can be used by any other computer or server (since all are required by Switch), and any port listening on your Switch will be automatically reachable by anyone which is a potential security risk. Does a Switch work if you are IPv6-only? Cause if it'd work with IPv6, a mitigation could be to only use IPv6. It wouldn't solve the security issue, but it would solve the problem of all (external IPv4) ports being used.
The Switch has no support for IPv6 that I’ve seen.
When you connect to a remote machine, you send traffic to a specific port on that remote machine but also from a specific port on your machine. The remote port would probably be well-known (eg, port 80 on TCP is the well known port for HTTP), but the local port would be chosen from a random range of available ports. As a result, every connection could be described based on a combination of parameters - the local IP, the remote IP, the local port and the remote port.
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)
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)