Troubleshooting Tip: Initial troubleshooting steps when endpoint is unable to telnet to a public server

An endpoint might not be able to connect to a public server due to the specific routing configuration of the FortiGate.

For instance, if the default 0.0.0.0/0 route are sent towards wan1 and/or wan2, but the next hop to get into that public IP address is to another device behind the LAN, then packets are going to be sent towards the public IP address instead of the desired next hop. The following commands can be used to diagnose the issue:

1. Confirm that the packet reached the FortiGate.

Open 1st FortiGate CLI window:

diagnose sniffer packet any 'host <IP address of the source device> and port <telnet port>

Open 2nd FortiGate CLI window:

diagnose debug reset

diagnose debug flow filter clear

diagnose debug console timestamp enable

diagnose debug flow show function-name enable

diagnose debug flow filter addr <source IP address>
diagnose debug flow filter port <port number>

diagnose debug flow trace start 99

diagnose debug  enable

Disable once done troubleshooting:

diagnose debug reset

2. If the packet fails to reach the FortiGate, verify the endpoints next hop:

On Windows Command Prompt:

route print

In this case, the packets are sent towards the hotspot which by-passed the FortiGate thus the hotspot needs to be disconnected.

3. Once the next hop is verified, check for an existing route to that destination and the next hop.

get router info routing-table all

If the route to the next hop does not exist, create a new static route to that destination via CLI or GUI. On the FortiGate GUI, navigate under Network -> Static Route, specify the destination IP address, and enter the next hop.