Configuring Hairpin NAT (VIP) in Fortigate

[ShadYaka]

Hair-pinning, in a networking context, is the method where a packet travels to an interface, goes out towards the Internet but instead of continuing on, makes a "hair pin turn", and comes back in on the same interface. Initially, it may seem unnecessary or pointless even but it does serve a purpose.

https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/105831
https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/856642/configuring-hair-pinning-on-a-for...

....but it does serve a purpose though and am still struggling to understand the genesis of this NAT technique. 

[rowan_kaag · Accepted solution]

Imagine that you have a Guest WiFi running on port2 and a WAN port with 1.2.3.0/28. Preferably, you'll want to seperate this guest network as much as possible from your office automation network on port1. This means that you don't configure the DHCP Server to forward DNS requests to your internal DNS server but to something like 8.8.8.8.

Now, some guest tries to reach yourcompanywebsite.com that you happen to host yourself in your office automation network. Ergo, the client does a lookup to 8.8.8.8 and gets back the Public IP belonging to yourcompanywebsite.com (e.g. 1.2.3.4)

The client starts an HTTPS session towards 1.2.3.4 and sends the packet to it's default gateway (port2 on the FortiGate). The FortiGate then tries to forward this packet to 1.2.3.4 but.. oh noes, the FortiGate has that IP address in it's public range on WAN1! Now what, does the FortiGate 'forward' this traffic to itself?

Enter the hairpin NAT, which will allow the FortiGate to not 'panic' as it detects that the 'forwarding' is originating from itself, matching the session initiated by the client, and forward the traffic to the internal web server running yourcompanywebsite.com.

One might think: why not just run a recursive DNS server on the FortiGate that will answer queries to yourcompanywebsite.com and resolve it to the internal IP address of the corresponding web server? Well - the most obvious reason is that by doing so, you’ll break the strict segmentation of the guest network and the office automation network. By having it flow through the hairpin, you’ll allow the traffic in a slightly different fashion and yet limit the possibility of human error.