Network Address Translation is routinely treated as a firewall, yet it was designed to conserve IPv4 addresses, and the protection people credit it with actually comes from the stateful filtering that usually ships alongside it. That confusion causes real gaps: port forwards nobody reviews, UPnP opening inbound holes on request, Application Level Gateways that can be tricked into opening pinholes, and IPv6 rollouts that remove NAT and with it the only inbound filtering a network had. NAT also changes how you investigate incidents, because a public address no longer identifies a single host or subscriber. This guide explains what NAT does and does not protect, the behaviours defined in the IETF requirements, the risks of carrier-grade NAT for attribution and IP-based controls, and how to log and monitor translation properly. It is written for network engineers, security architects, SOC analysts and incident responders.
Key takeaways
- NAT is not a security control. RFC 4864 states that IPv4 NAT was not developed as a security mechanism and that translating address bits does not provide security in itself; the default-deny stateful filter does the work.
- Filtering behaviour matters more than mapping. RFC 4787 separates mapping from filtering, and endpoint-independent filtering lets any external host reach an internal port once a mapping exists.
- Automatic pinholes are the real exposure. Static port forwards, UPnP, PCP and protocol ALGs all create inbound paths that bypass the "nothing gets in" assumption.
- Shared addresses break attribution and IP allowlists. Behind carrier-grade or cloud NAT, many hosts or tenants share one public address, so logs need source ports and accurate UTC timestamps, and IP-based trust needs care.
- IPv6 removes NAT, not the need for a firewall. Replace implicit NAT protection with an explicit default-deny inbound policy before enabling IPv6.
What NAT actually does
A NAT device rewrites source or destination addresses, and usually ports, as packets cross a boundary. The common forms are:
- Source NAT or NAPT (masquerade): many internal hosts with private RFC 1918 addresses share one or a few public addresses; the device tracks each flow by translated port. This is what home routers, office firewalls and cloud NAT gateways do for outbound traffic.
- Destination NAT (port forwarding): inbound traffic to a public address and port is rewritten to an internal host. This is a deliberate inbound exposure and must be governed like any firewall allow rule.
- Static one-to-one NAT: a public address maps permanently to one internal host. Every port on that host is reachable unless a filter says otherwise.
- Carrier-grade NAT (CGN, NAT444): an ISP or mobile operator translates many subscribers onto a shared public pool, often behind the customer's own NAT.
- NAT64 and related IPv6 transition mechanisms: translate between IPv6 clients and IPv4 servers, which moves the translation point and its logs to the operator or data centre edge.
The perceived benefit is that unsolicited inbound packets have no mapping, so they are dropped. RFC 4864 accepts this gives "a measure of protection" against simple attacks and some topology hiding, then shows that a stateful firewall with default-deny inbound rules delivers the same result without translation. The distinction matters because NAT state can be created from the inside, by software you do not control.
What NAT does and does not protect
| Threat | Does NAT help? | What actually controls it |
|---|---|---|
| Unsolicited inbound connection to an internal host | Partly, as a side effect of missing mappings | Stateful firewall with default-deny inbound (NIST SP 800-53 SC-7(5)) |
| Malware on an internal host calling out to command and control | No, outbound flows are translated freely | Egress filtering, DNS filtering, proxy inspection, EDR |
| Phishing, drive-by download, malicious attachment | No | Email and web security, endpoint controls |
| Exploitation of a port-forwarded service | No, the forward is an inbound path | Exposure review, patching, WAF, removing the forward |
| Inbound access opened by UPnP, PCP or an ALG | No, these create mappings on request | Disable UPnP and unneeded ALGs, restrict PCP to the inside interface |
| Lateral movement inside the network | No, internal traffic is not translated | Segmentation and microsegmentation |
| Internal topology discovery from outside | Partly, addresses are hidden | Also leaks through headers, DNS and application data; do not rely on it |
| Device tracking by IP address | Partly | IPv6 privacy addresses; application-level privacy controls |
For a broader view of boundary controls see the Network Security Guide and the Firewall Management Guide.
NAT behaviours and why they matter for security
RFC 4787 (BCP 127) defines how a NAT maps and filters UDP traffic. Mapping decides which external address and port an internal endpoint gets; filtering decides which external packets may use that mapping.
| Behaviour | Definition (RFC 4787) | Security effect |
|---|---|---|
| Endpoint-independent mapping | Same external address and port for all destinations from one internal address and port | Required (REQ-1) so STUN and peer-to-peer work; does not by itself weaken security |
| Endpoint-independent filtering | Any external source may send to an existing mapping | Most permissive: once a host has sent one packet, the whole internet can reach that port |
| Address-dependent filtering | Only external IP addresses the host has contacted may reply | Middle ground; RFC 4787 suggests it where stricter filtering is needed |
| Address and port-dependent filtering | Only the exact external address and port contacted may reply | Strictest; can break some real-time media and peer-to-peer applications |
- Mapping timers: RFC 4787 requires UDP mappings to last at least two minutes and recommends five minutes or more, refreshed by outbound traffic. Allowing inbound packets to refresh a mapping lets an external party hold it open indefinitely, which the RFC advises against.
- Traversal techniques: STUN, TURN and ICE are designed to open paths through NAT for voice, video and WebRTC. They are legitimate, but they show that NAT state can be created by an application on request. See the VoIP and SIP Security Guide.
- Tunnels through NAT: IPsec moves to UDP 4500 (RFC 3948) and sends keepalives to keep mappings alive. Any protocol that can keep an outbound flow open can carry inbound control traffic, which is why ATT&CK T1572 Protocol Tunneling and T1090 Proxy matter more than NAT in practice. See the IPsec Security Guide.
Pinholes opened on request: port forwarding, UPnP, PCP and ALGs
The biggest practical risk is not NAT itself but the mechanisms that create inbound mappings automatically or without review.
- Static port forwards: typically added for a camera, RDP, a test server or a vendor's remote support tool, then forgotten. Treat every destination NAT rule as an internet-facing service: owner, justification, review date, and an entry in attack surface monitoring. See the Attack Surface Management Guide.
- UPnP Internet Gateway Device: lets any device on the LAN ask the router to open a port forward, with no authentication. Malware and insecure IoT devices use it to expose themselves. Disable UPnP on business routers and on the WAN interface everywhere; if a home or small office needs it, monitor the active mapping table.
- Port Control Protocol (PCP, RFC 6887): the standardised successor for requesting mappings, and the subscriber control mechanism RFC 6888 expects on carrier-grade NAT. RFC 6887 requires a PCP server to accept normal requests only on the interface the client normally uses and to ignore requests arriving on other interfaces, such as the WAN. The THIRD_PARTY option, which creates mappings for another internal address, should be disabled unless you have controls for it.
- Application Level Gateways (ALGs): NAT features that inspect protocols such as SIP, H.323 and FTP and open matching pinholes. The NAT Slipstreaming research published by Samy Kamkar in October 2020, extended with Armis in January 2021, showed that a web page could make a browser emit traffic that a router's SIP ALG treated as signalling, opening an inbound port to a host behind the NAT. Browsers added mitigations, but the root cause sits in the ALG. Disable ALGs you do not need, especially SIP ALG where a session border controller or SIP-aware firewall handles voice.
Carrier-grade NAT, shared addresses and attribution
When many users share one public address, the address stops being an identifier. This affects investigations, abuse handling and every control that trusts or blocks by IP.
- Attribution: RFC 6269 explains that abuse reports and legal requests identifying only an IPv4 address may point to many subscribers. A request needs source address, source port and an accurate timestamp to be answerable.
- Server-side logging: RFC 6302 (BCP 162) recommends that internet-facing servers log the source port and a UTC timestamp accurate to the second from a traceable time source such as NTP, plus transport protocol and destination port where several are used. Most web and VPN logs still omit the source port. See the NTP Security Guide.
- Collateral blocking: RFC 6269 notes that penalty boxes, CAPTCHAs and blocklists apply to the whole shared address, so one abusive user can lock out many legitimate ones, and that IP-only rate limiting stops working well. Combine IP signals with account, device and session signals.
- Port exhaustion: RFC 6888 requires CGNs to limit external ports per subscriber and recommends limits on mapping creation rate, because one infected host opening many connections can exhaust ports for everyone sharing the address.
- Port unpredictability: RFC 6888 lists making port numbers hard to guess as a goal of port allocation schemes, which conflicts with deterministic allocation used to reduce log volume. Operators trade one against the other.
| Log field | Where it must be captured | Why |
|---|---|---|
| Internal address and port | NAT device (firewall, CGN, cloud NAT gateway) | Identifies the internal host behind a translated flow |
| External (translated) address and port | NAT device | Joins NAT logs to external reports and server logs |
| Subscriber or tenant identifier | CGN or cloud NAT | RFC 6888 suggests it per mapping for operator attribution |
| Source port of the client | Internet-facing servers, load balancers, VPN gateways | RFC 6302 recommendation; without it a shared address cannot be resolved |
| Timestamp in UTC, accurate to the second | Everywhere | Mappings are reused quickly (RFC 6888 suggests a reuse delay of at least 120 seconds) |
| Transport protocol | Everywhere | Same port numbers are reused across TCP and UDP |
RFC 6888 also says a CGN should not log destination addresses or ports unless there is an administrative reason, which is a privacy consideration operators must balance against investigation needs. Retention and access to NAT logs should be set in policy. See the Log Management and Retention Guide.
Where identity fits
Many organisations use source IP as a proxy for identity: SaaS tenant IP restrictions, conditional access named locations, API key allowlists and partner firewall rules all trust "our" egress address. NAT changes what that trust means.
- Cloud NAT egress: workloads, CI/CD runners and AI agents leaving through a shared NAT gateway all present the same address, so an IP allowlist cannot tell a production service from a compromised build job. Pair allowlists with strong workload credentials. See the API Key Management Guide.
- Shared provider addresses: addresses from a provider's shared pool or a consumer CGN may be shared with strangers. Never allowlist an address you do not exclusively control.
- Conditional access: trusted locations based on office egress IPs should reduce friction, not remove MFA. See the Conditional Access Guide.
IPv6: losing NAT safely
IPv6 gives every host a globally routable address, so the incidental protection of NAT disappears. RFC 4864 sets out how to get the same benefits explicitly: stateful firewalls that allow only return traffic by default, short-lived privacy addresses, large randomised subnets that resist scanning, and Unique Local Addresses for internal-only traffic. The order of work matters:
- Inventory where IPv6 is already on: most operating systems enable it by default, and some ISPs and mobile networks deliver it without a change request.
- Write the inbound IPv6 policy first: default deny inbound, allow established and related, allow required ICMPv6 for neighbour discovery and path MTU discovery.
- Mirror IPv4 exposure deliberately: every IPv4 port forward should become an explicit IPv6 allow rule, reviewed, or be dropped.
- Test from outside: scan the IPv6 addresses of exposed hosts and confirm nothing is reachable that was not reachable via IPv4.
- Roll back cleanly: if the filter is not ready, disable IPv6 router advertisements on that segment rather than leaving hosts reachable.
Do not reintroduce NAT66 for "security": it adds the same operational cost without replacing the firewall. See the IPv6 Security Guide.
Implementation: auditing NAT on your network
- Export translation rules: list every destination NAT, static NAT and port forward on firewalls, routers, cloud NAT gateways and load balancers. Record owner, service and review date.
- Check filtering behaviour: confirm a stateful default-deny inbound policy exists independently of NAT on every boundary device, and on IPv6.
- Disable automatic pinholes: turn off UPnP, unused ALGs (SIP, H.323, FTP where not needed) and PCP THIRD_PARTY. Pilot on one site first, watch for broken voice or video, then roll out; roll back per feature, not wholesale.
- Fix logging: enable NAT session logging with translated ports, ensure NTP sync, and add source port to web server, VPN and load balancer logs.
- Compare inside and outside views: run external scans of all public addresses (including IPv6) and reconcile results with the translation rule list.
- Review IP-based trust: list every allowlist that references your egress addresses and confirm each one also requires a credential.
Detection and measurement
Watch the NAT device as well as the hosts behind it. ATT&CK T1599.001 Network Address Translation Traversal describes adversaries who control a boundary device modifying its NAT configuration to bridge networks that should be separated, so NAT rule changes are security events.
- Alert on new or changed destination NAT and static NAT rules outside a change window.
- Monitor the UPnP or PCP mapping table where these remain enabled, and alert on new inbound mappings.
- Watch for port allocation spikes per internal host or subscriber, which can indicate scanning malware or exhaustion attacks.
- Correlate NAT session logs with EDR and proxy data so an external report can be traced to a host within minutes.
| Metric | Target |
|---|---|
| Destination NAT rules with named owner and review date | 100 percent |
| Boundary devices with UPnP enabled on any interface | Zero in business networks |
| Externally reachable services not matching an approved rule (IPv4 and IPv6) | Zero |
| Internet-facing logs that include client source port and UTC time | 100 percent of critical services |
| Time to resolve a public address, port and timestamp to an internal host | Under one hour |
Framework mapping
| Framework | Reference | Relevance to NAT |
|---|---|---|
| NIST SP 800-53 Rev. 5 | SC-7, SC-7(5), CM-7, AU-12, SI-4 | Boundary protection, deny by default and allow by exception, disabling unneeded functions such as UPnP and ALGs, NAT logging, monitoring |
| NIST CSF 2.0 | PR.IR-01, DE.CM-01 | Protecting networks from unauthorised access; monitoring network services |
| CIS Controls v8.1 | Control 4 Secure Configuration; Control 12 Network Infrastructure Management; Control 13 Network Monitoring and Defense | Hardened router and firewall configuration, managed boundary devices, network logging |
| ISO/IEC 27001:2022 Annex A | A.8.20 Networks security; A.8.22 Segregation of networks | Network controls and separation that do not rely on translation |
| MITRE ATT&CK v20 | T1599.001, T1572, T1090, T1133, T1190 | NAT configuration abuse, tunnelling through NAT, proxies, exposed remote services and forwarded applications |
Common failure patterns
- "We are behind NAT, so we are safe": used to justify no inbound firewall policy, no egress filtering or no IPv6 policy. The filter must be explicit.
- Forgotten port forwards: RDP, SSH, NAS and camera forwards added for convenience and never removed become initial access paths (T1133, T1190).
- UPnP left on: consumer-grade routers in branches and home offices let any LAN device publish itself to the internet.
- SIP ALG enabled by default: breaks voice and creates pinhole risks such as those shown by NAT Slipstreaming.
- Logs that cannot be joined: no source port on servers, no NAT session logs, or clocks out of sync, so an abuse report or law enforcement request cannot be traced to a host.
- Trusting a shared egress IP: allowlisting a cloud NAT or CGN address as if it identified one system.
Practitioner checklist
- Document that NAT is not counted as a security control in your network standards; require explicit stateful default-deny inbound filtering.
- Inventory every destination NAT, static NAT and port forward with owner and review date, and remove unused entries.
- Disable UPnP on all business boundary devices and on every WAN interface.
- Disable unneeded ALGs, especially SIP ALG, and restrict PCP to the inside interface without THIRD_PARTY.
- Write and test the IPv6 inbound policy before or alongside any IPv6 enablement.
- Log NAT translations with ports and UTC time, and log client source ports on internet-facing services.
- Keep NAT and server clocks synchronised to a trusted NTP source.
- Pair every IP-based allowlist with a strong credential and never allowlist shared provider addresses.
- Alert on NAT rule changes and new automatic mappings.
Standards and references
- IETF: RFC 4864, Local Network Protection for IPv6
- IETF: RFC 4787, NAT Behavioral Requirements for Unicast UDP
- IETF: RFC 6888, Common Requirements for Carrier-Grade NATs
- IETF: RFC 6269, Issues with IP Address Sharing
- IETF: RFC 6302, Logging Recommendations for Internet-Facing Servers
- IETF: RFC 6887, Port Control Protocol (PCP)
- MITRE ATT&CK: Network Address Translation Traversal
- Samy Kamkar: NAT Slipstreaming
Related NHI Mgmt Group resources: Network Security Guide · IPv6 Security Guide · Firewall Management Guide · IPsec Security Guide · Attack Surface Management Guide