Technical Tip: FortiGate receives connection requests for a listening service but fails to generate a response

[Umer221]

Description	This article explains why FortiGate, when receiving connection requests for any locally listening service (e.g., SSL-VPN, IPsec VPN, HTTPS GUI, SSH, SNMP), may fail to generate a response, even though the service daemon is running and all the configuration is correctly configured. The issue can occur for both SSL-VPN and IPsec VPN traffic, but the principles discussed here apply broadly to all services that FortiGate listens to.
Scope	FortiGate.
Solution	When FortiGate receives incoming traffic for any listening service (such as SSL-VPN, IPsec VPN, HTTPS GUI, or SSH) but does not respond, the following checks should be performed. Verify FortiGate is Receiving Requests (Example: SSL-VPN connection): Start by using the sniffer tool to ensure that the FortiGate is receiving the connection requests from the FortiClient or a remote device. Use the following command: diagnose sniffer packet "host <Public IP address of the FortiClient>" 4 0 l <-----  'l' is lowercase of 'L'. The following output is observed, where the FortiClient's WAN IP is seen as a source for incoming to FortiGate for SSL VPN connection, but FortiGate is not generating any response. The following output is observed in the debugs, where the FortiClient's WAN IP is seen as a source for incoming to FortiGate for SSL VPN connection, but FortiGate is not generating any response. Debugs to run: diag debug reset   diagnose debug application fnbamd 255  diagnose debug application sslvpn -1  diagnose debug application samld -1  diagnose debug console timestamp enable  diagnose debug enable  A white or blank screen may be observed on the FortiClient if FortiClient is configured with SSL VPN using SAML authentication. Check Geo-Block Restrictions (Example: SSL-VPN connection): Geo-blocking could be preventing traffic from reaching the FortiGate. To determine if this is the case: Review whether Geo-block restrictions are applied based on the FortiClient’s geographic location by following this guide: Restricting SSL-VPN Connectivity by Geo-location. If Geo-block is configured and the FortiClient’s location is in an allowed country, ensure that the Geo-IP database is up-to-date by following this article: Verifying Geo-IP database. Check Local-In Policies (Example: SSL-VPN connection): Next, ensure that no local-in policies are blocking VPN traffic. If local-in policies are configured, they should allow traffic from the FortiClient's public IP address. For more details on configuring local-in policies, refer to this article: Local-In Policy Configuration. Verify Port Configuration (Example: SSL-VPN connection): Ensure that the port numbers for SSL VPN are correctly configured on both FortiGate and FortiClient. If there is a mismatch in port settings, FortiGate will not be able to process the connection request. The sniffer output below shows that the FortiGate is receiving the connection on port 443, rather than the correct port number configured on the device. For more detailed guidance on configuring VPN access, refer to the following resources: SSL-VPN Full Tunnel Setup SSL-VPN Split Tunnel Setup IPSec Dial-up Full Tunnel Setup FortiClient Dialup IPSec VPN Split Tunnel Setup Resolve Virtual IP Conflicts (Example: IPSec dial-up connection): A common issue arises when Virtual IP (VIP) configurations conflict with the VPN port numbers. For example, IPsec uses UDP ports 500 or 4500, while SSL-VPN uses a port specified under VPN -> SSL VPN Settings. If a Virtual IP is configured with the same WAN IP and port as the VPN, the traffic could be incorrectly routed or dropped. To verify the VIP configuration and avoid conflicts, refer to this article: Using Virtual IPs for Port Forwarding. Use the following diagnostic commands to inspect the traffic flow and ensure that incoming VPN traffic is not being DNATed: diagnose debug reset diagnose debug flow filter addr <Public IP address of the FortiClient> diagnose debug flow show function-name enable diagnose debug console timestamp enable diagnose debug flow show iprope enable diagnose debug flow trace start 999 diagnose debug enable The following debugs indicate an IPsec VPN connection conflict with a Virtual IP on port UDP 500, showing that the traffic is being DNATed due to the Virtual IP configuration: Ensure no other traffic is being generated between the source public IP address and the FortiGate while running these commands. If there is a conflicting VIP configuration, traffic will be observed being DNATed. Verify HTTPS GUI Access (Example: FortiGate access via GUI): If the issue is with the FortiGate HTTPS GUI not reachable, check for any restrictions that may be blocking access. This can include local-in policies, Geo-blocking, or other access controls. For more details on troubleshooting HTTPS GUI access, refer to this article: Troubleshooting Tip: Cannot Access the FortiGate Web Admin Interface. Though this article focuses on SSL VPN and IPsec VPN traffic, the principles discussed here apply to any service FortiGate listens to. This includes administrative services like the HTTPS GUI, SSH, and SNMP. If FortiGate receives traffic for any of the listening services but does not respond, the troubleshooting steps outlined in this article can be applied.