What Is NAT? How It Works and How It Is Classified

1.1 Name groups and what each one describes

NAT terms found in vendor and RFC documents describe different parts of the system. Collapsing every name into one flat list of types creates confusion. STUN, for example, is a protocol that assists NAT traversal, while CGNAT describes where NAT sits in a service provider network.

• Which part of the packet is translated: SNAT, DNAT, twice NAT
• State handling: stateful NAT, stateless NAT
• Policy: policy NAT, no-NAT, NAT exemption
• Deployment and usage: hairpin NAT, double NAT, CGNAT
• IP family: NAT44, NAT64, NAT46, NAT66
• Application helpers: STUN, TURN, ICE, PCP

1.2 One rule can carry several names at once

A fixed rule that translates a TCP destination from 203.0.113.10:443 to 10.10.10.20:8443 can be described as DNAT because it rewrites the destination, as static PAT because the IP and port mapping is fixed, and as NAT44 because both sides are IPv4.

Those three names do not mean the packet passes through three layers of NAT. They describe one rule from three angles.

Note that external addresses used throughout this article, such as 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24, and IPv6 under 2001:db8::/32, are documentation ranges. They are not addresses to publish services on the real internet.

2.1 Outbound internet access using SNAT and PAT

Suppose host 10.10.10.11 opens a TCP connection to web server 198.51.100.20:443 using source port 51514. The NAT gateway holds external address 203.0.113.10 and picks port 40001 for this translation.

The server sees its peer as 203.0.113.10:40001, while the gateway keeps the relationship needed to return the reply to 10.10.10.11:51514. Using the port alongside the IP is what lets the gateway separate traffic from many hosts that share one external address.

2.2 NAT mapping versus session state

A device may keep NAT mappings and connection state in separate tables, and one mapping may relate to several sessions depending on the design. Stateful NAT64, for instance, separates the binding information base from the session table explicitly.

For TCP and UDP, a 5-tuple of protocol, source IP, source port, destination IP, and destination port is commonly used to distinguish flows. Matching a reply back to a host therefore does not always rely on the public IP and public port alone. Some systems also use destination data, which allows the same external IP and port to serve connections with different destinations.

In Linux nftables stateful NAT, the first packet of a flow selects the rule and creates the NAT binding, and later packets reuse it. Changing a rule may therefore not change the behaviour of connections that are already open. Test with a new connection, or clear the relevant sessions first.

2.3 Checksums, ICMP, and packets without ports

Changing an IPv4 address affects the IPv4 header checksum, and may affect the TCP or UDP checksum because those calculations include the IP address. A NAT device must adjust the checksums affected by the translation according to protocol rules.

ICMP, such as ping, has no TCP or UDP port, but it does carry an identifier that NAT can use to separate conversations. ICMP errors may also embed part of the original packet, and NAT must handle the addresses or identifiers inside that embedded data so the sending host can match the error to the right conversation.

3.1 Address-only static NAT

Address-only static NAT fixes the relationship between an original IP and its replacement, for example 10.10.10.50 paired with 203.0.113.50. In a source translation, 10.10.10.50:51000 becomes 203.0.113.50:51000 with the port unchanged.

This form suits systems that need a predictable address, such as a server that must reach a partner using a specific source IP.

A fixed pairing must be considered together with the direction in which sessions may be initiated and with security policy. Creating a single static source NAT rule does not guarantee that every vendor will automatically accept new inbound connections as well.

3.2 Address-only dynamic NAT

Address-only dynamic NAT picks an IP from a pool and pairs it with an internal host on demand, for example internal network 10.10.10.0/24 with an external pool of 203.0.113.100 to 203.0.113.109. When a host starts communicating, the device assigns a free address from the pool. Once the mapping expires or the resource is released, that address becomes available again.

With ten addresses, and assuming one external IP per internal host without PAT, ten hosts can hold mappings at once. Each host can still open many connections through the address it received, so this is not a limit of ten connections in total.

When the pool is exhausted, hosts without a mapping may be unable to start communicating even though link bandwidth is still available.

