Hacker News Reader

Comment by siva7 | Hacker News Reader

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.

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.

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.)

So, you are sure this is a mind-bogglingly stupid advice, but in fact you don't know ?

> (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.

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).

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.

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.

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.

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?

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?

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?

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...

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.

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.

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

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...

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 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.

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.

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.

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)

None. Unwanted traffic will simply be discarded.

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.

That's extremely unlikely.

Reply on news.ycombinator.com