Troubleshooting Tip: VIP DNAT internal server not responding

[mauromarme]

Description	This article describes how to resolve cases where traffic is correctly forwarded by the FortiGate but encounters issues such as non-functional traffic or no response from the destination host to the source host.
Scope	FortiGate v7.2.x.
Solution	First, use a 'diag debug flow' or a sniffer to ensure that the traffic is being properly forwarded by the FortiGate. This is the command for the sniffer: di sni pack <interface> 'host x.x.x.x' 4 0 l. The interface should be the egress interface for this traffic. This will show that the packet is being forwarded successfully. Here would be the commands for the debug flow, replacing x.x.x.x and y.y.y.y with the source and destination IPs:  di de res di de flow filter addr x.x.x.x y.y.y.y and di de flow trace start 1000 di de en Here is an example of a debug flow on a successful packet: If the traffic gets into the Firewall and is being properly sent to the destination host on the mapped port but the connection issues persist, check on the network segment behind the FortiGate. Determine the destination host's device type and confirm its operating system along with OS distributions. Security configurations may differ based on the operating system. For instance: Windows devices typically have Windows Defender Firewall enabled by default, which may obstruct inbound connections. Ensure this setting is reviewed, and check for any Firewall rules on the device that could potentially block traffic from outside the FortiGate. Windows Devices (excluding servers) may be part of a domain, and domain administrators could have implemented specific policies, including 'Traffic Inbound Rules'. If this scenario applies, verify the incoming traffic using Wireshark to ascertain whether it reaches the end device or not. Note that some devices may have more than one interface: make sure to capture traffic on the correct port. In some cases, the devices may have more than one NIC with IPs on different subnets. For Example: In this scenario, two NICs are in place: NIC1 with IP 10.100.100.99 and NIC2 with IP 192.168.1.194. When traffic originates from the internet and follows this path: Internet -----> FortiGate (DNAT) -------> Internal Host (Destination Host). No issues arise because the source IP from the internet does not fall within any of the subnets configured on either of the NICs on the Destination Host. However, complications arise when traffic flows from the internal network, and the destination IP is a public IP routable to the FortiGate via a VIP (with hairpinning): Internal Host (Source) ------------> FortiGate -------- > Internet ---------- > FortiGate (DNAT) ------> Internal Host (Destination Host). As the traffic remains within the FortiGate and does not exit due to the hairpinning, the source IP would be an internal IP rather than the public IP. This discrepancy occurs because the traffic loopback within the FortiGate does not allow the source IP to appear as the public IP: instead, it retains the internal IP address. So, following the IP information on the previous screenshot: NIC1: IP 10.100.100.99. NIC2: IP 192.168.1.194. If traffic originates from the 10.100.100.0/24 network and the VIP is set to redirect external traffic to 192.168.1.194, it will reach the destination host on NIC2 (192.168.1.194). However, the server's routing table may pose an issue as it indicates that the 10.100.100.0/24 subnet is accessible via NIC1. Consequently, the server might anticipate traffic from that subnet to arrive through NIC1 rather than NIC2. In such cases, Windows Defender could potentially block inbound traffic. It may be possible to work around this issue by performing SNAT (Source Network Address Translation) within the same policy where DNAT is configured. By source NATing the traffic, it will hide the real IP of the traffic to the internal device. If there was any routing issue downstream, this is a valid workaround. This can be done by enabling NAT on the policy, as seen here: