4.3 1-to-1 NAT

4.3 1-to-1 NAT

Quick Answer: 1-to-1 NAT creates a bi-directional, full-range IP address mapping between a public IP address (or contiguous range) and an internal private IP address (or contiguous range). Unlike SNAT, 1-to-1 NAT automatically translates both inbound destination IP and outbound source IP for all ports and protocols without port translation. 1-to-1 NAT handles address translation only; inbound traffic still requires explicit firewall policies to permit access.

Architecture of 1-to-1 NAT

In many enterprise environments, specific internal servers require full, multi-protocol exposure to external networks. For example, a unified communications server or VoIP PBX may utilize SIP signaling on UDP/TCP port 5060, secure SIP on TLS 5061, and dynamically negotiated Real-time Transport Protocol (RTP) audio/video media streams across thousands of ephemeral UDP ports (e.g., ports 10000–20000). Attempting to configure individual Static NAT (SNAT) actions for such broad, dynamic port ranges is administratively complex and prone to failure.

1-to-1 NAT resolves this challenge by creating a dedicated, bi-directional mathematical mapping between an external public IP address and an internal private IP address. When 1-to-1 NAT is active:

• Inbound Traffic: Packets arriving on the External interface addressed to the public IP have their destination IP translated to the corresponding internal private IP address.
• Outbound Traffic: Packets originating from that internal private IP exiting the External interface have their source IP automatically translated to that specific public IP address, cleanly overriding the default Dynamic NAT rule.

+--------------------------------------------------------------------------------+
|                       1-to-1 NAT Bi-Directional Mapping                        |
+--------------------------------------------------------------------------------+
|  [Inbound: Destination NAT]                                                    |
|  Public IP: 203.0.113.50 --------(DNAT Rewrite)-------> Private IP: 10.0.1.50 |
|                                                                                |
|  [Outbound: Source NAT]                                                        |
|  Private IP: 10.0.1.50 --------(SNAT Rewrite)-------> Public IP: 203.0.113.50 |
+--------------------------------------------------------------------------------+

---

Configuration Elements: NAT Base, Real Base, & Host Counts

1-to-1 NAT is configured globally under Network > 1-to-1 NAT in Fireware Web UI or Policy Manager. Rather than requiring administrators to enter each server mapping individually, Fireware uses a streamlined mathematical block definition:

1. Interface: The interface on which the public IP addresses reside (almost always an External interface).
2. NAT Base: The starting public IPv4 address of the translation range (e.g., 203.0.113.50).
3. Real Base: The starting private IPv4 address of the internal hosts on the Trusted, Optional, or Custom network (e.g., 10.0.1.50).
4. Number of Hosts: An integer specifying the count of contiguous IP addresses in the block.

Mathematical Offset Calculation

Fireware maps addresses sequentially by applying an identical offset index ($i$) to both the NAT Base and the Real Base: $\text{Public IP}_i = \text{NAT Base} + i$ $\text{Private IP}_i = \text{Real Base} + i$ where $i$ ranges from $0$ to $(\text{Number of Hosts} - 1)$.

Contiguous Range Mapping Example:

• Interface: Eth0 (External)
• NAT Base: 203.0.113.50
• Real Base: 10.0.1.50
• Number of Hosts: 4

