Publishing an Internal Portal Without Breaking Hairpin Access
An e-commerce company publishes an internal order portal at 10.10.5.20:443 through a two-member R81.10 cluster. External users resolve portal.example.com to 203.0.113.20, which is statically NATed to 10.10.5.20. Internal users are on 10.10.0.0/16 and use the same public DNS record. The cluster VIP is 203.0.113.1 external and 10.10.0.1 internal. The server's default gateway is the core switch 10.10.0.254, not the firewall. External access works. Internal users time out. A capture on the firewall shows the SYN from 10.10.1.50 to 203.0.113.20 translated to 10.10.5.20, but no SYN-ACK returns through the firewall. The current security rule allows Internal_Net to Web_Server_Public on HTTPS, and the server object has automatic static NAT. The application team refuses split DNS because the public name is embedded in the app.
1. Explain the failure and compare split DNS, hairpin NAT, and an internal reverse proxy as designs.
Read the worked answer
The failure is asymmetric routing, not a missing security rule. Destination NAT rewrites the packet to 10.10.5.20 but leaves the client source at 10.10.1.50. The server replies to 10.10.1.50 through its default gateway, the core switch, so the SYN-ACK never returns through the firewall. The firewall drops the half-open connection and the client times out.
Split DNS is the cleanest design: internal DNS returns 10.10.5.20 and the security rule allows Internal_Net to Web_Server_Internal. It avoids hairpin state and firewall load, but the application team has ruled it out.
Hairpin NAT keeps one name but requires source NAT so the server replies to an address on the firewall. It adds state and can complicate logging and troubleshooting, but it is the appropriate fallback when DNS cannot change.
An internal reverse proxy is a third option: internal clients resolve to the proxy, which connects to the real server. It gives better control and TLS termination but adds infrastructure. If the requirement is only to make the existing name work, hairpin NAT is the smallest change.
2. If hairpin NAT is chosen, specify the NAT and security rule logic and the routing requirement.
Read the worked answer
Create a manual NAT rule above the automatic rule: original source Internal_Net, original destination Web_Server_Public, service HTTPS; translated source Gateway_Internal_IP (10.10.0.1), translated destination Web_Server_Internal (10.10.5.20). The source translation is essential. Without it, the server replies directly to the client and bypasses the firewall.
For the security rule, match on the real server object rather than only the public object, because destination NAT is resolved before rule matching for inbound traffic. Allow Internal_Net to Web_Server_Internal on HTTPS. Keep the existing external rule for Internet users, but do not rely on it for internal clients. Confirm rule order and hit counts after install.
The routing requirement is that 10.10.5.20 must return traffic to 10.10.0.1. Because 10.10.0.1 is in the server's subnet, the server can ARP for it directly; the core switch default gateway does not need to change. If the source NAT address is moved to another subnet, add a route on the server or core switch. Verify with fw monitor that the SYN is translated both ways and that the SYN-ACK re-enters the firewall.
3. How would you verify the fix and prevent the broad rule from allowing unnecessary traffic?
Read the worked answer
Verify from at least two internal subnets and from an external test host. Use fw monitor to confirm the SYN, translated SYN, SYN-ACK, and translated SYN-ACK all traverse the firewall. Check fw tab -t connections for a fully established connection, and confirm the NAT rule and security rule hit counts increment. Test a non-HTTPS service to ensure the new rule does not over-match.
To tighten the rule, replace Internal_Net with a specific group for users who need the portal, or use an identity-aware group if the organization uses identity sources. Keep the destination as the real server object, not Any, and keep the service HTTPS. Add a cleanup rule below the relevant section and review hit counts after a week; remove any broader legacy rule that is no longer needed.
If VPN clients also need access, do not simply add them to the internal group. Confirm whether their traffic is NATed and whether they should use the public or internal name. Document the hairpin design, including the source NAT address, so a future administrator does not remove it as redundant.