For the last couple of days, I’ve been mystified as to why I could access a SharePoint site from other Windows servers on the same LAN but not from clients (Mac, Linux or Windows) elsewhere on the network (and on the Internet).

Strangely, the server responded to ping requests, but I couldn’t successfully traceroute ipaddress. Now I’ve realised why… I had the wrong default gateway set in the TCP/IP stack. So simple, yet so crucial. Furthermore, tracert ipaddress on Windows worked (tricking me into thinking it was a Mac OS X/Linux problem) – it turns out that many Unix-derived operating systems use UDP for traceroute whereas the Windows implementation (tracert) uses ICMP. As ping (which uses ICMP) was working, my Windows trace was successful but, because ICMP operates at the network layer in the OSI model and UDP is at the transport layer, the return UDP packets to a Mac OS X or Linux client would have been unable to reach me because of the incorrect gateway on the SharePoint server.

It just shows that, from time to time, it can be useful to go back to basics when troubleshooting TCP/IP issues:

• Firstly, check that the cable is plugged in. Believe me, it’s amazing how many times that is the cause of the problem!
• Next, check that the computer has correct IP addressing details. IP addresses starting with 169.254 are link-local or automatic private IP addressing (APIPA) addresses, used when a DHCP server cannot be located. Key settings to check are the IP address itself, subnet mask, default gateway/router address (used to find the next hop) and nameserver (DNS or WINS) addresses (used to locate a server to resolve friendly names to IP addresses).
• If you think the TCP/IP settings are correct then ping ipaddress from the computer to localhost (127.0.0.1), the default gateway, a known host elsewhere on the network, a known host on the Internet (in that order) – this approach will help to identify whether the issue is local to the computer, the local subnet, further out on the network or on the Internet (incidentally, many web servers will not respond to pings in order to avoid denial of service attacks such as the ping of death – so no reply from an Internet host doesn’t necessarily mean there is a problem). If pings from the computer are successful, try pings to the computer from elsewhere on the network.
• Finally, tracert ipaddress (Windows) or traceroute ipaddress (Mac OS X/Linux) can be used to check that packets are being routed correctly. Windows users also have a utility called pathping which is a combination of ping and tracert.

Some other commands that can be useful include:

• ipconfig /release followed by ipconfig /renew (Windows) or ifdown interface then ifup interface (Mac OS X/Linux) can be used to obtain a new IP address from the DHCP server (alternatively, just use ipconfig /renew or ifup interface to renew the existing address).
• The nslookup tool can be used to check the results returned by the DNS server for a particular host. If DNS is working and Internet access is available then further tests can be carried out at the DNS Stuff website.
• ipconfig /flushdns can be used for Windows users to flush the DNS cache and force a new lookup for a previously visited host.
• The netstat command can be used to see all the connections that are currently open (strange entries may indicate a problem with certain types of malware).
• telnet ipaddress portname can be useful to test a connection to a host.
• If the command line is too confusing, Windows users can use netsh diag gui as a last resort!