3.3 Dynamic PAT, NAPT, and NAT overload

PAT, or port address translation, uses IP and port together. NAPT stands for network address port translation. Dynamic PAT allocation lets many hosts share one external address, and it may also use a pool of several addresses.

When two hosts contact the same TCP server, 10.10.10.11:50000 may be translated to 203.0.113.10:40001 while 10.10.10.12:50000 becomes 203.0.113.10:40002. Both hosts used the same source port, but NAT chose external mappings that keep the replies separable.

PAT does not have to change the port every time. Some devices try to keep the original port, which is called port preservation, and choose another only when that is not possible. Seeing an unchanged port after NAT therefore does not prove the translation was address-only.

3.4 Static PAT and port forwarding

Static PAT fixes the mapping of IP, protocol, and port. Using it to accept inbound service traffic is commonly called port forwarding, and the external and internal ports may be the same or different.

One external address can therefore serve many systems by separating destinations with protocol and port. A TCP/443 rule and a UDP/443 rule are different mappings even though the port number matches.

Translating 443 to 8443 changes only the destination port. The internal service must still speak the protocol the client uses. NAT does not terminate TLS or convert HTTPS to HTTP as a side effect of changing the port.

4.1 Source NAT rewrites source data

Source NAT, or SNAT, changes the source IP and may change the source port. A common outbound form takes 10.10.10.11:51514 before translation and produces 203.0.113.10:40001 after it.

SNAT works with static address mappings, dynamic address pools, and dynamic PAT. The choice depends on whether you need a fixed address, a per-host allocation, or many hosts sharing one address through ports.

Although it is often used for outbound traffic, source refers to the packet source rather than a direction. In hairpin NAT, for example, SNAT may be needed so that a connection between an internal client and an internal server returns through the gateway.

4.2 Destination NAT rewrites destination data

Destination NAT, or DNAT, changes the destination IP and may change the destination port, for example accepting HTTPS from outside and forwarding it to an internal server. Before DNAT the packet is 198.51.100.60:51000 to 203.0.113.50:443, and after DNAT it is 198.51.100.60:51000 to 10.10.10.50:443.

The client source IP is untouched in this example, so the server sees 198.51.100.60 as the origin unless SNAT or another middlebox changes the source as well.

With stateful DNAT, the device uses existing state to translate replies so the client sees the source as 203.0.113.50:443. No extra SNAT rule is needed merely to carry that session back. Letting the server initiate new outbound connections from the same public IP is a separate requirement.

Some devices can select a destination from several servers. PAN-OS, for example, offers dynamic IP destination NAT with session distribution using round robin or source IP hash. This capability is distinct from an application load balancer, which may add health checks or decisions based on HTTP content.

REDIRECT in Linux is a special form of DNAT that sends traffic to the machine performing NAT itself, such as a proxy service on the gateway. It differs from DNAT to another host, and from an HTTP redirect, which instructs the client to request a new URL.

4.3 Twice NAT rewrites both source and destination

Twice NAT, in the mechanical sense, translates both source and destination. It applies when joining networks that use overlapping addresses, because both the address used to reach the far side and the address the far side replies to may need substitutes.

Suppose site A and site B both use 192.168.1.0/24, with client 192.168.1.10 at site A and server 192.168.1.20 at site B. If site A reaches server B through 10.20.1.20 and site B sees client A as 10.10.1.10, the packet goes from 192.168.1.10 to 10.20.1.20 before translation, and arrives at site B as 10.10.1.10 to 192.168.1.20.

The client never has to address a subnet that collides with its own, and the server has a reply address separate from its local network. The design still needs routes for the substitute addresses, plus DNS and VPN policy that match the state before and after translation.

Some products use full NAT to mean SNAT and DNAT applied together, while twice NAT on Cisco ASA is also the name of a rule style that binds source and destination together, where one side may use identity mapping. Read the meaning according to the platform.

4.4 Session direction and bidirectional NAT

A session started from inside will naturally receive reply packets from outside. Accepting return packets and allowing an outside party to start a new session are therefore two different conditions.

