4.4 NAT Loopback & Policy-Based NAT

4.4 NAT Loopback & Policy-Based NAT

Quick Answer: NAT Loopback (hairpinning) enables internal clients to access internal servers using their public IP address or public FQDN. To eliminate fatal asymmetric routing across the local subnet, the Firebox performs a dual-NAT transformation: translating the destination IP to the server's private IP and translating the client's source IP to the Firebox internal interface IP. Policy-Based NAT overrides global NAT rules on a per-policy basis. Fireware enforces a strict NAT precedence hierarchy: Policy-Based NAT > 1-to-1 NAT > Dynamic NAT / Static NAT (SNAT).

The Hairpinning Challenge: Internal Access to Public Server IPs

In modern enterprise networks, mobile laptops, tablets, and remote workstations frequently move between external networks (home Wi-Fi, cellular hotspots) and the internal corporate LAN (Trusted or Optional networks). When configured to connect to corporate resources—such as an internal web application or customer portal—these endpoints typically reference the server's public Fully Qualified Domain Name (FQDN), such as portal.company.com.

In public DNS, portal.company.com resolves to the organization's public External IP address (e.g., 203.0.113.25). When a user brings their laptop into the office and connects to the Trusted network (10.0.1.0/24), their system continues to resolve portal.company.com to 203.0.113.25, even though the actual web server sits on the very same internal subnet or DMZ at 10.0.1.50.

Without specialized translation handling, this traffic flow fails completely. The process of routing internal client traffic out toward an external public IP and immediately looping it back to an internal private address is known as NAT Loopback or NAT Hairpinning.

---

Mechanics of Asymmetric Routing Without Dual-NAT

To understand why NAT Loopback requires specialized dual-NAT mechanics, examine the failure scenario that occurs if a security gateway performs only destination translation:

[Internal Client (10.0.1.100)] ---- (1. SYN to 203.0.113.25) ----> [Firebox (10.0.1.1)]
                                                                          |
                                                               (DNAT Rewrite Only)
                                                                          |
[Internal Client (10.0.1.100)] <--- (3. SYN/ACK direct Layer 2) --- [Server (10.0.1.50)]

1. Step 1: The internal client (10.0.1.100) sends a TCP SYN packet destined for public IP 203.0.113.25:443. Because 203.0.113.25 is outside the local subnet, the client forwards the frame to its default gateway: the Firebox (10.0.1.1).
2. Step 2: The Firebox inspects the destination IP (203.0.113.25) and matches an SNAT or 1-to-1 NAT rule pointing to internal server 10.0.1.50. If the Firebox rewrites only the destination IP, the packet transmitted onto the local network has:
   • Source IP: 10.0.1.100
   • Destination IP: 10.0.1.50
3. Step 3 (The Failure): The server receives the SYN packet. Because the source IP (10.0.1.100) resides on its own directly connected local subnet (10.0.1.0/24), the server does not send the SYN/ACK reply to its default gateway (the Firebox). Instead, it resolves the client's MAC address via ARP and transmits the SYN/ACK packet directly to the client across the local Ethernet switch.
4. Step 4 (Connection Teardown): The client receives a SYN/ACK from 10.0.1.50. However, the client's operating system is expecting a reply from 203.0.113.25. Because the IP addresses do not match, the client's TCP stack immediately discards the packet and transmits a TCP RST (Reset), terminating the connection.

This classic failure is known as asymmetric routing on a shared broadcast domain.

---

The Dual-NAT Solution in Fireware

To prevent this asymmetric routing failure, WatchGuard Fireware OS executes a coordinated Dual-NAT transformation whenever NAT Loopback is triggered:

1. Destination IP Translation (DNAT): The Firebox rewrites the destination IP from the public address (203.0.113.25) to the server's private address (10.0.1.50).
2. Source IP Translation (SNAT): Simultaneously, the Firebox rewrites the client's source IP from its original address (10.0.1.100) to the Firebox's own internal interface IP address (10.0.1.1).

