Hacker News Reader

Comment by Dagger2 | Hacker News Reader

But... it doesn't do that. If incoming traffic isn't part of an established connection, NAT will just ignore it. It doesn't deny that traffic, it just lets it pass through to the router without translating the addresses in it.

The router will then do exactly the same thing it would've done if no NAT was involved at all: if the dest IP in the packet is the router itself then the router will accept or refuse the connection depending on whether anything is listening on the respective port, and if the dest IP is on the LAN then it will route it onto the LAN.

View on HN

It depends on how you've configured the router. It's quite common to reject or drop ingress traffic received on an egress interface destined to a NATed network address. In fact, I would flag any configuration that didn't have that.

Yes, of course. If NAT denied connections in the way people think it does, then it wouldn't be necessary to separately configure the router to reject inbound connections. It's possible to have configurations that don't do that precisely because NAT doesn't do that itself.

Yes, but we've just successfully rewritten the article in the comment section as "it's not having NAT that provides the security itself, but other configuration any sane person would expect on a device doing NAT to prevent unexpected inbound connections" is exactly what the article set out to separate.

Fair point!

That makes no sense. If a packet comes into a public IP to a session that doesn’t exist, there is nowhere to forward the packet onto. The public IP belongs to the router.

If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.

There's always somewhere to forward a packet to. The router looks at the dest IP field in the packet header, and that's where it goes.

> If the packet was going to a private RFC 1918 address, there wouldn’t be a way to get it to the router in the first place from the internet.

This is generally going to be true, but it's not relevant to how NAT behaves when it receives inbound connections.

I’m not sure you understand how NAT implementations work.

I recommend you setup a basic iptables NAT set of rules on linux to reflect what a home router does (masquerade) with ip forwarding enabled.

The inbound packets from the internet are to a public IP that belongs to the device performing NAT. If there is no entry in the conntrack table from a connection to translate that public IP to a private IP, there is nowhere it can be forwarded to. It’s already at the device that owns that destination IP.

Even if it spit the packet out a private interface (which makes no sense given the routing table), the destination IP would be a public IP that both cannot be ARPed for on the local network and will not be honored by any private device.

I'm reasonably sure I do. I've done that exact test literally half a dozen times now due to people telling me that I'm wrong, and each time I test it turns out that I'm right. What other conclusion am I supposed to come to?

I think it's someone else's turn to do the test now.

> The inbound packets from the internet are to a public IP that belongs to the device performing NAT.

If the inbound packets are addressed to the router, they get delivered to the router. But you cannot just declare that that's where they'll be addressed. You aren't in control of what packets show up to your router, you're only in control of how you process them after they show up.

you missed the part about an ACL. You’re whole shtick depends on a bad implementation of routing rules.

What you’re describing would happen if NAT were completely disabled. You’re just describing an open router

There's no inherent ACL in NAT, and adding one would just demonstrate that ACLs can block packets, which we already knew.

> What you’re describing would happen if NAT were completely disabled. You’re just describing an open router

Yep. It also happens when NAT is enabled. A router doing NAT is exactly the same thing as an open router -- it just has the additional property of editing outbound connections to appear to come from the IP of the router itself.

If NAT on its own blocked inbound connections, I would have seen that in my tests.

Reply on news.ycombinator.com