Bidirectional NAT describes a mapping that supports new sessions from either side, subject to security policy. Some systems offer a bidirectional option on static source NAT, while others require an explicit destination translation as well.

5.1 Policy NAT and conditional NAT

Policy NAT selects a mapping based on conditions such as source, destination, service, interface, or zone, so one host can use different translated addresses for different work. Host 10.10.10.50 might use source IP 203.0.113.50 toward partner A, 203.0.113.10 toward the internet, and keep its original source IP toward branches over VPN.

Policy NAT must agree with routing. A rule that selects the source IP of WAN A while traffic actually leaves through WAN B can produce a return path that does not match the design. Deciding which address to translate to must be checked together with forwarding path selection.

5.2 No-NAT, NAT exemption, and identity NAT

No-NAT and NAT exemption both describe configuring certain traffic so it is not translated, for example keeping original addresses between head office and branch while internet traffic still uses PAT. How the exemption is configured depends on the device.

Cisco ASA offers identity NAT, a static mapping that pairs an address with itself. The relationship between the three terms is that identity NAT is a way to build a mapping, while no-NAT and NAT exemption describe the intended policy outcome. Other devices achieve the same result with a rule that specifies neither source nor destination translation.

On systems that apply the first matching rule, place exemptions before broader rules. Otherwise branch traffic may be captured by the internet PAT rule first. Even where no translation happens, a security policy must still permit the traffic.

6.1 Masquerade uses the outgoing interface address

Masquerade in Linux is a form of SNAT that uses the output interface address as the translated address. It suits WAN links whose IP may change, because the rule does not have to reference a fixed external number.

Dynamic in dynamic NAT and a dynamically assigned WAN IP are different things. Dynamic NAT refers to mapping allocation, while a dynamic WAN IP refers to the address the interface receives. Using the interface address lets rules follow a new address, but connections built on the old address may need to be re-established when the WAN IP changes.

6.2 Network NAT, subnet NAT, and NETMAP

Network or prefix mapping defines a relationship across a whole address range, for example 10.10.10.0/24 paired with 172.20.10.0/24. When the host bits are preserved, 10.10.10.11 becomes 172.20.10.11 and 10.10.10.80 becomes 172.20.10.80.

That removes the need to write a mapping per host. It relates to fixed address translation across an entire prefix and can be applied to source or destination translation as the task requires. nftables prefix NAT mapping is one example of this capability.

6.3 Hairpin NAT, NAT loopback, and NAT reflection

Hairpin NAT lets an internal client reach a server behind the same NAT using the external address of the service, for example when office users resolve a hostname to the office public IP.

Suppose the client is 10.10.10.11, the server is 10.10.10.50, the LAN gateway is 10.10.10.1, and the public service IP is 203.0.113.50. With DNAT alone, when client and server share a subnet the server may reply directly to the client without returning through the gateway, so the reply carries source 10.10.10.50 even though the client addressed 203.0.113.50.

One approach adds SNAT so the server sees the gateway as the source and replies through it, where state exists to translate back and present the original public IP to the client. The side effect is that the server no longer sees the real client address. Whether the extra SNAT is required depends on the return path, not on a rule that every hairpin topology must use the gateway LAN address.

Split DNS is another option, answering with an internal address for internal users and an external address for external users. DNS can change the address but not the port, so if the outside uses 443 while the internal service listens only on 8443, changing the DNS answer alone may still not work.

6.4 Double NAT, passing through two layers

Double NAT occurs when traffic is translated at two points, for example client 192.168.10.20 behind an inner router whose WAN is 192.168.1.2, which in turn sits behind an internet router whose WAN is 203.0.113.10.

Accepting a new inbound connection requires passing the mapping and filtering of both layers. Creating a port forward on the inner router does not create a matching mapping on the outer one.

Double NAT refers to the number of translation layers, while twice NAT refers to translating both source and destination of a packet. The two terms are not interchangeable.

6.5 CGNAT, carrier-grade NAT, and large-scale NAT

CGNAT is NAT inside a service provider network so several customers can share public IPv4. A customer may control NAT on their own router but cannot define mappings on the provider CGN directly.

