Troubleshooting Tip: How to perform initial troubleshooting when a device is unable to reach the internet

[Renante_Era]

Description	This article describes the initial troubleshooting steps that users or network/system administrators should do to reduce the troubleshooting time and downtime.
Scope	FortiGate.
Solution	There are various reasons why a device is unable to reach the internet. The following steps briefly describe the checklists that users or network/system administrators should do and collect before reaching out to TAC to reduce the troubleshooting time and downtime. Determine if the device's NIC (Network Interface Card) is functional by sending a ping to the loopback interface. In Microsoft Windows, open the Command Prompt by selecting the Start button or pressing the Win key on the keyboard and typing 'command'. Take this opportunity to Pin to taskbar the Command Prompt as well. Next, ping 127.0.0.1 and ensure that the loopback interface responds as shown below. If the ping fails, open the Device Manager (devmgmt.msc) and review the Network adapters' device driver. Ping another device on the network or ping the gateway. Try to ping another device on the network, but keep in mind that it may not reply due to Windows Firewall, Anti-virus firewall, network discovery settings, intentionally disabled ping service, device not on the same broadcast domain and misconfigured gateway, or routing misconfiguration, etc. Start by identifying the device IP address using ipconfig /all. The output of the above ipconfig /all command shows that the device IP address is 10.0.1.119/24, the default gateway of 10.0.1.1, and the DNS server is 8.8.8.8. Typically, corporate networks utilize internal DNS server(s) and DHCP server(s). If needed, temporarily assign a static IP address, subnet mask, default gateway, and DNS server(s). The above output shows that the device is unable to ping a host on the same broadcast domain, but it can ping the gateway. This indicates that the device connectivity either via Wireless or Ethernet is working. The failure to ping another device might be normal as mentioned above, however, failure to ping the gateway may indicate incorrect gateway settings, routing, or network connectivity issues. Ensure that the ICMP echo request reaches the upstream Layer 3 device and if the upstream device is sending back an echo reply. Check the upstream Layer 3 device and ensure that the echo requests and replies are visible. In FortiGate, access the CLI via console or GUI, and use packet sniffer to determine if the echo request reached the FortiGate. diag sniffer packet any 'host <w.x.y.z> and icmp' 4 --> where w.x.y.z is the IP address of the ICMP echo request sender. Press Ctrl+C to stop the sniffer. Ensure that echo replies are routed correctly and FortiGate is not dropping the packet using debug flow. In some cases, FortiGate indicates that it is receiving the echo request and sending the echo replies but not reaching the source device. Debug flow should show more details about the packet. diagnose debug reset diagnose debug flow filter clear diagnose debug flow show function-name enable diagnose debug flow show iprope enable diagnose debug console timestamp enable diagnose debug flow filter diagnose debug flow filter addr <w.x.y.z> diagnose debug flow filter proto 1 diagnose debug flow trace start 99 diagnose debug enable Don't forget to disable the debug once done troubleshooting. diagnose debug disable The output of the debug flow should show the ingress and egress interface, where the packet is being routed, and more. If the packets do not match a firewall policy, the debug flow shows that the FortiGate is dropping the packets due to implicit policy 0. It might also be due to a routing issue if the debug flow indicates a Reverse Path Check Fail Drop. Check if FortiGate is able to reach FortiGuard. FortiGate might drop the packet if it is unable to reach the FortiGuard. First, identify which firewall policy the packets are matching using the session filter. diag sys session filter clear di sys session filter src w.x.y.z di sys session list | grep policy_id Next, open the matching firewall policy and determine if UTM (Unified Threat Management) such as Antivirus, Web Filter, etc. are used in the firewall policy. If UTM were used on the firewall policy: Check if FortiGate can reach FortiGuard via CLI: exec ping service.fortiguard.net exec ping update.fortiguard.net Check if FortiGate can reach FortiGuard via FortiGate GUI's System -> FortiGuard: Packets matching the firewall policy with UTM enabled are dropped if the device's FortiGuard subscription expires. Either disable the enabled UTM on the firewall policy or copy and paste the firewall policy in Policy & Objects -> Firewall Policy, disable the UTM security profiles, and enable the firewall policy. Note that policies are evaluated from top to bottom. Check internet connectivity. Ping an FQDN such as ping fortinet.com and see if responds. Next, ping an IP address such as 8.8.8.8. If a ping on an IP address works but not on FQDN, check the DNS server. Alternatively, temporarily change the DNS settings of the device to 8.8.8.8 or the ISP's DNS and see if it is going to work. When the device is pointing to an internal DNS server, keep in mind that connection to internet is going to be blocked if the FortiGate is unable to reach FortiGuard even if no UTM profiles were enabled on the outbound firewall policy for that device. The DNS server might be matching a different outbound firewall policy with DNS filter's profile applied. Feel free to decide whether Allow DNS request when a rating error occurs should be enabled based on the corporate's security profile requirements. If the issue persists, then attach the debug output when opening a TAC ticket at support.fortinet.com.