[ Glossary ]

Network Address Translation (NAT)

Network Address Translation (NAT) is a function that maps private IP addresses inside a network to a public IP address used on the internet. It lets multiple internal devices share one external address, conserving public IPv4 addresses and hiding internal network details from outside traffic.

What Is Network Address Translation (NAT)?

Key takeaways

NAT translates private, internal IP addresses into a public address so internal devices can reach the internet without each one needing its own routable IP.
NAT rules are configured alongside security rules on firewalls, routers, and cloud gateways, and they directly affect how traffic is matched and permitted.
NAT conserves scarce IPv4 addresses and adds a layer of obscurity, since outside networks only see the translated address, not the internal host.
Because NAT changes the addresses a packet carries, it changes what a firewall rule has to match, which makes NAT a frequent source of rule errors and troubleshooting time.

Why NAT Matters

NAT exists because of a simple math problem: there are far more devices than there are public IPv4 addresses to give each one. By letting a whole private network share one or a small number of public addresses, NAT solved that shortage and became a near-universal feature of routers, firewalls, and cloud gateways. For network and security teams, NAT also changes what a firewall rule actually has to match. A rule written for an internal address won't match traffic once NAT has rewritten that address for the public side, so NAT and firewall rules have to be designed and reviewed together, not as separate layers.

How NAT Works

A NAT rule defines how an address, or a range of addresses, gets rewritten as traffic crosses from one side of a device to the other. The most common form, sometimes called network object NAT, applies translation as a property of a network object, whether that object is a single host, a range of addresses, or an entire subnet. A related technique, Port Address Translation (PAT), lets many internal hosts share a single public address by also rewriting the port number, which is why one public IP can represent hundreds of internal devices at once. NAT rules typically sit next to security rules in a device's configuration, and most platforms evaluate them as part of the same policy set that controls what traffic is allowed through in the first place.

A Realistic Example

Picture a branch office with 200 workstations behind a single firewall. Rather than assigning each workstation a public IP address, the firewall uses a single NAT rule to translate all outbound traffic from the internal 10.0.0.0/8 range to one public address. From the internet's point of view, the whole branch looks like one device. When the security team later adds a rule to allow a new vendor's SaaS application, they have to account for the fact that the vendor will see traffic coming from the NAT'd public address, not from any individual workstation, which affects how the allow rule and any logging get written.

The Operational Consequence

When NAT and firewall rules aren't reviewed together, two problems show up repeatedly. First, a security rule written against the wrong side of a NAT translation (pre-NAT instead of post-NAT addressing, or the reverse) can silently fail to match traffic, creating an outage that looks like a firewall problem but is actually a NAT misconfiguration. Second, NAT rules themselves can accumulate the same way security rules do: unused translations, overlapping address mappings, and rules nobody remembers the purpose of. Both problems slow down troubleshooting and change management, and both increase the time it takes to answer a basic question during an audit: what does this rule actually allow, and for whom?

Key Components and Best Practices

Clear NAT management rests on a few habits: documenting the business reason for each NAT rule the same way you'd document a security rule, keeping pre-NAT and post-NAT addressing visible together so rule writers don't have to guess which side a rule should match, and reviewing NAT rules for staleness on the same cadence as security rule recertification. Treating NAT as part of the policy set, rather than a separate network configuration, keeps rule logic consistent and easier to audit.

Common Challenges

The most common NAT-related issues are address confusion (writing a rule against the wrong side of a translation), rule sprawl (NAT mappings that outlive the systems they supported), and visibility gaps across multiple firewall vendors that each display NAT differently. In hybrid environments with a mix of on-premises firewalls and cloud security groups, those inconsistencies multiply, making it harder to get one accurate picture of what's actually allowed between networks.

NAT, Network Security Policy Management, and FireMon

NAT rules are part of the broader security policy, alongside security rules, objects, and network architecture, that network security policy management (NSPM) exists to govern; for the management discipline itself, see the Network Security Policy Management glossary page. Policy is the control plane for network security, and NAT rules are one of the pieces that control plane has to account for, since a NAT misconfiguration can break or expose access as easily as a bad security rule. FireMon, the founder of NSPM, tracks NAT rules as part of a device's full policy, alongside security rules and objects, so teams can see how NAT and access rules interact, and review both as part of the same change and audit process rather than two disconnected configurations.

Frequently Asked Questions

NAT translates one internal address to one external address, while Port Address Translation (PAT) lets many internal addresses share a single external address by also rewriting port numbers. PAT is the most common form of NAT in use today because it lets an entire network share one public IP.

NAT adds a degree of obscurity because outside networks see only the translated address, not internal host addresses, but it isn't a security control by itself. Firewalls, not NAT, are responsible for deciding what traffic is actually allowed through.

NAT rewrites the addresses a packet carries, so a security rule written against the pre-translation address won't match traffic once NAT has changed it, or the reverse. This mismatch is a common cause of connectivity issues that look like firewall failures but are actually NAT configuration errors.

IPv6's larger address space removes the original reason for NAT, since there are enough addresses for every device to have its own, but many organizations still use NAT-style translation during IPv4-to-IPv6 transitions or for specific routing needs.

NAT rules are typically configured and displayed alongside security rules, network objects, and other policy elements on the same device, since most firewalls evaluate NAT as part of the same rule processing path that handles access control.