A utility configures a VIP so an internal back-office subnet can reach a substation console using the substation's public-facing address, even though both networks sit behind the same FortiGate, a hairpin scenario where the traffic enters and exits through interfaces the firewall must handle carefully. The VIP and an appropriate inbound policy are both configured, but internal back-office hosts still cannot reach the console this way, while genuinely external vendor traffic to the same VIP works correctly. What is a likely missing piece specific to this internal hairpin case?
Select an answer to reveal the explanation.
Short Explanation
Hairpin traffic bounces in and back out the same interface, and without a little source-NAT trick, the console's reply naturally heads straight back to the real internal host, skipping the firewall and the whole VIP illusion entirely. Adding NAT to that policy keeps the return trip flowing back through the firewall as expected.
Full Explanation
In a hairpin NAT scenario, internal traffic enters and exits the same interface to reach a server via its public-facing VIP address. Because the console sits on a routable internal subnet, if it sees the back-office host's real internal address as the session source, its reply routes directly back to that host on the local network instead of through the FortiGate, breaking the VIP's illusion. Genuinely external traffic doesn't hit this, since an external reply has no local path and must transit the firewall regardless. Applying source NAT on the policy handling internal-to-VIP traffic, commonly to the FortiGate's own internal interface address, ensures the console's replies address back to the firewall itself, keeping the round trip flowing through it as intended. VIP objects aren't duplicated per source population; one VIP is designed to serve both external and internal traffic when configured correctly. Central NAT is an architectural choice about where NAT rules live, not a system-wide constraint against hairpin VIP traffic, that's a routing/return-path concern, not a NAT-model conflict. Grouping the console's address with the VIP in an address group has no bearing on hairpin behavior; that isn't a recognized pattern for this problem. Confirm the fix by checking the session table for the internal-to-console session and verifying both translations are present.