The address range reserved as shared address space is 100.64.0.0/10. It is separate from RFC 1918 private addresses and is not a public address for global routing. Finding a WAN address in this range is a reason to check whether a CGN sits in front, while still confirming the topology with the provider.

When NAT exists at both the customer router and the provider, the result is called NAT444. The digits refer to three IPv4 address spaces. That form has two translation points, not three NAT devices, and CGNAT can also be deployed without customer-side NAT.

Publishing a service from outside requires a path through the CGN, such as a mapping the provider allocates, or an architecture that connects outward to a relay or tunnel. Setting up DDNS only changes the name to address relationship. It does not create a mapping on the CGN.

6.6 Port block allocation and deterministic NAT

Both terms concern port allocation and user traceability, particularly in systems where many users share IPv4.

Port block allocation, or PBA, assigns ports in blocks to a user or internal address rather than independently per connection. Deterministic NAT uses rules that allow the relationship between a user, a public IP, and a port range to be computed in reverse, which reduces the log volume some architectures need to keep.

PBA is not necessarily deterministic, since some systems allocate blocks dynamically or add more when the first block is exhausted. These details affect what must be recorded to identify a user after the fact.

7.1 Stateful and stateless NAT

Stateful NAT relies on mapping or flow state to translate related packets, dynamic PAT being the common case. If that state is lost, open connections may stop working even though the NAT rules are all still present.

Stateless NAT computes the translation from rules and packet data, without a dynamic binding or per-flow NAT state. SIIT and NPTv6 are examples. Having no state in the NAT function does not prevent the same device from keeping state for a stateful firewall.

Static and stateless describe different things. Static says the mapping is fixed, while stateless says the translation does not need per-flow state. A static mapping can therefore work alongside stateful connection tracking.

7.2 Mapping behaviour and filtering behaviour

When an internal endpoint contacts several destinations, two behaviours must be separated. Mapping behaviour states whether NAT reuses the same mapping when the destination changes. Filtering behaviour states which external endpoints may send packets to that mapping.

A device can have EIM together with APDF, reusing one mapping across destinations while still filtering inbound packets by the remote endpoints it has contacted. Knowing the mapping behaviour alone is therefore not enough to conclude which external peers can reach in.

7.3 Full cone, restricted cone, and symmetric NAT

The cone and symmetric labels come from the UDP NAT model in the original STUN specification, but describing real devices with mapping and filtering separately gives more detail.

Full cone does not mean the device opens every port of every internal host without a mapping, and it does not cancel other security policy. Symmetric NAT must be read according to the definition used by the tool or product reporting it, because the older labels may not describe every aspect of a system.

8.1 Stateful NAT64 and DNS64

Stateful NAT64 lets IPv6 clients reach IPv4 servers by allocating an IPv4 address and transport identifier on the external side, then keeping state to translate replies back to IPv6. Replies to an existing session return through the same NAT64 without a separate NAT46. Letting an IPv4 host start a new session toward an IPv6 host requires a mapping and supporting conditions such as a static binding.

DNS64 synthesises AAAA records from A records so IPv6 clients receive an address that points through the translator to the IPv4 server. DNS64 handles the DNS answer, while NAT64 handles packet translation.

As an example of embedding IPv4 in IPv6 with a /96 documentation prefix, IPv4 server 192.0.2.80 with translation prefix 2001:db8:64::/96 becomes 2001:db8:64::c000:250, where the trailing c000:250 is 192.0.2.80 in hexadecimal.

DNS64 alone does not fix applications that use IPv4 literals or reach IPv4 without DNS, and using it with DNSSEC requires deciding carefully where answers are validated.

8.2 SIIT, stateless translation, and SIIT-DC

SIIT, or stateless IP/ICMP translation, converts headers between IPv4 and IPv6 using defined address mapping rules without creating per-flow dynamic bindings. The algorithm is described in RFC 7915, which replaced RFC 6145.

Stateless translation requires an address plan that supports reverse translation. The SIIT algorithm itself does not provide IPv4 sharing in the way dynamic PAT does.

