FortiGate Hairpin NAT Configuration: The Definitive Technical Investigation
.
Master FortiGate hairpin NAT configuration with VIP setup, policy requirements, and troubleshooting for seamless internal server access via public IPs.
Understanding the Hairpin NAT Challenge
Hairpin NAT—also termed NAT loopback—represents a persistent configuration puzzle for network administrators managing FortiGate deployments. The scenario unfolds predictably: internal clients attempt to reach a locally hosted server using its public-facing IP address. DNS resolution returns the external address, traffic flows toward the WAN interface, and without precise firewall orchestration, the connection fails silently. This investigation dissects the architectural requirements, policy dependencies, and common failure points that determine whether hairpin NAT succeeds or stalls.
The Core Mechanism: Traffic Flow Deconstructed
Hairpin NAT operates through a deliberate redirection loop. Internal client traffic destined for a public IP enters the FortiGate, undergoes destination NAT translation to the server's private address via a Virtual IP (VIP) object, then routes back through the same or adjacent internal interface. The FortiGate must simultaneously process DNAT for the destination and, in many topologies, SNAT for the source address to ensure symmetric return paths. Failure to configure either transformation correctly results in asymmetric routing or policy denial.
Configuration Scenarios and Implementation Paths
External IP Assigned to FortiGate Interface
When the public IP address belongs directly to a FortiGate interface, configuration follows a relatively straightforward pattern. Administrators create a VIP object mapping the external IP to the internal server address, then establish two distinct firewall policies:
config firewall vip edit "VIP-Server" set extip 203.0.113.10 set mappedip "192.168.10.50" set extintf "wan" set portforward enable set extport 443 set mappedport 443 next end The first policy permits outbound traffic from LAN to WAN with NAT enabled. The second policy, critical for hairpin functionality, accepts traffic from the internal interface to the VIP object as destination, with NAT typically disabled to preserve source addressing for server logging.
External IP in Same Subnet, Not FortiGate-Owned
Complexity increases when the public IP resides within the WAN subnet but lacks direct assignment to the FortiGate. Two implementation strategies emerge:
Option A: VIP Interface Set to "Any" Configuring extintf "any" consolidates policy requirements into a single LAN-to-DMZ rule referencing the VIP. This approach simplifies management but demands careful attention to interface filtering and policy route precedence.
Option B: Explicit Interface Binding Specifying the WAN interface in the VIP definition requires dual policies mirroring the first scenario. However, administrators must ensure the internal subnet appears in the source address field of the WAN-to-DMZ policy; otherwise, hairpin traffic from LAN clients triggers policy denial during the post-DNAT evaluation phase.
Central NAT Considerations
Enabling Central NAT fundamentally alters the configuration paradigm. VIP objects no longer serve as direct policy destinations. Instead, administrators create standard address objects for internal servers and reference these in firewall policies. Corresponding Central SNAT and DNAT mappings handle address translation independently:
config firewall central-snat-map edit 1 set srcintf "lan" set dstintf "dmz" set orig-addr "all" set dstaddr "server-internal" set nat-ippool "vip-pool" next end This decoupling provides granular control but introduces additional verification steps during troubleshooting.
Critical Troubleshooting Vectors
Policy Route Interference
Policy-based routing frequently undermines hairpin NAT implementations. When a policy route directs all LAN-originated traffic toward the WAN gateway, post-DNAT packets targeting internal servers may follow the same path, bypassing the intended DMZ interface. Resolution requires inserting a higher-priority policy route that explicitly excludes the server's mapped IP from internet-bound redirection:
config router policy edit 1 set input-device "lan" set src "192.168.1.0/24" set dst "192.168.10.50/32" set action deny next end Source NAT Requirements for Return Traffic
Hairpin sessions often demand source NAT on the return path to maintain session state consistency. When internal clients access a server via its public IP, the server's reply targets the client's private address. Without SNAT translating the client source to the VIP address, return packets may traverse unexpected routes or trigger asymmetric session handling. Configuring an IP pool and enabling set ippool enable within the relevant policy ensures predictable source address translation.
VIP Interface Binding Pitfalls
A frequently overlooked constraint: VIP objects bound to specific interfaces become invisible to policies referencing different interfaces. Administrators attempting to reference a WAN-bound VIP in a LAN-to-LAN policy encounter silent failures. The solution involves either setting extintf "any" during VIP creation or duplicating VIP objects with interface-specific definitions—a trade-off between flexibility and configuration clarity.
Verification and Diagnostic Procedures
Session table inspection provides immediate validation of hairpin NAT functionality. The command get system session list | grep <vip-external-ip> reveals active translations, displaying both source and destination NAT transformations. A correctly established hairpin session shows the original client IP translated to the VIP address for outbound traffic, with the server's private IP appearing as the destination after DNAT processing.
Flow debugging offers granular visibility into policy evaluation sequences. Enabling debug output with diagnose debug flow traces packet progression through DNAT lookup, routing decisions, and policy matching. Critical indicators include successful VIP resolution (find DNAT: IP-<mapped-address>), correct egress interface selection, and final policy acceptance without fallback to the implicit deny rule.
FAQ: Hairpin NAT Configuration Essentials
Q: Why does hairpin NAT work for external clients but fail for internal users?
A: Internal traffic typically bypasses the WAN interface where VIP-based DNAT rules activate. Without a dedicated policy accepting LAN-originated traffic to the VIP object as destination, the FortiGate applies default routing, which may direct packets externally or drop them due to missing policy matches.
Q: Can hairpin NAT function without enabling source NAT on internal policies?
A: Yes, but only when the server's return path recognizes the client's private address and routing symmetry exists. Many deployments require SNAT to ensure the server replies through the FortiGate, maintaining session state and enabling security profile inspection on return traffic.
Q: How does Central NAT change hairpin configuration compared to policy-based NAT?
A: Central NAT separates address translation from firewall policy evaluation. VIP objects no longer serve as policy destinations; instead, standard address objects reference internal servers while Central SNAT/DNAT mappings handle translations. This provides flexibility but requires coordinating three configuration elements instead of two.
Q: What diagnostic command confirms whether VIP resolution occurs during hairpin attempts?
A: The flow debug output displays find DNAT: IP-<mapped-address> when VIP resolution succeeds. Absence of this message indicates the VIP object is either misconfigured, bound to an incompatible interface, or excluded by policy route precedence.
Q: Does hairpin NAT require the external IP to respond to ARP requests on the local subnet?
A: When the public IP lacks direct assignment to the FortiGate, ARP resolution depends on upstream router configuration. The router must either proxy-ARP for the VIP address or maintain a static ARP entry mapping the VIP to the FortiGate's MAC address. Without this, layer-2 delivery fails before firewall processing begins.