How to troubleshoot your Internet connection

This KB article provides guidance on how to troubleshoot your Internet connection. The KB article is also published in my podcast.

Case #

You cannot connect to any Internet resources via TCP/IP from your local endpoint. This article provides guidance on how to troubleshoot your Internet connection. If you need detailed guidance and tips on how to resolve TCP/IP network connectivity issues, refer to the separate KB article entitled "How to troubleshoot your TCP IP stack connectivity".

Solution #

Carry out the following checks:

• First-off confirm that you have no Internet connectivity at all. To confirm this, open your operating system terminal and type the following command. If this ping fails, this means that you have no Internet connectivity.

ping 1.1.1.1
# You can change the above public IP with a known Web server of your choice. 1.1.1.1 is a public IP address of the Cloudflare CDN free DNS servers.

• If the above public IP address ping fails, try to ping your local network gateway. This is provided by your core router and if provided by your ISP, it is usually set to 192.168.1.1 or 192.168.1.254.

ping 192.168.1.1
# Change private IP to the one corresponding to your local network gateway

• If the above private IP address ping succeeds (and the public IP address ping fails), then your issue can be isolated to the router onwards. If you have other networking devices which exist between your ISP distribution network and your router, then focus on these devices after rebooting all of them. Any custom configurations, such as L2 bridging, VPN or other PPP/WAN configuration must be thoroughly tested. At this point you may also need to contact your ISP technical support team if the issue is isolated to your ISP router.
• If the above private IP address ping fails(and the public IP address ping fails), you need to troubleshoot your network connectivity at OSI layers 2 (data link layer, i.e. Network Interface Cards (NIC)) and 1 (physical layer, i.e. cables or wireless connections)
  • First off, reboot any intermediary network appliance including routers, modems, firewalls or other network devices you may be using.
  • Check your NIC configuration and switch from DHCP to static IP and vice versa.
  • Try disabling and re-enabling your NIC.
  • If you have any custom TCP/IP configuration at the NIC level, such as when using the TCP Optimizer tool, reset it to the defaults.
  • If all above checks fail, change your Ethernet cable and/or check your WiFi configuration and wireless network coverage.
  • If you are using HomePlug devices for distributing your Ethernet network connectivity via the power lines, remove all power connections from the home plug and unplug and re-plug it to ensure any corrupt registers and caches are cleared and that communication tokens between the homeplug devices are re-initialized.
  • Reboot your computer after the above tasks and try connecting to the Internet again.

• If the above public IP address ping succeedsbut you still cannot access Internet resources, this means that you have Internet connectivity but there is some other type of malfunction in your local TCP/IP stack at a layer above layer 3 (network), where the ping command (ICMP protocol) operates. To troubleshoot the issue further and resolve it, carry out the steps below, starting from layers 7,6,5 (application-presentation-session) to layer 4 (transport) :
  • Reload your HTTP web page by clicking Cltr+F5 (Force refresh contents from the Web server)
  • Check your DNS settings. To circumvent DNS configuration, you can try to use the hosts or lmhosts file in Windows/Linux (NETBIOS protocol). You can use the dig and nslookup commands to troubleshoot DNS name resolution. If you are using third party DNS servers (such as Cloudflare or OpenDNS) try re-setting your DNS servers to your ISP default DNS servers and try again. Disable and re-enable your NIC for any changes to take effect.
  • Certain Web browsers have certain security settings. In the case of Chrome for instance, try disabling network prediction by following these steps: Go to Wrench menu > Options > Under the Hood and deselect "Predict network actions to improve page load performance." If this does not resolve the issue, we recommend selecting this option again for improved performance.
  • Check your local firewall settings and your network firewall appliance security settings (if applicable). In your local software firewall (Windows Defender, Linux iptables or other third party firewall) try adding your Web browser as a permitted program. If it is already a permitted program, try deleting it from the list of permitted programs and adding it again.
  • Check your antimalware software and your antimalware rules in your firewall hardware appliances (if applicable).
  • If you use a proxy server, check your proxy settings or check with your network administrator to make sure the proxy server is working. You should also check your Web browser and other applications that they have correct proxy configuration to point to your proxy or otherwise they must have proxy disabled.
  • If you are using a VPN proxy/client, try disconnecting and disabling the VPN proxy/client and try again.
  • Check your available Internet bandwidth by utilizing a free tool such as speedtest.net. If users or apps in your local network are consuming all of your available uplink/downlink bandwidth, you may be failing to open Web resources because of exhausted Internet bandwidth. One other reason for very slow connectivity may be a hacked network or a hacked wireless WiFi connection (stolen SSID/password). Make sure you release your network bandwidth and reset your router, allowing you to change your WiFi password. The speedtest will provide the uplink/downlink speed and an estimation of network latency via ping time. If your latency is very high (high ping time) open a support ticket with your ISP technical support team to have this fixed.
  • Check the TCP/UDP port which your application is using and ensure that this port is not blocked by your applications, by your firewall(s) or by your ISP firewall(s). You can check this with the netstat and telnet commands. Some ISPs block known ports, such as RDP port 3389. In such cases you may need to contact the ISP technical support team to ask for these UDP/TCP ports to be allowed in your account.