SIIT-DC applies the idea to data centres so services on an IPv6 network are reachable from IPv4 through border relays and defined address mapping. It is a service architecture, not an additional kind of mapping.

8.3 464XLAT

464XLAT combines two translators so IPv4 applications work across an IPv6 network. CLAT performs stateless IPv4 to IPv6 translation on the client side, and PLAT performs stateful NAT64 toward IPv4 on the service side. This covers cases where an application still requires IPv4, which DNS64 alone cannot handle.

8.4 NAT66 and NPTv6

NAT66 is a broad name for IPv6 to IPv6 translation. NPTv6, defined in RFC 6296, is a specific prefix translation that is stateless, bidirectional, and checksum-neutral, published in the experimental category.

NPTv6 does not aggregate many hosts behind one address using ports the way PAT does. The algorithm may adjust other parts of the IPv6 address to compensate for the prefix change so transport checksums remain valid without editing TCP or UDP headers.

It is therefore wrong to describe NPTv6 as simply changing the prefix and preserving every other bit, and leaving transport headers untouched does not guarantee that applications embedding IP addresses in payloads are unaffected.

8.5 NAT-PT and the DS-Lite, MAP-T, MAP-E architectures

NAT-PT and NAPT-PT are older IPv4 and IPv6 translation approaches. RFC 4966 moved NAT-PT to historic status because of architectural limitations, so when reading older documents, keep these names separate from NAT64 and SIIT.

DS-Lite encapsulates IPv4 over IPv6 toward an AFTR with NAT44 on the provider side. MAP-T uses translation with address and port set mapping rules. MAP-E uses encapsulation of IPv4 over IPv6, where the customer side may run NAPT44 within the port set it receives.

Translation changes headers between protocols, while encapsulation wraps the original packet inside another protocol, so they should not all be called NAT64.

10.1 SIP registers successfully but audio does not pass

SIP separates signalling, which sets up and controls calls, from media such as RTP that carries audio or video. A successful registration therefore does not confirm that the media path works in both directions.

SIP carries media details in SDP, which states addresses and ports inside the message body, for example the lines c=IN IP4 10.10.10.50 and m=audio 20000 RTP/AVP 0 8. Here SDP advertises 10.10.10.50 for media and port 20000 for audio. Translating the outer IP header does not change those lines.

If the far end sends audio to an unreachable private address, the result is no audio or one-way audio. Diagnosis must therefore examine SIP, SDP, and the RTP actually exchanged, not only the registration status.

10.2 SIP ALG and SBC

An application layer gateway, or ALG, handles protocols that carry addresses or ports inside the payload, potentially editing messages and creating related state. Support depends on how well the ALG understands the protocol and how compatible it is with the application.

For SIP, decide explicitly which component, whether the PBX, the endpoint, the SBC, or the ALG, is responsible for advertising addresses and steering media. Editing the same data in several places can produce results the far end does not expect, so verify with a packet capture rather than switching an ALG on or off without understanding the design.

An SBC handles SIP signalling and media according to product capability, including media relay, access control, and limiting what is exposed outside the network. Configuring static NAT for a PBX does not give the NAT gateway those functions.

When signalling is encrypted, a device that is not an endpoint of the encryption cannot read or edit the payload the way it could with cleartext. Designing SIP over TLS therefore requires considering where message-handling devices sit.

10.3 IPsec NAT-T and NAT exemption

IPsec NAT-T encapsulates ESP in UDP to pass through NAT, generally involving UDP/4500, while NAT exemption keeps certain traffic unchanged. Both can appear in one system. Packets inside the VPN from 10.10.10.0/24 to 10.20.20.0/24 may keep their original addresses under a no-NAT rule, while the outer packets from the VPN gateway pass a NAT router and use NAT-T to carry ESP through it.

Diagnosis must separate the inner packet inside the tunnel from the outer packet carrying the VPN across the external network. Networks with overlapping addresses may also need inner address translation, so not every VPN requires no-NAT.

ESP uses IP protocol number 50, not TCP or UDP port 50, and AH protects parts of the IP header, which conflicts with changing addresses in transit. These details are why IPsec needs specific measures to cope with NAT.

