[Dagger2]

It's not actually secure; your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN. This remains true whether or not you're applying NAT to your outbound connections.

If anything, NAT makes you less secure by tricking you into a false sense of security.

(It's also worse if you're deliberately running servers, because it catastrophically reduces the search space needed for a hostile actor to find those servers via network scanning. At least, it does on v6 -- on v4 the search space is already too small to be a relevant factor.)

[hot_gril]

> your router will route inbound packets to whatever IP is in the packet's destination header, and that can be a machine on your LAN

The dst is going to be the router's address, not one of the LAN's private IPs.

[Dagger2]

Not necessarily. What enforces that? You can't rely on your attackers to kindly not send traffic to IPs you don't want them to.

[hot_gril]

The routers. My ISP can't route dst=192.168.1.2 to anywhere, and even if someone managed to splice the packet in between my router and the ISP, my router won't take that dst. That address doesn't exist on the WAN.

[Dagger2]

No, the routers don't enforce that, and your ISP can route packets with a destination IP of 192.168.1.2, or anything else they like, to you just fine.

Your router will happily "take" that destination IP. The only reason it won't is because of a firewall, not because of NAT.

[hot_gril]

Ok, my PC's address is 192.168.1.3 and I have UDP port 9000 open, please send me a packet.

[Dagger2]

Okay, but since that's RFC1918 you'll need to give me access to your immediate upstream network in order to send the packet to your router. How do you want to do that?