OpenVPN for Docker

OpenVPN server in a Docker container complete with an EasyRSA PKI CA.

Credit

• Most of the work from kylemanna/docker-openvpn

Quick Start

• Setup envs:

    cp vpn.envs.sample vpn.envs
    vim vpn.envs
  

• Build the image (optional)

    ./gantry build-image
  

• Create the OVPN-DATA volume container

    ./gantry create-data
  

• Initialize the OVPN-DATA container that will hold the configuration files and certificates

    ./gantry init-vpn
  

• Start OpenVPN server process

    ./gantry start-vpn
  

• Generate a client certificate without a passphrase

    ./gantry gen-client CLIENTNAME
  

• Retrieve the client configuration with embedded certificates

    ./gantry get-client CLIENTNAME > CLIENTNAME.ovpn
  

Advanced

• Enable debug in vpn.envs before starting VPN server

    OVPN_DEBUG=1 ./gantry start-vpn
  

• Attach shell to openvpn server container

    ./gantry shell
  

Backup & Restore

• Backup to a file (See 'backup docs` for discussion on security).

    ./gantry backup openvpn.tar.xz
  

• Restore backup to a new data volume

    ./gantry restore openvpn.tar.xz
  

How Does It Work?

Initialize the volume container using the jcap/openvpn image with the included scripts to automatically generate:

• Diffie-Hellman parameters
• a private key
• a self-certificate matching the private key for the OpenVPN server
• an EasyRSA CA key and certificate
• a TLS auth key from HMAC security

The OpenVPN server is started with the default run cmd of ovpn_run

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 --volumes-from flag, 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, jcap/openvpn uses EasyRSA via the easyrsa command in the container's path. The EASYRSA_* environmental variables place the PKI CA under /etc/opevpn/pki.

Conveniently, jcap/openvpn comes 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.

OpenVPN Details

We use tun mode, because it works on the widest range of devices. tap mode, for instance, does not work on Android, except if the device is rooted.

The topology used is subnet.

The UDP server uses192.168.255.0/24 for 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 (8.8.4.4 and 8.8.8.8) or OpenDNS (208.67.222.222 and 208.67.220.220).

Security Discussion

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).

• The certificate authority key is kept in the container by default for simplicity. It's highly recommended to secure the CA key with some passphrase to protect against a filesystem compromise. A more secure system would put the EasyRSA PKI CA on an offline system (can use the same Docker image and the script ovpn_copy_server_files to accomplish this).
• It would be impossible for an adversary to sign bad or forged certificates without first cracking the key's passphase should the adversary have root access to the filesystem.
• The EasyRSA build-client-full command 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.
• Assuming the rest of the Docker container's filesystem is secure, TLS + PKI security should prevent any malicious host from using the VPN.

Benefits of Running Inside a Docker Container

The Entire Daemon and Dependencies are in the Docker Image

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).

It Doesn't Stomp All Over the Server's Filesystem

Everything for the Docker container is contained in two images: the ephemeral run time image (jcap/openvpn) and the data image (using phusion/baseimage as a base). To remove it, remove the two Docker images and corresponding containers and it's all gone. 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).

Some (arguable) Security Benefits

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.

Differences from jpetazzo/dockvpn

• No longer uses serveconfig to distribute the configuration via https
• Proper PKI support integrated into image
• OpenVPN config files, PKI keys and certs are stored on a storage volume for re-use across containers
• Addition of tls-auth for HMAC security

Tested On

• Docker hosts:
  • Linode Server running Ubuntu 15.04 with OverlayFS