Case #
You try to connect two computer hosts running the TCP/IP stack via the IPv4 or IPv6 protocol and you receive various errors resulting in the systems' inability to establish an IP protocol connection. This article provides guidance on how to troubleshoot your TCP IP stack connectivity.
In a separate KB article, I am providing how-to guidance for resolving any issues with your Internet connection.
In this article, I am providing guidance on how to resolve any issues arising when you try to establish an IP connection between computer hosts, whether these hosts are using private or public IP addresses. The general troubleshooting principle is to always keep in mind the ISO OSI protocol layer architecture which allow us to prioritize network troubleshooting tasks for the real-world TCP/IP protocol stack.
Solution #
Carry out the following tasks, the execution order of which should be determined by the exact error or scenario you are having.
- First off, check the status of your Network Interface Cards (NIC) and the cabling you are using. Ensure that your NICs and cables are in a good state as well as perform checks of the intermediary routing and switching interfaces that your packet traffic is going through. If there is any type of hardware failure on the NICs, interfaces or cables, this is the first thing to check and rectify. If you see that your NIC shows a "Network Cable Unplugged" or similar message, then most likely, your computer NIC, your network cable or the corresponding switching interface is faulty.
- Assuming that there is no physical networking issue (considering layer 1 - physical) of the OSI stack, then you should transition your troubleshooting effort on the logical side of things (vs physical). One of the most fundamental as well as practically useful tools to help you troubleshoot any TCP/IP stack network connectivity issue is the ping tool. Ping is available in virtually all operating systems or can come as an app or add-on in some cases (e.g. mobile operating systems). Ping utilizes the ICMP protocol. ICMP for IPv4 is defined in RFC 792. A separate ICMPv6, defined by RFC 4443, is used with IPv6. The following list contains the most common ICMP-based ping errors and provides an idea of possible root causes in each case.
- Request timed out. This is the most common and most general ICMP-related error. The most common root cause of this error are network congestion, failure of the ARP request, some sort of packet filtering or a routing error. However this error could mean a number of things, so start from layer 1 and go up to layer 3 (IP) to resolve the issue, by following the tips in this article.
- TTL Expired in Transit. In this case you may need to increase the TTL by using the ping -i switch.
- Destination host unreachable. This means that your computer host does not have an IP route to the destination or one of the remote routers in-between your host and the destination host report that they have no route to the destination host. In some cases, editing your local route table may fix this issue.
- "Ping Request Could Not Find Host" or "Unknown Host". These messages could indicate an issue with your DNS configuration for name resolution or you made a typo.
- "PING: transmit failed, general failure" or "Hardware error". This is purely a hardware related error. Perform OSI layer 1 troubleshooting to resolve.
- Some common action items to quickly resolve ping errors are the following.
- Disable and re-enable your NIC.
- Check the configuration of your hypervisor virtual network interfaces and VPN network interfaces. Disable your VPN interfaces temporarily and try again.
- There may be a duplicate IP configuration on your host, either in another disabled NIC or in a ghosted NIC. Ensure that you remove any ghosted NICs by following instructions in the following article: https://stefanos.cloud/kb/how-to-remove-ghosted-nics-in-windows/.
- There can be an IP conflict between your machine and another computer host in the network which receives its IP configuration from a DHCP device. You should configure your router to reserve an IP range for special devices on the network (e.g. servers and peripherals) and ensure that you check for IP conflicts. In the case of an IP confict, the static IP you are trying to allocate to your machine does not get allocated and your machine receives the APIPA address (169.254.x.y).
- Change your DNS servers, in case you are using third party DNS servers, change them to your ISP DNS servers and vice versa. There are handful of freely available DNS services such as those of Cloudflare and Google.
- There can be two different default gateways in two different NICs. In this case, try to eliminate the DG of the other NIC and ensure you have a valid DG setup, in order to connect to other subnets.
- In case you have HomePlug / Powerline devices or wireless network adapters, try to disable or reset them and see if that makes any difference for your wired Ethernet adapter(s).
- Check the ARP table and confirm that there is no STP switching loop (make use of the netstat -ano and the arp commands)
- Check your NIC driver and re-install the latest version if applicable
- Check your firewall rules and the network restriction rules of any other antimalware applicaiton and temporarily disable your firewall or antimalware to check if that makes any difference.
- There are other useful tools to troubleshoot network connectivity, the most important ones are the following:
- Tracert (Windows) and traceroute (Linux)
- Pathping (Windows) and mtr (Linux)
- IPconfig (Windows) and ifconfig (Linux)
- Linux distributions also provide their own flavor of network management utilities, such as the Netplan system in Ubuntu.
- Check your operating system for various network-related services (Windows) or deamons (Linux) which may overlap with the system's proper IP address allocation operations. Such services are for example DHCP, DNS, NetBIOS, LLDP and various routing protocols such as BGP, IGMP, RIP, OSPF, IS-IS. The routing protocols may be tampering with your local host's route table. Check and make any adjustments if needed.
- Check the Windows route table by running command "route print" to check whether there is a default gateway and route path to the destination network you are trying to reach from your computer host. You may need to edit or add routes to ensure that there is a routing path to your destination.
- If all else fails, you can try to cleanup all your TCP/IP stack configuration by running the following commands in an elevated Windows CLI or Powershell session.
netsh winsock reset
netsh int ip reset
ipconfig /flushdns
ipconfig /release followed by
ipconfig /renew (in the case of DHCP)
netcfg -d- If you are troubleshooting a connection to a Cloud host and assuming that the computer host you connect from has Internet connectivity, then you should consult the troubleshooting procedures of the Cloud vendor. One such common example is when you try to RDP to an Azure VM. In this example, you should consider Microsoft's guidance, as per the following links. Do the same for any other public cloud (AWS, GCP, IBM Cloud, etc).