+-------------+---------------------+----------------------+
| Host Index  | Public IP (NAT Base)| Private IP (Real Base|
+-------------+---------------------+----------------------+
| Host 0      | 203.0.113.50        | 10.0.1.50            |
| Host 1      | 203.0.113.51        | 10.0.1.51            |
| Host 2      | 203.0.113.52        | 10.0.1.52            |
| Host 3      | 203.0.113.53        | 10.0.1.53            |
+-------------+---------------------+----------------------+

To map a single server, the administrator simply sets Number of Hosts to 1.

---

1-to-1 NAT vs. Static NAT (SNAT) vs. Dynamic NAT

Understanding when to deploy 1-to-1 NAT versus SNAT or Dynamic NAT is one of the most heavily tested domains on the WatchGuard certification exam.

---

Policy Integration & Security Rule Enforcement

A critical misconception among novice administrators is assuming that defining a 1-to-1 NAT rule exposes the internal server directly to the Internet without firewall protection. 1-to-1 NAT handles address translation only; it provides zero packet filtering or access authorization.

When an external packet arrives addressed to 203.0.113.50:

1. The Firebox recognizes that 203.0.113.50 matches a 1-to-1 NAT Base address.
2. The packet is not automatically passed. The Firebox evaluates active firewall policies to determine whether an explicit policy permits the connection.
3. If no policy matches, the packet is immediately dropped by default threat protection.

Defining Policies for 1-to-1 NAT Hosts

In modern Fireware OS, administrators have flexibility when configuring the To list of firewall policies for 1-to-1 NAT hosts:

• Using the Public IP (NAT Base): Administrators can place the public IP (203.0.113.50) in the policy To field.
• Using the Private IP (Real Base): Administrators can place the internal private IP (10.0.1.50) in the policy To field.

Fireware's policy matching engine evaluates both addresses seamlessly. However, industry best practice in WatchGuard environments is to specify the Real Base (internal private IP) in policies. This ensures that if the organization changes Internet service providers or renumbers its public IP subnet, the underlying firewall policies do not require reconfiguration—only the 1-to-1 NAT mapping table needs updating.

Exam Tip: To permit external access to an internal web server mapped via 1-to-1 NAT, you must create an HTTP or HTTPS policy with From: Any-External and To: 10.0.1.50 (or 203.0.113.50). Never leave the server open to all ports; configure policies strictly for the services the server actually provides.

---

Outbound Traffic Behavior & Override Rules

One of the greatest operational advantages of 1-to-1 NAT is its automated handling of outbound connections.

In a standard Fireware deployment without 1-to-1 NAT:

• Workstations on 10.0.1.0/24 access the Internet.
• The global Dynamic NAT rule (Any-Trusted -> Any-External) translates all their source IPs to the primary External interface IP (203.0.113.2).

When a 1-to-1 NAT rule is defined for host 10.0.1.50 with NAT Base 203.0.113.50:

• Any time 10.0.1.50 initiates an outbound connection to the Internet (e.g., initiating an SMTP session, downloading a software patch, or performing DNS queries), Fireware checks the 1-to-1 NAT table.
• Because 10.0.1.50 is a Real Base member, Fireware rewrites its source IP to 203.0.113.50 rather than the default 203.0.113.2.
• Why this matters for Mail and Cloud Security: External mail servers require that the sending public IP address matches the domain's SPF (Sender Policy Framework) record and PTR (reverse DNS) record. 1-to-1 NAT ensures the mail server always egresses using its own dedicated public IP.

---

Operational Verification & Troubleshooting

1. Verification via Firebox System Manager (FSM)

Open Firebox System Manager and navigate to the Status Report tab. Scroll to the 1-to-1 NAT section to confirm active mappings, interface bindings, and member counts:

--- 1-to-1 NAT Configuration ---
Interface: 0-External
NAT Base: 203.0.113.50
Real Base: 10.0.1.50
Hosts: 4
  203.0.113.50 <-> 10.0.1.50 (Active)
  203.0.113.51 <-> 10.0.1.51 (Active)
  203.0.113.52 <-> 10.0.1.52 (Active)
  203.0.113.53 <-> 10.0.1.53 (Active)

2. Common Misconfigurations & ARP Issues

• Subnet Overlaps: The Real Base subnet must never overlap with the NAT Base subnet or any other configured interface subnet.
• ARP Conflicts on External Interface: In rare cases where an external upstream router does not properly update its ARP cache for secondary public IPs in the 1-to-1 NAT Base, the administrator may need to verify proxy ARP or configure the addresses as secondary IPs on the Firebox External interface to force immediate gratuitous ARP responses.