FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
Article Id 286071
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.
If the traffic gets into the Firewall and its being properly sent to the destination host on the mapped port but the connection issues persist, check on the network segment behind the FortiGate.


  1. 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.

  1. In some cases, the devices may have more than one NIC with IPs on different subnets.

    For Example:

Screenshot 2023-11-27 193545.png


In this scenario, two NICs are in place: NIC1 with IP and NIC2 with IP 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 doesn't 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:


If traffic originates from the network and the VIP is set to redirect external traffic to, it will reach the destination host on NIC2 ( However, the server's routing table may pose an issue as it indicates that the 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.

To resolve this issue, rectify it by performing SNAT (Source Network Address Translation) within the same policy where DNAT is configured. By source NATing the traffic to any available IP within the segment, it is possible to ensure that the traffic's source address aligns correctly with NIC2, resolving potential routing and Windows Defender blocking issues.