3.4 Automatic vs Manual NAT and Proxy ARP

Two Authoring Paths to the Same Rule Base

Both Automatic and Manual NAT produce rows in the NAT Rule Base that the gateway installs. They differ in who writes the rule, how much ancillary configuration comes with it, and how much control the administrator has over translation specifics. CCSA exam questions frequently test the trade-offs, so it is worth mapping them out explicitly.

Automatic NAT

Automatic NAT is configured on the object itself. In SmartConsole, open the properties of a host, network, or range object, go to the NAT tab, and check Add automatic address translation rules. You then choose:

• Translation method: Hide or Static.
• For Hide: Hide behind the gateway (use the gateway's external IP) or Hide behind IP (specify a different IP).
• For Static: a specific translated IP address.
• Position: whether the auto-generated rules appear above or below the manually authored Manual NAT rules in the NAT Rule Base.

At policy install, the Security Management Server generates the corresponding NAT rules and inserts them at the chosen position. The administrator does not see or edit the rows directly — they are derived from the object's NAT settings and shown in the NAT Rule Base with a small icon indicating they are automatic.

Advantages of Automatic NAT:

• Proxy ARP is handled for Static NAT. When you enable Automatic Static NAT, the gateway automatically answers ARP for the translated public IP on the correct interface. You do not need to add ARP entries on Gaia.
• Anti-spoofing and topology consistency are handled. The management server knows which interface the translated IP is reachable on and keeps anti-spoofing aligned.
• Object reuse. If the same internal network is referenced in many places, the NAT configuration travels with the object — one change, one install.
• Less error-prone. There is no risk of forgetting proxy ARP or misplacing a rule.

Disadvantages:

• Less granular. You cannot translate the service port (port forwarding), and you cannot have different translations depending on the original destination.
• One rule per object. Complex scenarios (translate differently based on source) are awkward.

Manual NAT

Manual NAT is authored directly in the NAT Rule Base. You add a row, fill in Original Source, Original Destination, Original Service, Translated Source, Translated Destination, and Translated Service, choose Install On, and install the policy.

Advantages of Manual NAT:

• Full control over every column, including service translation (port forwarding). You can publish a web server on a non-standard external port and translate it to 443 internally.
• Per-destination translation. The same internal host can be translated differently depending on where traffic originates.
• Rule position is explicit. You decide exactly where the rule sits in the top-down evaluation.

Disadvantages:

• Proxy ARP must be added manually for Static NAT. This is the classic CCSA gotcha. If you publish 203.0.113.50 to 10.1.1.100 with a Manual Static NAT rule and forget the ARP entry, external traffic never reaches the gateway. Add it with clish:

  add arp proxy ipv4-address 203.0.113.50 interface eth1 mac-address auto
  save config
  

  or via the Gaia Portal under Network Management > ARP > Proxy ARP.

• Anti-spoofing must be checked. Manual translation can confuse topology assumptions; verify the internal interface's topology still treats 10.1.1.0/24 as internal and the external interface treats 203.0.113.0/28 as external.

• More bookkeeping. Each published server requires both a rule and an ARP entry; deleting the rule without removing the ARP entry leaves the gateway answering for an IP that no longer translates anywhere.

Rule Placement in the NAT Rule Base

The NAT Rule Base is evaluated top-down, first match wins — exactly like Access Control ordered layers. The first rule whose Original Source, Original Destination, and Original Service match a packet is the one that performs the translation; rules below it are skipped for that packet.

This means rule order is decision-critical:

• A broader rule on top can "shadow" a more specific rule below it. If you put a generic Hide-NAT rule for 10.0.0.0/8 above a specific Static-NAT rule for 10.1.1.100, the static rule never matches.
• Best practice is to place Static NAT rules above Hide NAT rules, because Static NAT is more specific (one host) and Hide NAT is broader (a whole network).
• Use the Hit Count column (introduced into the NAT Rule Base in R82 along with the unified policy model) to identify rules that never match — a sign they are shadowed or obsolete.

When you mix Automatic and Manual NAT, the object's NAT tab lets you choose whether the auto-generated rule appears above or below your Manual rules. The common practice is to keep Manual rules on top (so explicit, hand-tuned translations take precedence) and let Automatic rules fill in below for the bulk of client Hide-NAT traffic.

Proxy ARP Summary Table

A Decision Procedure for the Exam

When a CCSA scenario asks you to choose a method, walk through this:

1. Is the host a server accepting inbound connections? If yes, you need Static NAT. If no, use Hide NAT.
2. Do you need service/port translation or per-destination logic? If yes, Manual NAT. If no, Automatic NAT is sufficient and safer.
3. If Manual Static NAT is chosen, did you add proxy ARP for the public IP on the external interface? If not, the rule will not work. This is the single most common NAT configuration error on the exam and in the field.
4. Where does the rule sit in the NAT Rule Base? Verify it is not shadowed by a broader rule above. Static above Hide; specific above general.

NAT rule position, Automatic vs Manual authoring, and the proxy ARP requirement for Manual Static NAT are the three load-bearing facts for CCSA NAT questions. Master them and the rest of the chapter falls into place.