Network address translation (NAT) rewrites the IP addresses in packets as they cross a router, so many private hosts can share one public address. It was built to stretch IPv4, not to protect anyone. It hides internal addressing as a side effect, but it is not a substitute for a firewall policy.
What problem was NAT created to solve?
IPv4 has about 4.3 billion addresses, far fewer than the number of devices people own. RFC 1918 reserves three blocks for private use: 10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16. Anyone may use them inside their own network, and routers on the public internet do not forward them.
NAT, described in RFC 3022, lets a device with a private address talk to the public internet by borrowing a public address on the way out and swapping it back on the way in.
How does it work in practice?
The most common form is port address translation, often called NAT overload or masquerading. Picture an office with 200 laptops and one public address, 203.0.113.10 (a documentation address). Laptop A at 192.168.1.20 opens a connection to a web server from source port 50514. The router rewrites the source to 203.0.113.10 and picks its own port, say 41000, and records the pairing in a translation table.
When the server replies to 203.0.113.10 port 41000, the router looks up the entry and forwards the packet to 192.168.1.20 port 50514. Entries expire after a period of inactivity.
Other forms exist. Static NAT maps one private address to one public address permanently, usually to publish a server. Destination NAT, often called port forwarding, sends traffic arriving on a public port to a chosen internal host.
Does NAT make a network more secure?
Partly, by accident. A device behind overload NAT cannot be reached by an unsolicited inbound connection, because the translation table has no entry for it. Outsiders also cannot see how many hosts there are or what their internal addresses look like.
That is a narrow benefit. Consider what it does not stop.
- Malware on a laptop that calls out to an attacker. Outbound connections create their own table entries.
- Phishing, malicious downloads and stolen credentials. None depend on addressing.
- Anything you forward. A port forward to an internal server exposes that server fully.
- Abuse of the router. Many NAT devices also run other services, and a vulnerable one is reachable.
NIST SP 800-41 treats NAT as an address management feature that some firewalls also provide, and makes the point that the security value comes from the filtering rules, not the translation. A stateful firewall with a default deny rule gives you the inbound protection deliberately and visibly.
What about IPv6?
IPv6 has enough addresses that every device can have a globally routable one, so NAT is not needed for scale. This worries some people, who assume reachable means exposed. It does not. A stateful firewall that blocks unsolicited inbound traffic gives the same protection NAT gave by accident, and it is a rule you can read and audit.
How to check or apply this
- List every NAT rule on your edge devices, especially static and port forwards, and match each to a named owner.
- Remove forwards to services that no longer exist.
- Confirm a default deny inbound rule exists and does not depend on NAT.
- Put forwarded servers in their own segment with limits on what they can reach inward.
- Keep translation logs long enough to trace an incident, since the public address alone no longer tells you which laptop made a connection.
- When you plan IPv6, write equivalent firewall rules before you enable it.
Quick check
Is NAT a firewall?
No. NAT changes addresses. A firewall decides which traffic is allowed. Many devices do both, but one does not imply the other.
Why do investigators care about NAT logs?
Many users share one public address, so a request seen from outside cannot be traced to a person without the translation records showing which internal host held that port at that time.
Sources
- RFC 3022, Traditional IP Network Address Translator
- RFC 1918, Address Allocation for Private Internets
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
Last reviewed: 18 October 2026.