4.2 Static NAT (Server NAT & Port Forwarding)

4.2 Static NAT (Server NAT & Port Forwarding)

Quick Answer: In WatchGuard Fireware, Static NAT (SNAT) is Destination NAT (DNAT) used to publish internal servers (web, mail, SFTP) to the external world. Creating an SNAT action defines the translation from a public IP to an internal private IP, but does not permit traffic on its own. An administrator must explicitly reference the SNAT action in the To list of a firewall policy (e.g., HTTPS-proxy or SMTP). SNAT supports port translation (redirection) and Server Load Balancing (SLB) with Round-Robin or Weighted distribution and Source IP Sticky persistence.

Architectural Role of Static NAT (Destination NAT)

While Dynamic NAT translates the source IP of outbound connections initiated by internal clients, Static NAT (SNAT) performs the opposite operation for inbound connections initiated by external clients. In standard networking terminology, this is known as Destination NAT (DNAT), Server NAT, or Port Forwarding.

When external clients connect to an organization's public services—such as an e-commerce web portal, an on-premises Microsoft Exchange server, or a customer SFTP repository—they send packets to a public IP address owned by or routed to the Firebox External interface. Because the actual servers reside in a protected internal zone (such as an Optional DMZ or Trusted subnet) with private RFC 1918 addresses, the Firebox must rewrite the destination IP header before routing the packet to the server.

[External Client] ---> [Firebox External (203.0.113.25:443)]
                              |
                     (DNAT Translation)
                              |
                      [Internal Web Server (10.0.2.50:443)]

---

Decoupled Architecture: SNAT Actions vs. Firewall Policies

A central design philosophy of WatchGuard Fireware is the strict separation between network address translation and access control. In some basic consumer routers, setting up a port forward automatically punches a hole in the firewall. In Fireware OS, this never occurs.

An SNAT configuration in Fireware consists of two distinct components:

1. The SNAT Action: A reusable translation definition created under Network > SNAT (in Fireware Web UI) or Network > Configuration > SNAT (in Policy Manager). The action specifies the public External IP, the target internal IP, optional port redirection, and load balancing parameters.
2. The Firewall Policy: A packet filter or proxy policy (e.g., HTTP, HTTPS-proxy, SMTP) that governs which traffic is permitted. The SNAT action is selected as the destination in the policy's To list.

Exam Tip: If an administrator creates an SNAT action but fails to add it to the To list of an active firewall policy, all inbound traffic to that public IP and port will be dropped by the Firebox's default unhandled packet rule. Both the SNAT action and the matching firewall policy are strictly required.

Benefits of Decoupled Architecture

• Granular Security Controls: Different policies can reference the same SNAT action while enforcing distinct inspection engines. For example, external HTTP traffic can be subjected to an HTTP-proxy with WebBlocker and Gateway AntiVirus, while SSH traffic to the same server can use a restrictive packet filter.
• Source Filtering: An SNAT action merely defines where packets go; the firewall policy defines who may send them. Administrators can restrict the policy's From field to specific partner IP addresses or Geolocation regions rather than allowing Any-External.

---

Configuring SNAT Actions in Fireware

When creating an SNAT action in Fireware Web UI or Policy Manager, the administrator defines the following core elements:

1. SNAT Action Name: A descriptive label (e.g., SNAT_Web_Cluster, SNAT_Mail_Server).
2. SNAT Members: One or more mapping entries defining:
   • External IP Address: Must be an IP address assigned to an External interface (either the primary interface IP or a secondary IP configured on the interface).
   • Internal IP Address: The private IPv4 address of the target internal host (e.g., 10.0.2.50).
   • Port Translation (Optional): Specifies an internal destination port if port redirection is required.

+--------------------------------------------------------------------------------+
|                            SNAT Action Configuration                           |
+-------------------+--------------------+--------------------+------------------+
| External IP       | Internal IP        | External Port      | Internal Port    |
+-------------------+--------------------+--------------------+------------------+
| 203.0.113.25      | 10.0.2.50          | 443 (inherited)    | 443 (inherited)  |
| 203.0.113.25      | 10.0.2.51          | 8443 (policy port) | 443 (redirected) |
+-------------------+--------------------+--------------------+------------------+

---

Port Translation (Port Redirection)

In addition to rewriting destination IP addresses, Fireware SNAT can rewrite destination transport port numbers. This capability, known as Port Translation or Port Redirection, enables organizations to expose internal services running on non-standard ports, or multiplex multiple internal services behind a single public IP address.

Common Port Redirection Scenarios

1. Security Through Obfuscation / Management Access

An internal web management console listens on standard HTTPS port 443. To protect it from automated Internet scanning, the administrator configures an SNAT action with port translation:

