You are right that it would be hard to open a TCP connection with you on a specific target port on a 1:N NAT without UPnP. If you could, IPv4 exhaustion would n

You are right that it would be hard to open a TCP connection with you on a specific target port on a 1:N NAT without UPnP. If you could, IPv4 exhaustion would not be an issue. However, NAT is just a mapping from an internal IP to an external Port number. With pure NAT, once you have created a connection to the outside, anyone can send packets to that external port, and have them delivered to your device. Of course, this mapping is inherently lossy. You are mapping the port space of one device onto N devices. This does mean external IPs can only send your devices packets on ports they have previously used as source ports, but you are still not safe. You might own devices that, for example, have vulnerabilities in their networking stack. Not that rare. You also might not want to disclose the number of devices active in a network, allow them to be fingerprinted by their response, or similar. Some UDP client applications might also not check the IP addresses of incoming packets. UDP server applications also commonly use the same socket for connections to other hosts as it listens on. So, to elaborate on that last example, you might run, say, a video surveillance server. It might listen for RTP on UDP port 12345. It then uses that same socket to send a UDP packet to licensecheck.example.com. That packet will have a source port of 12345. NAT will then map internal_ip:12345 to external_ip:xyz. Anyone can now view your cameras on external_ip:xyz. So either way, you'll want a stateful firewall. Deny incoming, allow outgoing. That's what firewalls are there for, and that's what gives you your security, NAT or no NAT.