Select Page

Troubleshooting, Possible Next Steps, and a Favor

Back to the overview
Back to step 4

And there you have it. Four easy steps to build a VPN without spending one penny. What could possibly go wrong? Here are a few troubleshooting tips I discovered as I built this.

Server doesn’t start

  • Make sure you have the correct name for the .conf file. The general form of the systemctl start/stop syntax is
systemctl start|stop|status openvpn-server@[conf file name].service
  • Make sure you have the correct certificate, key, and configuration files in the correct directories. On the server, the base for everything is /etc/openvpn.
    • CA (Certificate Authority) operations
      • /etc/openvpn/ca
      • /etc/openvpn/ca/pki/issued – for issued certificates. If something bad happens to a client or server, you can always get new copies from here.
      • /etc/openvpn/ca/private – the private CA key and client keys. This ca key needs to stay private; do not copy it anywhere else. Clients need a copy of their keys.
    • Server files
      • /etc/openvpn/server – configuration file and some logging and DHCP status info.
      • /etc/openvpn/server/pki/ – the server certificate, a copy of the CA certificate, and Diffie-Hellman parameters.
      • /etc/openvpn/server/pki/private – the server private key. Keep this secret; don’t copy it anywhere else.
      • /etc/openvpn/server/ccd – custom client connect and disconnect scripts.
      • /etc/openvpn/server/logs – client connect and disconnect logs.
    • client files
      • /etc/openvpn/client – the template client config file lives here.
  • The unit file that controls startup is /usr/lib/systemd/system/openvpn-server@.service. Use it as a reference – don’t edit it.
  • Keep an eye on log messages in /var/log/messages.
  • The command, journalctl -xe is your friend.
  • Another helpful tactic–set up two ssh windows into your OpenVPN server. In one window, do journalctl -f. In the other window, start and stop your openvpn-server service. This will give you immediate feedback on any issues starting up.
  • Keep an eye on the expiration dates of your certificates. They should be good for five years.

Windows Client problems

  • C:\Program Files\OpenVPN\config contains all the config and authentication files. Only the admin can edit files in this directory – not even a user with admin permissions can do it. Save yourself aggravation and make sure you run notepad, WinSCP, or any other programs as the administrator.
  • %USERPROFILE%\OpenVPN\log contains the client connection log.
  • You may see connection failures that look like authentication problems. Debug by also looking at /var/log/messages on the server.

Integration issues

  • Make sure user and group openvpn:openvpn owns everything in the /etc/openvpn directory tree.
  • Make sure your OpenVPN server is set up as a router. Use the sysctl setup from step 3. If you can ping, but nothing in your internal network, this is a likely cause.
  • Compression settings in both the client and server configurations must match. If not, the VPN will connect, but neither side will be able to see the other.
  • MTU settings should also match. You’ll see warnings if they don’t.
  • The ping program is your friend. From the client, ping various systems inside your company network. Start close to the logical edge and work your way inside.
    • First ping the other side of your tunnel at If this responds, then the tunnel is good.
    • Next, ping your internal default gateway.
    • If this responds, then your OpenVPN server can route. Now ping a few internal server(s). If these answer, you should be all set.
  • Make sure your company firewall forwards and NATs UDP port 1194 to your OpenVPN server.
  • The tcpdump program on the server if your friend. Learn to use it. If your firewall or internal Ethernet switch has the ability to watch packets, this can also be your friend. Watching conversations is a great way to gain insights when problems come up.

Possible Next Steps

This implementation uses client certificates with a password for two factor authentication (2FA). This can confuse end users who already hate passwords and now need to remember one more. OpenVPN includes modules and some documentation to integrate authentication Active Directory. With this in place, instead of using certificate passwords on the client, the server would validate credentials against Active Directory. This saves password hassles for users, but it’s more complicated to implement on the server. I may add this in the future.

The Red Hat internal VPN eliminates client certificates and uses a 2FA system based on LDAP credentials and a one-time-password generator. This approach scales nicely, it makes sense for end users, but it depends on every user obtaining, synchronizing, and keeping an OTP device. This initial OTP setup was never meant for general use. If an acceptable OTP implementation becomes available, I will consider adopting that approach here.

It may be necessary to set up remote systems without bringing them into the office. This will require putting the client config, CA and client certificates, and private key files into a staging area exposed to the internet for download. Find a way to do this while minimizing the risk of impostors copying this information to their systems. The client certificate passwords will be helpful here, but even better is a private way to send this information to your users. If all else fails, USB memory sticks via the postal service could work.

Nearly all of this setup could be automated, and if this catches on, I will look into it.

A couple favors

Sometimes free stuff is worth less than what you paid for it. Hopefully you’ll find this more valuable. I went to lots of trouble to make this the best quality possible. But even though I’m a Red Hat employee, with access to the smartest people on the planet who build this stuff, this implementation is from me, and not Red Hat. Any bugs or omissions are mine. And it comes with no warranty, although I’ll try to answer questions as they come up. And in the spirit of open source development, I’ll consider adding improvements if anyone wants to contribute. In return, please consider adopting an open source attitude in your organization, and consider using Red Hat for future projects.

If you find this VPN implementation helpful, please consider buying copies of my novels for everyone in your department. They’re entertaining and great cybersecurity teaching tools. If a global pandemic leaves you stuck at home for several weeks, spend your evenings with a couple of great books. Readers will love Jerry Barkley. He’s no superhero, but every time he finds himself in the middle of a crisis, he finds a way to save the day. Maybe real superheroes are ordinary people who step up. Even when they don’t want to.

Take a look at my Books page for more.

Back to the overview
Back to step 4