10.4 Other protocols that embed addresses in payloads

Some FTP modes and other protocols announce the address or port of an additional connection inside the control channel. Translating headers alone may therefore be insufficient. Choose a suitable operating mode, use a traversal mechanism or a capable ALG, and remember that encrypted payloads greatly limit in-transit message editing.

11.1 Forward and return paths

Stateful NAT requires related packets to pass the point that holds the correct state. If traffic leaves through firewall A but returns through firewall B without the same state, reverse translation or session inspection can fail. High availability designs must therefore consider both state synchronisation and traffic paths.

Public addresses used in NAT rules also need a path to reach the gateway, such as an upstream route or suitable ARP responses. Adding an address to a NAT rule does not guarantee that the upstream network will deliver packets to that device.

Processing order differs by platform. PAN-OS, for example, evaluates security policy using pre-NAT source and destination addresses with post-NAT zones. Copying an assumption about whether policy uses pre-NAT or post-NAT addresses from another vendor can leave rules that never match.

11.2 Port count is not the same as maximum sessions

The claim that one public IP supports 65,535 sessions is not a fixed limit for every NAT system. TCP and UDP ports are 16 bits, but the usable count depends on the allocated port range, reserved ports, and whether mappings are reused across different destinations.

As a worked assumption, four public addresses with 60,000 usable ports each, considering one protocol where every connection reaches the same remote IP and port, gives roughly 240,000 mapping entries.

That number is still not the session capacity of the device. Concurrent sessions, new connection rate, packets per second, throughput, and connection tracking resources must all be checked, especially where many users contend for the same addresses and ports.

11.3 Timeouts and keepalives

UDP has no connection teardown like TCP, so NAT relies on timers and traffic behaviour to keep or clear state. TCP has connection states and several timeout phases.

A timeout that is too short can drop a mapping while the application still needs it, while one that is too long leaves stale state consuming resources. Keepalive intervals must therefore relate to the timeouts of devices along the path, and the default of one firewall model should not be assumed to apply everywhere.

11.4 Logging and user identification

Where a public IP is shared, knowing the IP alone is not enough to identify a user. Public IP, port, protocol, and time must be correlated with the mapping or port block allocated to that user.

If the system reuses the same external IP and port for several connections with different destinations, analysis may also need the destination IP and port, depending on how the device allocates. Check the NAT behaviour before deciding which log fields to retain.

In practice, also verify that the clocks of the NAT gateway, the authentication system, and the log store agree closely enough to correlate events, especially when mappings are reused within a short interval.

11.5 The roles of NAT and firewall

NAT is responsible for address translation, and the firewall is responsible for permitting or denying traffic. The fact that some dynamic mappings will not accept new inbound connections without state does not replace a security policy, and it does not encrypt the traffic passing through.

IPv6 can use a stateful firewall to permit outbound connections and their replies while denying new inbound connections, with no NAT involved. Choosing NAT66 or NPTv6 should therefore be justified by addressing or interconnection requirements.

12.1 Cautions when diagnosing

The table above is a starting point, not a confirmation of cause from a symptom alone. The method is to trace mappings, state, and traffic paths, plus application-level data when the protocol embeds addresses in its payload.

A small ping passing does not confirm that packets of every size pass. Fragmentation and the ICMP errors related to path MTU must also be checked, particularly across IPv4 and IPv6 translation where header sizes differ.

After changing a rule, test with a new connection first. If sessions must be cleared, clear only the entries relevant to the test so other active traffic is not interrupted.

12.2 Documenting a NAT rule

Record the purpose, the pre-translation condition, the post-translation result, and the return path.

• Purpose: publish HTTPS to external users
• Condition: TCP toward 203.0.113.10:443
• Translation: destination becomes 10.10.10.20:8443, client source unchanged
• Rule description: DNAT combined with static PAT and NAT44
• Operating requirements: a security policy permits it, the server listens on TCP/8443, and replies return through a gateway holding the connection state
• Verification: open a new connection and capture packets before and after NAT in both directions