Split NAT Server Configuration and Source‑Return Path in USG Firewalls

The firewall, acting as an outbound gateway, often needs to expose a private server with two different public IP addresses when connected to two ISPs; this is achieved by splitting the NAT server configuration.

Two methods exist: (1) placing each ISP’s public interface in a different security zone and adding the zone parameter to the NAT server command, and (2) keeping both interfaces in the same zone but using the no-reverse parameter to prevent reverse Server‑map entries.

Example of the zone method: [FW] nat server zone untrust1 protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 [FW] nat server zone untrust2 protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80

Example of the no‑reverse method: [FW] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 no-reverse [FW] nat server protocol tcp global 2.2.2.2 9980 inside 10.1.1.2 80 no-reverse

Without no-reverse , the two commands cannot be issued simultaneously because they would generate conflicting reverse Server‑map entries, causing the firewall to map the same source address to two different public addresses.

When the split configuration is used, response packets may exit through a different ISP than the request entered, leading to asymmetric routing; to enforce source‑return, USG9000 series firewalls use the redirect-reverse command on the public interface, e.g., [FW] interface GigabitEthernet 1/0/1 [FW-GigabitEthernet1/0/1] redirect-reverse next-hop 1.1.1.254

USG2000/5000 series use reverse-route next-hop next-hop-address , while USG6000 series enable reverse-route enable and configure a gateway on the interface.

In dual‑firewall (active‑standby) deployments, each firewall generates a free ARP request for the NAT server’s public IP when that IP resides in the same subnet as the interface, resulting in duplicate‑IP logs such as: 2014-05-11 10:02:22 FW1%%01ARP/4/DUP_IPADDR(l): Receive an ARP packet with duplicate ip address 1.1.1.1 from GigabitEthernet0/0/1, source MAC is 0000-003a-f701

Both firewalls send ARP replies, causing the client’s ARP table to flip between the two MAC addresses and leading to intermittent connectivity because the standby firewall discards traffic.

Adding the vrrp keyword to the NAT server command resolves the issue by ensuring only the active firewall sends ARP replies and that the client always uses the VRRP virtual MAC, e.g., [FW1] nat server protocol tcp global 1.1.1.1 9980 inside 10.1.1.2 80 vrrp 1

After this change, duplicate‑IP logs disappear, ARP replies originate solely from the active firewall with the VRRP virtual MAC (e.g., 0000-5e00-0101), and client traffic consistently reaches the active device, achieving a stable source‑return path.

In summary, the article covers the three‑step “NAT Server” mantra: using zones or no-reverse , configuring source‑return with redirect-reverse / reverse-route , and employing VRRP to eliminate ARP conflicts in multi‑ISP, dual‑firewall environments.