External access to OpenVPN

You can configure the publication of the OpenVPN server in several ways:

  1. Select one or more external IP addresses for connection.
  2. Choose one of the connection methods:
    • via external IP address (ExternalIP) — if there are nodes with public IPs;
    • using LoadBalancer — for all cloud providers and their deployment schemes that support LoadBalancer provisioning;
    • Direct — manually configure the traffic path from the cluster entry point to the OpenVPN pod.

Example for bare-metal clusters

Apply the following YAML file in your cluster:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: openvpn
spec:
  version: 2
  enabled: true
  settings:
    inlet: ExternalIP
    externalIP: 5.4.54.4 # External IP address.

Example for AWS and Google Cloud

Apply the following YAML file in your cluster:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: openvpn
spec:
  version: 2
  enabled: true
  settings:
    inlet: LoadBalancer

Example for a public IP address on an external Load Balancer

Apply the following YAML file in your cluster:

apiVersion: deckhouse.io/v1alpha1
kind: ModuleConfig
metadata:
  name: openvpn
spec:
  version: 2
  enabled: true
  settings:
    externalHost: 5.4.54.4
    externalIP: 192.168.0.30 # Internal IP address that will receive traffic from the external Load Balancer.
    inlet: ExternalIP
    nodeSelector:
      kubernetes.io/hostname: node

Authentication

You can configure user authentication to access OpenVPN. Alternatively, you can use the externalAuthentication parameter.
If both options are disabled, basic authentication with a generated password will be enabled.

To view the generated password, run the following command:

d8 k -n d8-system exec svc/deckhouse-leader -c deckhouse -- deckhouse-controller module values openvpn -o json | jq '.openvpn.internal.auth.password'

To generate a new password, delete the Secret resource:

d8 k -n d8-openvpn delete secret/basic-auth

The auth.password parameter is no longer supported.

Available cluster resources after connecting to VPN

After connecting to the VPN, the following parameters are pushed to the user’s computer:

  • The kube-dns address is added to the client’s DNS servers to allow direct access to Kubernetes services via FQDN;
  • A route to the local network;
  • A route to the cluster service network;
  • A route to the pod network.

Auditing user connections

To monitor user connections, you can enable logging of VPN activity in JSON format. Traffic is grouped by the following fields: src_ip, dst_ip, src_port, dst_port, ip_proto.
Using log-shipper, you can collect and store container logs for later auditing.

Why automatic DNS configuration doesn’t work on macOS and Linux with the OpenVPN client

Due to the architectural specifics of Linux and macOS, automatic DNS server configuration when using the official OpenVPN client is not supported.

These operating systems allow using external scripts that run on VPN connect and disconnect to configure DNS.

In the client configurations generated by the module, the following blocks are predefined and commented out:

# Uncomment the lines below for use with Linux
#script-security 2
# If you use resolved
#up /etc/openvpn/update-resolv-conf
#down /etc/openvpn/update-resolv-conf
# If you use systemd-resolved, first install the openvpn-systemd-resolved package
#up /etc/openvpn/update-systemd-resolved
#down /etc/openvpn/update-systemd-resolved

To activate these code blocks, you need to uncomment them (remove the leading #) and provide correct paths to the scripts.

You can either write your own scripts or use existing solutions provided by the official OpenVPN Community (for Linux).
For macOS, you can use a third-party script.

The scripts must have execution permissions.

How to revoke, rotate or delete a user certificate

All operations with client certificates are performed via the openvpn-admin web interface. Buttons for managing certificates are available to the right of each user’s name:

Actions with an active user

To rotate (issue a new certificate) or delete a client, you must first revoke their current certificate:

Actions with a revoked user

Once revoked, the Renew (rotation) and Delete (removal) actions become available.

How to rotate a server certificate

The server certificate is rotated automatically several days before it expires.

If you need to rotate the certificate manually (e.g., due to certificate corruption or an unscheduled replacement), follow these steps:

  1. Delete the secret openvpn-pki-server in the namespace d8-openvpn:

    d8 k -n d8-openvpn delete secrets openvpn-pki-server
    
  2. Restart the OpenVPN pods to trigger the generation of a new certificate:

    d8 k -n d8-openvpn rollout restart sts openvpn
    

A new certificate will be generated automatically when the pods start.

How to rotate a root certificate (CA)

The root certificate (CA) and server certificate are rotated automatically 1 day before expiration. Automatic rotation of clients certificates is not provided. The root certificate (CA) is used to sign all certificates in OpenVPN — both server and client. Therefore, when replacing the CA, you must reissue all dependent certificates.

Steps to rotate the root certificate:

  1. Revoke or delete all active client certificates using the openvpn-admin web interface. If you choose to revoke certificates, you can rotate them later (Renew) after the CA is replaced, without recreating the clients.

  2. Delete secrets openvpn-pki-ca and openvpn-pki-server in the namespace d8-openvpn:

    d8 k -n d8-openvpn delete secrets openvpn-pki-ca openvpn-pki-server
    
  3. Restart OpenVPN pods:

    d8 k -n d8-openvpn rollout restart sts openvpn
    
  4. Rotate certificates of revoked users, or create new ones.

  5. Delete all revoked certificate secrets:

    d8 k -n d8-openvpn delete secrets -l revokedForever=true