Troubleshooting Tip: Packet logic analysis when a host is unable to access the FortiGate

[Renante_Era]

Description	This article describes how to troubleshoot when one host or client computer is unable to communicate with another host or server.
Scope	FortiGate v7.0+.
Solution	Case: Endpoint is unable to access the gateway. Check if there are physical layer issues. Ensure that the RJ45 cable is connected to the ethernet port or that the computer is properly connected to SSID if it is using WiFi. Check the TCP/IP stack. For instance, use ping 127.0.0.1 on the Windows command prompt. Check the endpoint's IP address and its gateway address. In Windows, it is possible to use ipconfig/all to ensure that the computer has a valid IP address, Gateway, and DNS server. The above image shows that the LAN IP address to reach the FortiGate is 10.0.9.3/24 and its gateway is 10.0.9.251 while the DNS servers are 208.67.222.222 and 8.8.8.8. Check if the endpoint was able to reach the gateway. For instance, if the gateway is FortiGate, some of the steps are as follows: Test the FortiGate reachability using ping. Test the FortiGate reachability using SSH. Test the FortiGate reachability using a terminal emulator such as PuTTY. Test the FortiGate reachability using the browser. In most cases, the endpoint should be able to ping the gateway. However, gateways are sometimes configured not to reply to ping for security reasons. It is also possible that ping was enabled on the interface, but the FortiGate is not replying because the Trusted Host was configured for security reasons. In some cases, the HTTP, HTTPS, and SSH ports might have been intentionally updated. In these situations, check if it is possible to reach the internet by sending a ping to an FQDN or public IP address. If the ping to FQDN fails, there is a possibility that the DNS server is not reachable, so ping a public IP address instead. Troubleshooting the reachability of the FortiGate: Access the FortiGate from a computer that has an IP address that belongs to the trusted host's IP address. If that is not possible, then connect directly to the FortiGate via console cable and use the command 'show system admin | grep -f trusthost' to see if the trusted host is configured. Alternatively, use a sniffer to confirm if the packet reached the FortiGate.  The following command and output show that the packet reached the FortiGate, but the sender is unable to establish a 3-way handshake: di sni pa any 'host 10.0.9.3 and port 443' 4 0 a di sni pa any 'host 10.0.9.3 and port 22' 4 0 a Similarly, the following output shows that the ICMP echo request reached the FortiGate, but there are no ICMP echo replies: di sni pa any 'host 10.0.9.3 and icmp' 4 0 a What the above sniffer commands show is that it is possible to use a sniffer to quickly see if the packet reached the FortiGate. However, the sniffer is not enough to determine the cause of the issue, and that is where the debug flow comes into play: kvm70 # di de fl filter cl kvm70 # di de cons t en kvm70 # di de fl sh f en show function name kvm70 # di de fl filter addr 10.0.9.3 kvm70 # di de fl filter port 443 kvm70 # di de fl tr start 99 kvm70 # di de en For the ping test, use  'di de fl filter proto 1 instead of # di de fl filter port 443' The output 'msg=check failed on policy 0 drop' indicates that there is no matching firewall policy and the following image confirms that there is a LAN>WAN firewall policy. The sender 10.0.9.3 and the FortiGate 10.0.9.251 are on the same broadcast domain, thus a port3>port3 firewall policy is not necessary. The most likely reason for 'msg="iprope_in_check() check failed on policy 0 drop' is due to the trusted host, it is possible to confirm that by adding the IP address of the sender or by unsetting the value by checking below article: Troubleshooting Tip: debug flow messages 'iprope_i... - Fortinet Community kvm70 # config system admin kvm70 (admin) # edit admin kvm70 (admin) # set trusthost2 10.0.9.3/32 kvm70 (admin) # end Use the command unset trusthost1 to unset the trusted host value instead. The debug flow output now shows that 3-way handshakes were complete, and packets are passing through.  Disable debug flow using 'di de dis' or 'di de res'. It is also possible to confirm that the FortiGate is now accessible using the GUI. If it is still not possible to access the FortiGate via GUI, CLI, or SSH even after unsetting all the admin's trusted host, then confirm via CLI if the GUI port is port 443 as well as the SSH port is 22: kvm70 # show full system global | grep admin-sport set admin-sport 443 set management-port-use-admin-sport enable kvm70 # show full system global | grep admin-ssh-port set admin-ssh-port 22   Another possible reason is due to local-in-policy which it is possible to confirm using 'show full firewall local-in-policy'.