Over the past few weeks, we have had a number of cases where support tickets needed to be opened to resolve issues where end-users were reporting “inability to access the Internet.” These can be frustrating and stressful for both end-users and the responding techs. The root cause of this type of problem report can be varied. In this week’s Tech Tidbit, I share some of the basics of our troubleshooting checklist to determine what we do and where we look to help resolve these types of issues.
Troubleshooting “I have no Internet access” issues:
Note: When working the checklist below, when you reach the step when a failure occurs, immediately note where you were and drop down to Step 7.
Step 1 – Start back at the very beginning, run an IPCONFIG /ALL on the workstation. Does it have the proper IP address, subnet mask and DNS server response for the network / VLAN the device is attached to? If not, we are probably looking at DHCP issues. If all looks good, then proceed to the next step.
Step 2 – Test local basic IP transport. PING for the device’s default gateway. Is it reachable? If not, we are looking for local building issues (workstation, switch, building core switch). If all looks good, then proceed to the next step.
Step 3 – Test IP transport to the Internet – PING a known always available Internet located IP address, Google DNS is a good choice, PING 188.8.131.52 from the device. Is it reachable? If not, we are looking at potential local switch ACL or Firewall ACL/NAT issues. If all looks good, then proceed to the next step.
Step 4 – Test if DNS resolution is working properly – PING for a known URL, something like www.cnn.com. Is the device able to use DNS to resolve the URL to an IP address? When looking at this we are not so much looking for a successful PING response (although at this writing www.cnn.com does in fact respond) we are looking to see if PING can use DNS to resolve what particular IP address it should attempt to reach when given a URL name. If PING cannot resolve a URL to an IP address, we are looking at troubleshooting DNS problems. If all still looks good, then proceed to the next step.
Step 5 – If IP transport and DNS are operating correctly, we are now looking for higher-order issues, usually with some device or tool filtering the Internet traffic out in some way. First stop would be to review your organization's web filtering tool. Review the filtering profile assigned to the device and any logs of traffic seen from the device. If all looks good, then proceed to the next step.
Step 6 – Next stop would be to look at Firewall rules, IPS blocking, or any other traffic shaping/blocking/ controlling systems in place for the cause.
Step 7 - Final step – Assuming you find a failure along one of the steps the next thing we will want to know is if the problem is limited to a single device, a region of the network or the whole network. Can you repeat the problem with the exact same failure in the exact same step on more than one device?
Depending on your situation and experience you may not be in a position to fully complete the resolution of the problem on your own. Some of you may not even have access to all the devices involved in your particular environment.
However, assuming you do, running down this checklist and knowing where along this troubleshooting chain the first failure occurs can be critical in reducing the time to resolution.
If you need to open a ticket with our support staff on this type of issue be prepared to run down this checklist for the engineer as we begin to work on your support case.