🔒 OpenVPN server in a Docker container complete with an EasyRSA PKI CA
OpenVPN server in a Docker container complete with an EasyRSA PKI CA.
Pick a name for the
$OVPN_DATAdata volume container. It's recommended to use the
ovpn-data-prefix to operate seamlessly with the reference systemd service. Users are encourage to replace
examplewith a descriptive name of their choosing.
$OVPN_DATAcontainer that will hold the configuration files and certificates. The container will prompt for a passphrase to protect the private key used by the newly generated certificate authority.
docker volume create --name $OVPNDATA docker run -v $OVPNDATA:/etc/openvpn --rm kylemanna/openvpn ovpngenconfig -u udp://VPN.SERVERNAME.COM docker run -v $OVPNDATA:/etc/openvpn --rm -it kylemanna/openvpn ovpn_initpki
Start OpenVPN server process
docker run -v $OVPNDATA:/etc/openvpn -d -p 1194:1194/udp --cap-add=NETADMIN kylemanna/openvpn
Generate a client certificate without a passphrase
docker run -v $OVPN_DATA:/etc/openvpn --rm -it kylemanna/openvpn easyrsa build-client-full CLIENTNAME nopass
Retrieve the client configuration with embedded certificates
docker run -v $OVPNDATA:/etc/openvpn --rm kylemanna/openvpn ovpngetclient CLIENTNAME > CLIENTNAME.ovpn
Miscellaneous write-ups for advanced configurations are available in the docs folder.
systemdinit script is available to manage the OpenVPN container. It will start the container on system boot, restart the container if it exits unexpectedly, and pull updates from Docker Hub to keep itself up to date.
Please refer to the systemd documentation to learn more.
If you prefer to use
docker-composeplease refer to the documentation.
Create an environment variable with the name DEBUG and value of 1 to enable debug output (using "docker -e").
docker run -v $OVPN_DATA:/etc/openvpn -p 1194:1194/udp --cap-add=NET_ADMIN -e DEBUG=1 kylemanna/openvpn
Test using a client that has openvpn installed correctly
$ openvpn --config CLIENTNAME.ovpn
Run through a barrage of debugging checks on the client if things don't just work
$ ping 184.108.40.206 # checks connectivity without touching name resolution $ dig google.com # won't use the search directives in resolv.conf $ nslookup google.com # will use search
Consider setting up a systemd service for automatic start-up at boot time and restart in the event the OpenVPN daemon or Docker crashes.
Initialize the volume container using the
kylemanna/openvpnimage with the included scripts to automatically generate:
The OpenVPN server is started with the default run cmd of
The configuration is located in
/etc/openvpn, and the Dockerfile declares that directory as a volume. It means that you can start another container with the
-vargument, and access the configuration. The volume also holds the PKI keys and certs so that it could be backed up.
To generate a client certificate,
kylemanna/openvpnuses EasyRSA via the
easyrsacommand in the container's path. The
EASYRSA_*environmental variables place the PKI CA under
kylemanna/openvpncomes with a script called
ovpn_getclient, which dumps an inline OpenVPN client configuration file. This single file can then be given to a client for access to the VPN.
To enable Two Factor Authentication for clients (a.k.a. OTP) see this document.
tunmode, because it works on the widest range of devices.
tapmode, for instance, does not work on Android, except if the device is rooted.
The topology used is
net30, because it works on the widest range of OS.
p2p, for instance, does not work on Windows.
The UDP server uses
192.168.255.0/24for dynamic clients by default.
The client profile specifies
redirect-gateway def1, meaning that after establishing the VPN connection, all traffic will go through the VPN. This might cause problems if you use local DNS recursors which are not directly reachable, since you will try to reach them through the VPN and they might not answer to you. If that happens, use public DNS resolvers like those of Google (220.127.116.11 and 18.104.22.168) or OpenDNS (22.214.171.124 and 126.96.36.199).
The Docker container runs its own EasyRSA PKI Certificate Authority. This was chosen as a good way to compromise on security and convenience. The container runs under the assumption that the OpenVPN container is running on a secure host, that is to say that an adversary does not have access to the PKI files under
/etc/openvpn/pki. This is a fairly reasonable compromise because if an adversary had access to these files, the adversary could manipulate the function of the OpenVPN server itself (sniff packets, create a new PKI CA, MITM packets, etc).
ovpn_copy_server_filesto accomplish this).
build-client-fullcommand will generate and leave keys on the server, again possible to compromise and steal the keys. The keys generated need to be signed by the CA which the user hopefully configured with a passphrase as described above.
This means that it will function correctly (after Docker itself is setup) on all distributions Linux distributions such as: Ubuntu, Arch, Debian, Fedora, etc. Furthermore, an old stable server can run a bleeding edge OpenVPN server without having to install/muck with library dependencies (i.e. run latest OpenVPN with latest OpenSSL on Ubuntu 12.04 LTS).
Everything for the Docker container is contained in two images: the ephemeral run time image (kylemanna/openvpn) and the
$OVPN_DATAdata volume. To remove it, remove the corresponding containers,
$OVPN_DATAdata volume and Docker image and it's completely removed. This also makes it easier to run multiple servers since each lives in the bubble of the container (of course multiple IPs or separate ports are needed to communicate with the world).
At the simplest level compromising the container may prevent additional compromise of the server. There are many arguments surrounding this, but the take away is that it certainly makes it more difficult to break out of the container. People are actively working on Linux containers to make this more of a guarantee in the future.