7 ms·

As a network engineer, this made me audibly sigh. Solid advice, redirect all incoming UDP traffic to your Switch, and your Switch alone...

siva7 5y ago
Can you explain the consequences to the plebs? :)
- iqanq 5y ago
  None. Unwanted traffic will simply be discarded.
  - SjorsVG 5y ago
    I imagine the Switch might collect information about traffic that isn't relevant to the features the user is interested in. Seems a bit careless to just send all of it to the device.
    - iqanq 5y ago
      That's extremely unlikely.
- toyg 5y ago
  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).
  - cube00 5y ago
    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.
- aspenmayer 5y ago
  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/fixing_nat_for_a_nintendo_switch_using_upnp_w/ https://www.reddit.com/r/NintendoSwitch/comments/agv6hw/fixi... https://docs.netgate.com/pfsense/en/latest/services/upnp.html https://docs.netgate.com/pfsense/en/latest/services/upnp.htm... https://www.sciencedirect.com/topics/computer-science/registered-port https://www.sciencedirect.com/topics/computer-science/regist...
- chrismorgan 5y ago
  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/service-names-port-numbers.xhtml 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.
  - iqanq 5y ago
    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.
    - mulmen 5y ago
      I'd tell you the joke about UDP but you might not get it.
      - leokennis 5y ago
        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?
        CPLX 5y ago
        I’ve always wanted to add an HTTP joke to these sorts of networking humor threads but the prospect makes me feel mildly insecure.
- Fnoord 5y ago
  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.
  - tolien 5y ago
    The Switch has no support for IPv6 that I’ve seen.
- lelag 5y ago
  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.
  - donkarma 5y ago
    consoles are one of the most secure systems due to the fact they're alwyas unnder attack for ajilbreak
  - Ekaros 5y ago
    Also it would be really nice bot network...
  - deleted 5y ago
    [deleted]
  - AshamedCaptain 5y ago
    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...
    - lelag 5y ago
      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.
      - 5y ago
- mjg59 5y ago
  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)
- hyperman1 5y ago
  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.

siva7 5y ago

Can you explain the consequences to the plebs? :)

iqanq 5y ago
None. Unwanted traffic will simply be discarded.
- SjorsVG 5y ago
  I imagine the Switch might collect information about traffic that isn't relevant to the features the user is interested in. Seems a bit careless to just send all of it to the device.
  - iqanq 5y ago
    That's extremely unlikely.
toyg 5y ago
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).
- cube00 5y ago
  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.
aspenmayer 5y ago
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/fixing_nat_for_a_nintendo_switch_using_upnp_w/ https://www.reddit.com/r/NintendoSwitch/comments/agv6hw/fixi... https://docs.netgate.com/pfsense/en/latest/services/upnp.html https://docs.netgate.com/pfsense/en/latest/services/upnp.htm... https://www.sciencedirect.com/topics/computer-science/registered-port https://www.sciencedirect.com/topics/computer-science/regist...
chrismorgan 5y ago
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/service-names-port-numbers.xhtml 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.
- iqanq 5y ago
  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.
  - mulmen 5y ago
    I'd tell you the joke about UDP but you might not get it.
    - leokennis 5y ago
      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?
      - CPLX 5y ago
        I’ve always wanted to add an HTTP joke to these sorts of networking humor threads but the prospect makes me feel mildly insecure.
Fnoord 5y ago
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.
- tolien 5y ago
  The Switch has no support for IPv6 that I’ve seen.
lelag 5y ago
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.
- donkarma 5y ago
  consoles are one of the most secure systems due to the fact they're alwyas unnder attack for ajilbreak
- Ekaros 5y ago
  Also it would be really nice bot network...
- deleted 5y ago
  [deleted]
- AshamedCaptain 5y ago
  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...
  - lelag 5y ago
    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.
    - 5y ago
mjg59 5y ago
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)
hyperman1 5y ago
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.