Dropped traffic when accessing WAN IP from LAN with NAT Reflection disabled

Root Cause: Hairpin NAT Bypass

When NAT Reflection is disabled, packets originating from LAN hosts destined for the firewall's own WAN IP address bypass the NAT engine entirely. The firewall routes these packets directly back to the LAN without performing the necessary address translation, causing the return traffic to be dropped because it appears to come from an unexpected source. This is the expected behavior on most firewall platforms when hairpinning is not explicitly enabled.

Solution: Enable Pure NAT for Standard Services

Pure NAT creates a lightweight hairpin NAT path that rewrites the source address of LAN-to-WAN traffic to the firewall's WAN IP. This allows return packets to flow correctly without application-level inspection. For HTTP, SSH, and similar protocols that do not embed IP addresses in their payloads, Pure NAT restores connectivity with minimal CPU overhead—typically 10-30% less than Proxy NAT.

Configuration Steps

1. Access the firewall's NAT settings
2. Enable Pure NAT (sometimes labeled "NAT Reflection" or "Pure NAT")
3. Verify the WAN IP address is included in the NAT policy
4. Test connectivity from a LAN host to the WAN IP on the target service port

Protocol Compatibility: Pure NAT vs Proxy NAT

Pure NAT works correctly for protocols that transmit data directly (HTTP, SSH, TCP, UDP) because it only modifies packet headers. However, protocols that embed IP addresses in their payload—such as FTP active mode or SIP—may fail because the embedded addresses remain unchanged while the packet headers are rewritten.

Proxy NAT terminates connections at the firewall and creates new connections, handling embedded IP protocols correctly. This comes with significant CPU overhead due to connection state tracking and packet buffering, which may impact throughput on modest hardware under high connection rates.

Alternative: Split-DNS Workaround

Split-DNS provides the lowest overhead solution by configuring your internal DNS server to resolve the public IP address to a LAN-accessible address. This eliminates hairpinning entirely without any NAT processing. Implementation requires:

• Creating an internal DNS zone for your domain
• Configuring the public IP to resolve to your firewall's LAN IP
• Ensuring clients use the internal DNS server

Verification Checklist

• Monitor CPU utilization during connection establishment with Pure NAT enabled
• Check firewall logs for dropped packets when accessing WAN IP from LAN
• Verify FTP active mode and SIP connections work correctly (if applicable)

Recommendation

For most environments with modest hardware running standard services like HTTP and SSH, enable Pure NAT first. If you require protocols that embed IP addresses, evaluate whether Proxy NAT's CPU overhead is acceptable for your connection rate, or implement split-DNS as a lower-overhead alternative.