If you’ve ever had to troubleshoot a technical issue, surely you know that having pertinent information related to the issue is vital. This could include steps to reproduce the error, any captured logs detailing the issue at hand, or even steps taken attempting to (unsuccessfully) resolve the issue(s). With that being said, I will also say that there can be times of having too much information – that is, information that really isn’t related to the issue. This can lead to a distraction of focus in trying to make sense of many things that are unrelated.
This blog post will cover some troubleshooting steps that can be taken when attempting to troubleshoot a network issue. Some of these concepts can be applied to other scenarios, but the scope of this guide is going to cover troubleshooting networks with an integrated WatchGuard firewall appliance. Further, it is expected that you have access to the WatchGuard device’s management interface along with a computer that has administrative access.
First Things First
The first thing to do is stop, collect yourself and most importantly, breathe. Technical issues can vary from something small and specific affecting a single user up to a site-wide outage preventing many employees from being productive, leading to lost revenue. Regardless of your scenario, as the technical employee, you have a lot of pressure to get the issue resolved. Perhaps your job may even be on the line but if you’re frantic, it can impair logical thinking and cause more issues.
When you’re not as nervous or frantic, which may be difficult, granted, the next step would be to identify the issue. What is the issue? Ask yourself the following questions in no particular order:
- In a simple and single, high-level overview sentence, what is the issue?
- Who is all affected, is it a single employee or are multiple users affected?
- Is this issue easily reproducible?
- What products are involved; what electronic device, which operating system (OS) and what version, etc.
- Has this ever worked?
This is a great start, you can use the answers to these questions to further troubleshoot. The nice thing about troubleshooting network issues is that you can work through the issue in various ways.
I Can’t Do…
To provide an example scenario to work through, let’s suppose there are complaints about being unable to access resources over a VPN. A few questions I’d start by asking are: has this ever worked, which OS is being used and which version, what type of VPN is being used?
If this were a new deployment, then of course this has never worked, so there is no way of knowing where the issue lies. Should this have worked previously but no longer, then we’d continue with additional follow-up questions. Does the issue occur when you’re on-site or traveling?
This makes a difference because when an individual is remote, the VPN connection differs from when they were in the office behind a WatchGuard appliance. Remote VPN software WatchGuard offers is the SSL VPN client that’s available for both Mac and Windows, as well as the IPSec VPN client. For a site-to-site VPN (Branch Office VPN, in WatchGuard terms) the feature is built into the appliance so there is no additional software to keep in consideration.
Bottom line is, the issue could be the software client installed for the remote employee, the WatchGuard appliance itself, or even possibly the remote endpoint.
Our goal would be to troubleshoot what all we have access to first before we pass the buck and claim the remote side is the issue. This could actually be determined if other users have access to that same resource over the same VPN, putting the suspicion on the host machine. It could be that the remote end just so happened to block the single user having issues in the first place. Verify if other users can reach resources over that same VPN as expected. As you can see, there are a lot of “gotcha” possibilities, but needing to work through the process is still key.
You could try to reinstall the client software for remote users. If users are local, then we’d want to check other network activities outside of just VPN access – do they have general Internet access, can they reach other resources over the VPN, or is the VPN not connecting at all.
General Network Checks
During my days as a support technician for WatchGuard, typical steps that I took to resolve network issues consisted of different things depending on the issue. Some general steps to take to ensure proper access include:
- Check your IP address:
In a Windows OS, open the command prompt and issue the command “ipconfig”
For Mac / Linux, use “ifconfig” or “ip addr”Does the displayed IP address and network match up with the network assigned by the network administrator? Do you even have a valid IP that is not publicly assigned and is not part of APIPA (169.254.x.x /16)?
- Are you able to ping the remote end?
Most OSes simply accept “ping x.x.x.x” to ensure that the remote end is reachable. - Can you trace route from your host to the other host you’re trying to reach?
Windows uses “tracert x.x.x.x”
Mac / Linux requires “traceroute x.x.x.x”This step would help ensure that your host machine can indeed reach the target machine via its IP. The issue may be the software on the machine versus the machine malfunctioning. If you can’t reach the remote host via ping, then the network path would be the next step to look at.
- Verify that intermediary networking devices are not impairing network traversal.
VLAN switches can affect network traffic, as an example, or other “smart” devices that work great if and when they’re configured properly.
- Take a packet capture.
Packet captures offer traffic logs according to what arguments used, so this does require a bit more technical know-how but this may help (WatchGuard-specific).
Another common issue that customers would call in about is their inability to log into the admin interface of the WatchGuard firewall. This is definitely not a good thing, so the issue is fairly serious. Taking the above points into consideration, start by pinging the device’s management IP address – is there a response?
No? Are there any intermediary devices that could be posing an issue? Check a trace route to verify. Is a direct connection feasible to rule out the intermediary devices?
WatchGuard Configurations
Aside from the more general steps that can be taken listed above, which can be used in non-WatchGuard networks as well, there may just be a misconfiguration on the appliance itself. The key here being the use of either a packet filter or a proxy policy, along with other available security services that stack on top of the policy; IPS, GAV, APT, etc.
Packet filters simply check source IP addresses and ports as well as destination IP addresses and ports. Proxy policies do that and (optionally) much, much more. If there is an issue, more than likely the issue is a misconfiguration of the proxy policy. Proxies can do some rather intensive inspection on network traffic on higher levels of the OSI model; e.g., HTTP inspection.
It could just be that the remote end is part of a botnet, which an offered service could prevent access. Likewise, you may have unintentionally configured geolocation to prevent access to parts of the world where a company that your own company works with has servers located in. Or, more commonly, maybe you have a WebBlocker rule preventing access to particular categories.
For WatchGuard-specific issues, a great first step to take prior to opening a support case is to create a simple packet filter allowing full access. Configure the packet filter to be “From” a designated and known host that only you, as the administrator, have access to, and “To” “Any” so that the firewall does not interfere at all with the traffic. Lastly, be sure to place this policy in first place to ensure that the “From” host hits this policy first. Should this work, then chances are the issue is with your configuration. If this doesn’t work, then chances are the issue is with the remote host.
Conclusion
This article is by no means all-inclusive, as each scenario can vastly differ from the next. However, the steps that are listed here can help your support technician to troubleshoot, be it with WatchGuard support or another vendor’s support team. The more work you’ve done yourself, since you’re more familiar with your network and all, the more data you have to offer to that technician.
Aside from the above steps, looking at your WatchGuard Traffic Monitor is fairly similar to a packet capture, just without the need to use arguments. Plus, its graphical so therefore a tad more user friendly. To take it a step further, we also offer great resources to help self-troubleshoot issues categorically.
If you need to submit a support case, be sure to include the steps you’ve take, along with any relevant screenshots and packet captures. On that same note, after all, our support team is here to help you as should any vendor’s support should you be in contract.