Publishing an Internal Web App to Staff Without Split DNS

Order of operations on the FortiGate

1. Route lookup for 10.10.10.25 -> 203.0.113.10 matches the default route, so the packet is scheduled out wan1.
2. Policy lookup is then keyed on the interface the packet actually arrived on: port2 -> wan1, source 10.10.10.0/24, destination 203.0.113.10, service HTTPS.
3. The working policy is wan1 -> port3, so it can never match. A different incoming interface means a different policy.
4. The VIP object has extintf wan1. VIP translation is only evaluated for traffic ingressing wan1, so the destination is never rewritten to 10.10.20.50 and the packet never touches port3.
5. The generic outbound policy at position 1 matches instead, source-NATs the session to 203.0.113.10 and sends it toward the ISP, which drops a packet addressed to the FortiGate arriving from an unexpected direction.

So the session entry the admin sees is real, but it is a misdirected internet session, not a hairpin session. The key judgement is that the FortiGate never 'knows' the user meant the internal server: the FQDN resolved to a public IP, and the public IP is the FortiGate's own wan1 address.

Add a policy that matches the traffic where it really arrives, above the generic internet policy:

config firewall policy
    edit 0
        set name "hairpin-shop"
        set srcintf "port2"
        set dstintf "wan1"
        set srcaddr "LAN-10.10.10.0"
        set dstaddr "shop-vip"
        set action accept
        set schedule "always"
        set service "HTTPS"
        set nat enable
    next
end

Why each line matters

• dstaddr must be the VIP object, not a plain address object; the VIP is what performs 203.0.113.10:443 -> 10.10.20.50:8443.
• set nat enable (SNAT to the wan1 interface address) is the step most often forgotten. Without it the server replies directly to 10.10.10.25 with source 203.0.113.10; the client discards it as a reply to a connection it never opened and the handshake never completes. With SNAT the reply is 203.0.113.10 -> 10.10.10.25, which routes back to the FortiGate and matches the existing session.
• Order matters: the generic port2 -> wan1 policy at position 1 must move below this one.
• Keep the VIP's extintf on wan1; the internal policy can still reference it.

If the architecture board later allows split DNS, an internal zone returning 10.10.20.50 is cheaper on the FortiGate, but it does not fix the callback-URL requirement unless the name is identical.

Clear stale state first, then trace:

diagnose sys session filter dst 203.0.113.10
diagnose sys session clear
diagnose debug flow filter addr 10.10.10.25
diagnose debug flow show iprope enable
diagnose debug flow trace start 15
diagnose debug enable

Look for iprope found with the hairpin policy ID, then the NAT lines showing the source rewritten to 203.0.113.10 and egress on wan1. If the trace shows the generic policy ID, ordering is still wrong. If the trace is clean but the browser hangs, check the server's default gateway and any host firewall or reverse proxy that only trusts 203.0.113.0/29.

Two interface traps

• If wan1 is a member of an SD-WAN zone, the VIP's extintf must reference the zone, not the physical port; a VIP bound to a member port in a zone will not match.
• If the staff network is a VLAN sub-interface, srcintf must be the VLAN interface name (for example port2.10), not the parent port2. The policy lookup fails closed and the packet falls through to the next matching policy.