+--------------------------------------------------------------------------------+
|                        Dual-NAT Loopback Transformation                        |
+-------------------+-----------------------------+------------------------------+
| Packet Leg        | Source IP : Port            | Destination IP : Port        |
+-------------------+-----------------------------+------------------------------+
| 1. Client -> FB   | 10.0.1.100 : 53210          | 203.0.113.25 : 443           |
| 2. FB -> Server   | 10.0.1.1 : 39482 (Rewritten)| 10.0.1.50 : 443 (Rewritten)  |
| 3. Server -> FB   | 10.0.1.50 : 443             | 10.0.1.1 : 39482             |
| 4. FB -> Client   | 203.0.113.25 : 443 (Restored| 10.0.1.100 : 53210 (Restored)|
+-------------------+-----------------------------+------------------------------+

When the server replies to 10.0.1.1, the packet is physically directed back to the Firebox. The Firebox reverses both translations in its state table, presenting the response to the client with Source IP: 203.0.113.25. The client receives the exact response it expected, and the three-way handshake completes successfully.

Enabling and Disabling NAT Loopback

In Fireware OS, NAT Loopback is enabled by default for all SNAT actions and 1-to-1 NAT configurations:

• SNAT Actions: Within the SNAT Action dialog, the Enable NAT Loopback checkbox is selected by default.
• 1-to-1 NAT Rules: Within the 1-to-1 NAT configuration, NAT Loopback is globally active for all mapped blocks.

Administrative Consideration: Because the server sees all loopback connections originating from the Firebox internal IP (10.0.1.1), server access logs cannot distinguish between different internal clients unless the application utilizes HTTP X-Forwarded-For headers inserted by an HTTP-proxy policy, or the organization implements Split-Brain (Split-Horizon) DNS to resolve the domain directly to the private IP internally.

---

Policy-Based NAT: Granular Rule Overrides

While global Dynamic NAT and 1-to-1 NAT apply universally across interfaces, Policy-Based NAT allows administrators to customize network address translation behavior within an individual firewall policy.

Policy-Based NAT is configured within the policy edit window under the NAT tab in Fireware Web UI or Policy Manager. It provides three primary operational modes:

1. Set Source IP (Policy Dynamic NAT): Forces all outbound traffic matching this specific policy to use a dedicated public IP address, overriding the interface's primary IP.
   • Enterprise Example: An enterprise owns a block of public IPs (203.0.113.10 to 203.0.113.14). General web traffic uses 203.0.113.10 via default Dynamic NAT. However, an outbound SMTP policy is configured with Policy-Based NAT set to 203.0.113.14. This ensures outgoing mail strictly originates from the IP tied to the public reverse DNS (PTR) record.
2. Use 1-to-1 NAT: Restricts or enforces 1-to-1 NAT translations exclusively for traffic matching that policy.
3. Disable NAT: Completely disables network address translation for traffic governed by the policy.
   • Enterprise Example: Routing traffic between a corporate Trusted network (10.0.1.0/24) and an internal partner network (172.16.50.0/24) over a dedicated leased line. Without Policy-Based NAT, the default Any-Trusted -> Any Dynamic NAT rule would rewrite the internal source IPs. Selecting Disable NAT inside the inter-site policy preserves the original RFC 1918 addresses.

---

Order of NAT Precedence in Fireware

When a packet traverses the Firebox, multiple NAT rules might theoretically match the traffic. To eliminate ambiguity, Fireware OS enforces a deterministic Order of NAT Precedence:

+--------------------------------------------------------------------------------+
|                       Fireware Order of NAT Precedence                         |
+--------------------------------------------------------------------------------+
|  1. POLICY-BASED NAT (Highest Priority)                                        |
|     - Configured directly inside the matching firewall policy                  |
|     - Overrides all global translation tables                                  |
|                            ↓                                                   |
|  2. 1-TO-1 NAT (Second Priority)                                               |
|     - Global bi-directional IP block mapping                                   |
|     - Evaluated if no Policy-Based NAT rule matches                            |
|                            ↓                                                   |
|  3. DYNAMIC NAT / STATIC NAT (SNAT) (Lowest Priority)                          |
|     - Global Dynamic NAT rules (Any-Trusted/Any-Optional to Any-External)       |
|     - Inbound destination SNAT actions referenced in policy 'To' lists         |
+--------------------------------------------------------------------------------+

Precedence Conflict Scenarios

Scenario 1: Policy-Based NAT vs. 1-to-1 NAT

Host 10.0.1.50 is mapped via 1-to-1 NAT to public IP 203.0.113.50. Under normal circumstances, any outbound connection from this host egresses with source IP 203.0.113.50. However, the administrator creates a dedicated backup policy for offsite archival that specifies Policy-Based NAT with source IP 203.0.113.99.

• Result: When 10.0.1.50 sends backup traffic matching this policy, Fireware applies Policy-Based NAT. The packet egresses with source IP 203.0.113.99. For all other traffic, the host uses its 1-to-1 NAT address (203.0.113.50).

Scenario 2: 1-to-1 NAT vs. Dynamic NAT

Host 10.0.1.75 resides on the Trusted network. The default Dynamic NAT rule specifies that all Trusted hosts egress using primary interface IP 203.0.113.2. A 1-to-1 NAT rule maps 10.0.1.75 to 203.0.113.75.

• Result: Because 1-to-1 NAT takes precedence over Dynamic NAT, outbound traffic from 10.0.1.75 is translated to 203.0.113.75. All other Trusted hosts continue using 203.0.113.2.

---

Diagnostic Verification & Troubleshooting

1. FSM Traffic Monitor Dual-NAT Verification

When an internal client triggers NAT Loopback, the Traffic Monitor logs both legs of the translation:

2026-09-21 14:48:02 Allow 10.0.1.100 203.0.113.25 https/tcp 53210 443 1-Trusted 1-Trusted HTTPS-proxy: Allowed (Loopback: 10.0.1.1:39482 -> 10.0.1.50:443)

Notice that the ingress interface is 1-Trusted and the egress interface is also 1-Trusted, confirming hairpinning. The source IP is rewritten to the Firebox interface IP (10.0.1.1), and the destination is rewritten to the private server IP (10.0.1.50).

2. Validating Policy-Based NAT in CLI

In the Fireware CLI, verify policy-specific NAT bindings using:

• show policy <PolicyName> — Displays detailed policy parameters including any configured source IP override or NAT disable flags.
• show connection — Filters active connections by policy to verify whether packets egress with the policy-specified NAT IP.