This is a common end user problem. The user cannot connect to a website, and they consistently get the same error message. This illustrates how important it is to gather information because without knowing more about the problem, we do not know which of many causes may be in play here:

• User error: Did the user mistype the URL or make a similar mistake?
• Computer configuration issue: This may be the case if new software/hardware was installed recently
• Network connection issue: Does the user's computer have network connectivity?

If the problem is with our internet connection or the website, then the problem is beyond our control. However, other likely causes are more likely to be within our sphere of control; even if the problem is something that requires escalation to another tier within our support team.

Referring back to our basic troubleshooting procedure, we want to spend some time gathering information. We might question the user and ask them what error message they received when they tried to access the website. If the user cannot remember, we can ask them to recreate the problem. As an example, they may try to access the website again and receive a Server Not Found error page.

An error message such as this can have several causes. The web server to which the user is trying to connect may be down. Also, the user's internet connection may be down, or DNS resolution may not be working. Further, the user may be connecting to the website through a proxy, and the proxy may be down or misconfigured. It might be helpful to begin with the most wide-ranging possibilities first because they are the easiest to prove or disprove. Thus, we might begin by considering the possibility that the user’s internet connection is down.

Most organizations have shared internet connections. Therefore, the end user’s system will connect to a switch that connects to a router that connects to an ISP. There are several problems that could occur:

• There may be a problem with the router's connection to the ISP, or the ISP’s connection to the internet. This is a problem beyond our control, and there would be little we could do about it, other than reporting it to the ISP.
• The problem may be within our network—for example, a bad network cable or a misconfigured switch or router. Finding out the number of users affected by the problem might help us zero in on the problem. For example, a misconfigured switch will likely affect several users, whereas a bad network cable between our user’s computer and the switch will only affect that user.
• The user’s computer might be the source of the problem. There may be a problem with the network card, the networking software, or the computer's configuration. If so, our user will likely be the only person affected by the problem.

Let us assume that no other users have reported any networking problems. If this is so, it is unlikely that we have a malfunctioning router or switch, as we would likely have multiple users reporting issues. Still, we can easily eliminate this as a possibility by accessing a website using a separate computer using the same internet connection. Doing so will help us narrow down the source of the problem. We can begin to focus on the user, their computer, the way they access the site, or the computer’s connection to the network.

If we find that we are unable to access the internet via another computer connected to the network, then we may need to change our focus. A component we used to access the Internet could be broken, such as a switch, cable, or another component. It could also be the connection between our router and the ISP, and as mentioned before, then it would be beyond our control.

If users on your network are accessing the web through a proxy such as Squid, this could be the source of the problem. If you think it is the source of the problem, then this becomes your theory of probable cause. You can test the theory by temporarily disabling the proxy and seeing if you can access websites. If you can, then you have likely isolated the cause of the problem or at least one of the causes.

If you were able to access the internet via another computer and thus have narrowed down the source of the problem to either the user or the user's computer, then you should continue the process of trying to isolate the cause of the problem. You could ask the user to access a different website. If the user can do that, then the network, router, and internet connection are functioning; the problem is likely either a website that is down or user error.

If the user cannot access any other website, then you should ask the user to open another network client application and use it to try to connect to the internet. The application could be an email or FTP client. If the user can connect to the internet using another application, then we have likely isolated the cause of the problem: the web browser software on the user’s computer. If we cannot connect to the internet at all from the user’s computer, we are left trying to determine what element of the computer’s networking setup is at fault.

One possibility we should consider is that the computer’s DNS configuration is wrong. As you know, hosts rely on DNS servers to resolve hostnames to IP addresses. If the user’s computer is not configured with one or more valid DNS servers to which it can connect, name resolution will fail. An easy way of detecting likely DNS problems is to try to ping an IP address rather than a hostname. If you can ping a site when entering the IP address, but pings fail when you enter the hostname, there is a significant chance that you have a DNS issue. You will thus want to have the user check his computer’s DNS settings. In most cases, we will have configured pfSense to act as a DNS server or at least have specified upstream DNS servers in the settings. Therefore, resolving the issue may be as simple as having the user click on Obtain DNS server address automatically so that they use the DNS server specified by the upstream router.

If we cannot ping an IP address of a site on the internet, then DNS misconfiguration either isn’t an issue—or at least, isn’t the only issue. There could be another configuration issue. An incorrect gateway may have been specified, in which case the user will only have access to the local subnet. We might try pinging a host on the same network, then ping a computer on a different network and see what the result is. If the user can access the local network but not another network, there is a good chance the issue is a network configuration issue, such as an incorrect gateway specified. If even a ping to a local host fails, however, we should consider whether the problem is the computer hardware.

If we suspect that the network card is at fault, we could try pinging the loopback (127.x.x.x) address. If this fails, then there is a good chance the network card drives may need to be reinstalled. The network card itself may be broken as well. If we can ping the loopback address, then it is likely the network card is functioning, and we might consider checking the cabling instead.

Once you have identified the problem, you still have to formulate a plan of action. In this case, the user will likely want to have the issue resolved as soon as possible. Therefore, you can begin working on fixing the problem right away. In other cases, implementing a solution may affect many users. If so, it is good practice to inform such users and also to follow any procedures your organization has for performing such maintenance. When you test the solution, you may not have success at first. For example, what if we replace the network card, only to find we still cannot access the internet from the computer. There may have been two or more causes preventing the user from accessing the internet, and we may have only solved one of them. We would have to go back to step one, gather more information, and formulate a new theory of probable cause. Even if your tests are successful, you will want to verify system functionality and document what you have done.

As you can tell by our relatively brief discussion of this troubleshooting scenario, even a simple problem can have many possible causes. Nonetheless, by employing the troubleshooting procedure we outlined in the first section, we can work toward eliminating many of these possibilities and move toward a solution.