|
When a client behind FortiGate port2 attempts to communicate with a server behind FortiGate, the packet always uses the IP address of the FortiGate interface port2 as the source IP. This default behavior prevents the server from being able to identify the actual source IP of the traffic.
However, in certain scenarios, it may be necessary to preserve the original IP address.
The FortiGate VM is deployed in either active/passive mode or a standalone configuration.
Both the servers and clients have traffic routed to the FortiGate Network Virtual Appliance (NVA) port2 as the next hop, utilizing Azure User-Defined Routing (UDR).
The firewall policy responsible for inspecting traffic on port2 has the virtual server configured as the destination, with SNAT (Source Network Address Translation) disabled.
Clients communicate with the server by directing their traffic to port2, with the assistance of UDR.
The traffic matches the virtual server, where DNAT (Destination Network Address Translation) translates the virtual server IP to the real server IP.
The packet is then SNATed with the IP of port2 and forwarded to the server.
Upon reaching the server, it will only see the IP address of the FortiGate port2 instead of the original IP address of the client.
This behavior is expected because the traffic is ingressing and egressing on the same interface (port2), creating a hairpin scenario where SNAT is performed by default.
To allow the server to see the original IP address of the packet, the snat-hairpin-traffic feature needs to be disabled. This can be achieved by following the steps below:
config system settings
set snat-hairpin-traffic disable
end
By disabling the snat-hairpin-traffic feature, the server behind the FortiGate will now be able to correctly identify the original IP address of the client when receiving traffic through the virtual server.
|
