Hacker News Reader

Comment by iqanq | Hacker News Reader

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.

View on HN

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?

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.

Reply on news.ycombinator.com