Destination NAT Configuration on FortiGate: A Technical Investigation into VIP Implementation and Policy Architecture
.
Master FortiGate Destination NAT configuration: VIP setup, firewall policy rules, port forwarding, and troubleshooting for secure inbound traffic management.
The Architecture of Inbound Traffic Translation
Destination Network Address Translation (DNAT) on FortiGate firewalls operates through a distinct two-component framework: Virtual IP objects handle address translation, while firewall policies govern traffic permission. This separation of concerns—often misunderstood by administrators migrating from other platforms—forms the foundation of reliable port forwarding implementations.
Unlike monolithic NAT rules found in legacy systems, FortiGate's approach requires explicit coordination between object definition and policy enforcement. The Virtual IP (VIP) performs the mechanical translation of destination addresses; the firewall policy determines whether translated traffic reaches its intended internal resource.
Constructing the Virtual IP Object
Interface and Address Mapping
The VIP configuration begins under Policy & Objects > Virtual IPs. Administrators must specify the external interface receiving inbound connections, then define the translation parameters:
- External IP address/range: The public-facing address clients will target
- Mapped IP address/range: The internal server's private address
- Port forwarding toggle: Enables protocol-specific translation rather than one-to-one IP mapping
When port forwarding activates, additional fields appear: protocol selection (TCP/UDP), external service port, and mapped internal port. This granularity permits scenarios such as redirecting external port 8080 to internal port 80, or exposing multiple internal services through distinct ports on a single public IP.
Static NAT versus Port Forwarding
Two operational modes exist within VIP configuration. Static NAT establishes a complete one-to-one IP mapping, forwarding all protocols and ports. Port forwarding restricts translation to specified protocols and port numbers, offering tighter security boundaries. Most production deployments favor port forwarding, as it limits exposure to only required services.
Policy Configuration: The Often-Misunderstood Second Step
Destination Reference Requirements
Creating a VIP alone accomplishes nothing without an accompanying firewall policy. The policy's destination field must reference the VIP object—not the internal server's IP address. This distinction represents a frequent configuration error: administrators correctly define the VIP, then incorrectly point the policy to the backend server, causing the FortiGate to bypass DNAT processing entirely.
The NAT Toggle Paradox
Within the firewall policy interface, a NAT checkbox appears. For DNAT scenarios, this setting controls Source NAT, not Destination NAT. When inbound traffic requires the internal server to see the original client IP address, administrators must disable this toggle. Conversely, when the server should perceive traffic as originating from the FortiGate's internal interface, enabling NAT performs the necessary source address translation.
This dual-NAT scenario—simultaneous DNAT via VIP and SNAT via policy—proves essential in asymmetric routing environments or when internal servers lack return path knowledge to external networks.
Advanced Implementation Patterns
Combining Source and Destination Translation
Complex deployments sometimes require translating both source and destination addresses within the same traffic flow. FortiGate accommodates this through two methods:
In traditional NAT mode, the VIP handles destination translation while the policy's NAT setting manages source translation. In Central NAT mode, administrators configure VIP objects separately, then create distinct Central SNAT policies referencing the post-DNAT internal address as the destination match criterion.
Handling Identical External and Mapped Addresses
FortiGate prohibits static VIP configurations where external and mapped IP addresses match—a restriction that surfaces when attempting port redirection on the same interface. The workaround employs server load balancing VIP type rather than static NAT. This configuration accepts traffic on the interface IP, then forwards to the same IP on a different port, effectively achieving port redirection without violating the extip/mappedip uniqueness requirement.
Verification and Diagnostic Methodology
Session Table Inspection
Post-configuration validation begins with the session table. The command diagnose sys session list reveals active connections, displaying both original and translated addresses. A properly functioning DNAT rule shows the external destination IP in the session's pre-NAT fields and the internal server IP in the post-NAT fields.
Packet Capture Analysis
For deeper investigation, diagnose sniffer packet provides wire-level visibility. Filtering on the external port or internal server IP allows administrators to observe the translation moment: inbound packets display the public destination, while outbound packets toward the internal network show the translated private address. Source address changes, when SNAT is enabled, appear simultaneously.
Log Correlation
Forward traffic logs, when enabled on the policy, record both the original destination (VIP) and the translated destination (internal server). Discrepancies between expected and logged addresses often indicate misconfigured VIP port mappings or protocol mismatches.
Common Configuration Failures and Resolutions
Routing Asymmetry
DNAT succeeds only when return traffic traverses the FortiGate. Internal servers must route responses through the firewall, either via default gateway configuration or specific static routes. Asymmetric routing—where replies exit through a different path—breaks stateful inspection, causing the FortiGate to drop legitimate return traffic.
Proxy ARP Considerations
When the VIP's external IP does not belong to the FortiGate's interface subnet, Proxy ARP ensures the firewall responds to ARP requests for that address. Modern FortiOS versions handle this automatically in most scenarios, but manual verification remains prudent in complex Layer 2 environments.
Service-Specific Protocol Handling
Certain protocols embed IP addresses within application payloads—FTP, SIP, and H.323 among them. These require corresponding ALG (Application Layer Gateway) settings to rewrite internal addresses within the data stream. Without ALG activation, connection establishment may succeed while data transfer fails.
Frequently Asked Questions
Why does my VIP configuration not permit traffic despite correct policy settings? Verify that the firewall policy references the VIP object as the destination, not the internal server IP. Additionally, confirm the policy's incoming interface matches the VIP's configured external interface, and ensure no higher-priority deny policies intercept the traffic first.
Can I forward multiple external ports to different internal servers using a single public IP? Yes. Create separate VIP objects for each port-to-server mapping, then reference each VIP in its corresponding firewall policy. The FortiGate evaluates VIP matches before policy processing, enabling distinct translations based on destination port.
How do I preserve the original client IP address when forwarding traffic? Disable the NAT toggle within the firewall policy. This prevents source address translation, allowing the internal server to see the genuine client IP. Ensure the server's return route points to the FortiGate, or asymmetric routing will disrupt the connection.
What diagnostic commands reveal DNAT processing status? Use diagnose firewall iprope list to inspect policy matching, diagnose sys session list to view active translated sessions, and diagnose debug flow to trace packet processing decisions in real time. These tools isolate whether failures occur during VIP matching, policy evaluation, or routing.
Does FortiGate support hairpin NAT for internal clients accessing VIP addresses? Yes, when hairpin NAT is enabled in system settings. This permits internal clients to reach internal servers via the public VIP address, with the FortiGate translating both source and destination addresses appropriately. Without this setting, internal clients attempting VIP access may experience routing loops or connection failures.