• Policy Destination Port: 8443
• SNAT Internal Destination Port: 443
• Flow: External traffic destined for 203.0.113.25:8443 is translated by the Firebox to 10.0.2.80:443.

2. Multiple Internal Servers Sharing One Public IP

An organization owns only one public IP address (203.0.113.10) but hosts two distinct internal SSH servers (10.0.1.20 and 10.0.1.30). The administrator creates two separate SNAT actions and policies:

• Policy 1 (SSH-Server1): Port 2201 -> SNAT redirects to 10.0.1.20:22
• Policy 2 (SSH-Server2): Port 2202 -> SNAT redirects to 10.0.1.30:22

External users connect to 203.0.113.10:2201 or 203.0.113.10:2202, and the Firebox directs the traffic to the appropriate internal server on standard port 22.

---

Server Load Balancing (SLB) with SNAT

Fireware OS includes native Layer 4 Server Load Balancing (SLB) capabilities embedded directly within SNAT actions. Instead of mapping an External IP to a single internal server, the administrator adds multiple internal server IP addresses to the SNAT action member list.

Distribution Algorithms

When multiple backend servers are assigned to an SNAT action, Fireware provides two primary traffic distribution methods:

1. Round-Robin: Incoming connection requests are distributed sequentially and equally among all healthy backend servers in the pool ($Server_1 \rightarrow Server_2 \rightarrow Server_3 \rightarrow Server_1$). Ideal when all backend servers possess identical computing capacity.
2. Weighted Round-Robin (Weighted Distribution): Each server is assigned an integer weight (from 1 to 255). The Firebox distributes connections proportionally based on the assigned weights.

Mathematical Example of Weighted Distribution:

Consider an SNAT pool with three backend web servers:

• Server A: Weight 3
• Server B: Weight 2
• Server C: Weight 1
• Total Weight Sum: $3 + 2 + 1 = 6$

Out of every 6 incoming client connections:

• Server A receives $\frac{3}{6} = 50%$ of sessions
• Server B receives $\frac{2}{6} = 33.3%$ of sessions
• Server C receives $\frac{1}{6} = 16.7%$ of sessions

This mechanism allows administrators to seamlessly mix legacy hardware with modern, high-performance servers without overloading weaker systems.

Sticky Connections (Source IP Persistence)

Many web applications—such as e-commerce shopping carts, banking portals, and stateful CRM platforms—store session data locally in web server RAM. If a user's first HTTP request hits Server A and their checkout request hits Server B, the user's session may be corrupted or terminated.

To prevent this, Fireware provides the Sticky Connections setting within the SNAT action:

• When Sticky Connections is enabled, Fireware records the external client's source IP address upon initial connection.
• For all subsequent connections from that same source IP within a configurable expiration window (default is typically 10 to 60 minutes), the Firebox guarantees forwarding to the exact same internal backend server.
• Once the sticky timer expires without active traffic, new connections are once again subject to the weighted load balancing algorithm.

---

Security Inspection on Inbound SNAT Traffic

Because the SNAT action is evaluated within the context of a firewall policy, all Fireware security subscription services remain fully operational:

• Proxy Policies vs. Packet Filters: When publishing critical services, administrators should deploy proxy policies (such as HTTPS-proxy or SMTP-proxy) rather than simple packet filters. Proxies terminate the connection, validate protocol RFC compliance, and prevent buffer overflow exploits.
• Subscription Services: Intrusion Prevention Service (IPS), Gateway AntiVirus (GAV), and APT Blocker inspect packet payloads after destination translation is calculated but before packets are transmitted to the internal server.

---

Operational Verification & Troubleshooting

1. Traffic Monitor Log Verification

In Firebox System Manager (FSM) Traffic Monitor, verify successful SNAT execution by checking the destination address rewrite:

2026-09-21 14:35:22 Allow 198.51.100.75 203.0.113.25 https/tcp 49812 443 0-External 1-Trusted HTTPS-proxy: Allowed (SNAT: 203.0.113.25 -> 10.0.2.50)

The log demonstrates that external host 198.51.100.75 connected to public IP 203.0.113.25:443, and Fireware successfully applied the SNAT action, rewriting the destination to 10.0.2.50:443.

2. Common Deployment Pitfalls

• Default Gateway on Internal Server: The internal server must use the Firebox interface IP as its default gateway (or have a return route pointing back to the Firebox). If the server routes return traffic out an alternate gateway, the connection will break due to asymmetric routing.
• Secondary IP Not Configured: If the SNAT External IP is not the primary interface IP, it must be explicitly configured as a Secondary IP on that External interface; otherwise, the Firebox will not respond to ARP requests for that address on the WAN link.