Chapter 9. External Problems

OpenVPN, by itself, can be a complex system, with given certificates, keys, configuration, scripts, hardware, and so on. The previous eight chapters of this book have touched on troubleshooting techniques and points on where to look within OpenVPN to address problems. However, once all the internal problems have been addressed, there are still several external influencers that can create additional hassles for your VPN.

Troubleshooting external factors for many things can be a difficult endeavor. In most cases, you'll be looking into a veritable black box for which you don't have a key. By setting up a VPN server, you are relying upon your Internet Service Provider (ISP) to allow transit for your VPN traffic on both the server and client side of the connection.

Inspection and filtering

Whether you are operating a server as a corporate tool or setting up a system to escape a hostile environment, there may be network policies in place that may prevent the successful operation of an OpenVPN connection. If you are a user on a large corporate or government network, it may be against usage policy to create a VPN tunnel and technology may be deployed to actively thwart such a tunnel.

Both corporate network administrators and many governments around the world are doing something named Deep Packet Inspection (DPI). A traditional firewall will only look at what the protocol and port traffic is using and allow or deny the traffic. This method will not prevent someone from moving a service that is blocked to an allowed port to circumvent the firewall.

A firewall or border gateway enabled with DPI is able to look beyond just the protocol and port and actually look at what the traffic is. In some cases, this can be to ensure TLS traffic is actually taking place...

Routing path performance

Another component that is generally outside the control of a network operator is the overall network path. Peering agreements between upstream providers will determine the final path traffic with traverse. This path will often be weighted toward monetary cost and not always network path cost.

For many years, I ran the network for a small company in Minneapolis, MN, with the majority of our customers being local to Minneapolis. On occasion, I would receive complaints of slow performance of our network as customers attempted to communicate with our systems.

After troubleshooting, we would identify a slow hop in the path between their systems and our systems. The most frustrating part was, physically, our facilities were only 10 or so miles apart (16 km), but the network path would go approximately 400 miles (645 km) to Chicago and another 400 miles back.

At the time, due to our hosting situation, we did not have the tools or agreements in place to change the network routing...

Summary

The most basic VPN tunnel, like the one created using the Static Key Mini-Howto (https://openvpn.net/index.php/open-source/documentation/miscellaneous/78-static-key-mini-howto.html), involves only a few components and can be relatively easy to troubleshoot. As functionality and capability is added, however, additional components are leveraged, which will require their own set of troubleshooting techniques. By writing Troubleshooting OpenVPN, it was my goal to provide two specific, unique, sets of information.

The first tool is the OpenVPN specific knowledge and known issues presented here. This spans the breadth of issues identified by users on Internet Relay Chat (IRC), the web forums (https://forums.openvpn.net), and the mailing list (http://sourceforge.net/p/openvpn/mailman/). These are the most common occurring problems or sticking points encountered by both experts and novices, alike.

The second tool I tried to provide is a more general technique for troubleshooting. This techniques...