Hairpin access to a published server after enabling central NAT

This is a hairpin (loopback) NAT failure caused by the source address never being translated.

Flow

1. Client 10.20.1.55 sends a SYN to 203.0.113.20. Policy 8 matches and the VIP destination-NATs it to 10.10.5.20:443.
2. Because central NAT is enabled, per-policy NAT on policy 8 is ignored. No central SNAT rule matches destination 203.0.113.20/hr-public, so the packet reaches the server with source 10.20.1.55. The capture confirms this.
3. The server replies to 10.20.1.55. Since that address is on the same internal network, the reply either goes directly at layer 2 or through the FortiGate as a brand-new flow with a different 5-tuple than the original client-to-VIP session.
4. The client sent its SYN to 203.0.113.20 but receives a SYN-ACK sourced from 10.10.5.20. It discards the packet and retransmits until it times out. The FortiGate never sees a matching return packet for the NAT session.

External users work because their source address is routable on the internet, so the server's reply naturally returns through the FortiGate and matches the existing session.

Fix: add a scoped central SNAT rule

• Source: 10.20.0.0/16 (or the specific user subnet).
• Destination: the hr-public VIP object (203.0.113.20), not 'all'.
• Translated address: 203.0.113.20, i.e., the VIP's external address.
• Place this rule above the existing 10.20.0.0/16 to 203.0.113.10 internet rule, because central SNAT maps are evaluated in order and the general rule would otherwise match first.

With source translated to 203.0.113.20, the server's reply goes to 203.0.113.20, which is local to the FortiGate. It matches the existing session, gets reverse-NATed, and returns to 10.20.1.55 with the expected source.

Why policy 8's NAT setting did nothing When central NAT is enabled, FortiOS uses the central SNAT table and ignores the per-policy NAT checkbox. The setting is still visible in the configuration, which is why it looks correct, but it is not evaluated. This is also why the previous per-policy design worked before the change: policy 8 used to translate the source to the egress interface address, and the server's reply came back to a local address and matched the session.

Recommendation: keep central NAT and add the scoped SNAT rule.

• Central NAT gives one deterministic place to prove the auditor's requirement that all outbound traffic uses 203.0.113.10. It also removes the risk of someone adding a policy later with NAT disabled or NATing to the wrong address.
• The hairpin problem is a missing rule, not a flaw in central NAT. Adding one rule is a smaller, reversible change than reworking every policy.

If central NAT were disabled anyway, verify:

1. Every internet-bound policy has NAT enabled and translates to 203.0.113.10, including any policy that is currently inheriting translation only from a central rule.
2. The two central SNAT rules do not encode other requirements, such as a separate public IP for a partner-facing subnet; those must be recreated per policy.
3. Policy 8's per-policy NAT once again translates internal hairpin sources to the egress interface address, so the server's replies come back to a local address.
4. Re-test external access, hairpin access, and the auditor's source-IP check, then keep a configuration diff in change control.

Also confirm with the auditor's actual wording: if it says 'all internet-bound traffic must use 203.0.113.10', per-policy NAT can satisfy it, but the evidence burden is higher because it must be checked policy by policy.