OpenVPN
Traditionally hardware routers implement IPsec exclusively due to relative ease of implementing it in hardware and insufficient CPU power for doing encryption in software. Since VyOS is a software router, this is less of a concern. OpenVPN has been widely used on UNIX platform for a long time and is a popular option for remote access VPN, though it’s also capable of site-to-site connections.
Advantages of OpenVPN are:
It uses a single TCP or UDP connection and does not rely on packet source addresses, so it will work even through a double NAT: perfect for public hotspots and such
It’s easy to setup and offers very flexible split tunneling
There’s a variety of client GUI frontends for any platform
Disadvantages are:
It’s slower than IPsec due to higher protocol overhead and the fact it runs in user mode while IPsec, on Linux, is in kernel mode
None of the operating systems have client software installed by default
In the VyOS CLI, a key point often overlooked is that rather than being configured using the set vpn stanza, OpenVPN is configured as a network interface using set interfaces openvpn.
Site-to-Site
OpenVPN is popular for client-server setups, but its site-to-site mode remains a relatively obscure feature, and many router appliances still don’t support it. However, it’s very useful for quickly setting up tunnels between routers.
As of VyOS 1.4, OpenVPN site-to-site mode can use either pre-shared keys or x.509 certificates.
The pre-shared key mode is deprecated and will be removed from future OpenVPN versions, so VyOS will have to remove support for that option as well. The reason is that using pre-shared keys is significantly less secure than using TLS.
We’ll configure OpenVPN using self-signed certificates, and then discuss the legacy pre-shared key mode.
In both cases, we will use the following settings:
The public IP address of the local side of the VPN will be 198.51.100.10.
The public IP address of the remote side of the VPN will be 203.0.113.11.
The tunnel will use 10.255.1.1 for the local IP and 10.255.1.2 for the remote.
The local site will have a subnet of 10.0.0.0/16.
The remote site will have a subnet of 10.1.0.0/16.
The official port for OpenVPN is 1194, which we reserve for client VPN; we will use 1195 for site-to-site VPN.
The
persistent-tunneldirective will allow us to configure tunnel-related attributes, such as firewall policy as we would on any normal network interface.If known, the IP of the remote router can be configured using the
remote-hostdirective; if unknown, it can be omitted. We will assume a dynamic IP for our remote router.
Setting up certificates
Setting up a full-blown PKI with a CA certificate would arguably defeat the purpose of site-to-site OpenVPN, since its main goal is supposed to be configuration simplicity, compared to server setups that need to support multiple clients.
However, since VyOS 1.4, it is possible to verify self-signed certificates using certificate fingerprints.
On both sides, you need to generate a self-signed certificate, preferrably using the “ec” (elliptic curve) type.
You can generate them by executing command run generate pki certificate self-signed install <name> in the configuration mode.
Once the command is complete, it will add the certificate to the configuration session, to the pki subtree.
You can then review the proposed changes and commit them.
vyos@vyos# run generate pki certificate self-signed install openvpn-local
Enter private key type: [rsa, dsa, ec] (Default: rsa) ec
Enter private key bits: (Default: 256)
Enter country code: (Default: GB)
Enter state: (Default: Some-State)
Enter locality: (Default: Some-City)
Enter organization name: (Default: VyOS)
Enter common name: (Default: vyos.io)
Do you want to configure Subject Alternative Names? [y/N]
Enter how many days certificate will be valid: (Default: 365)
Enter certificate type: (client, server) (Default: server)
Note: If you plan to use the generated key on this router, do not encrypt the private key.
Do you want to encrypt the private key with a passphrase? [y/N]
2 value(s) installed. Use "compare" to see the pending changes, and "commit" to apply.
[edit]
vyos@vyos# compare
[pki]
+ certificate openvpn-local {
+ certificate "MIICJTCCAcugAwIBAgIUMXLfRNJ5iOjk/ uAZqUe4phW8MdgwCgYIKoZIzj0EAwIwVzELMAkGA1UEBhMCR0IxEzARBgNVBAgMClNvbWUtU3RhdGUxEjAQBgNVBAcMCVNvbWUtQ2l0eTENMAsGA1UECgwEVnlPUzEQMA4GA1UEAwwHdnlvcy5pbzAeFw0yMzA5MDcyMTQzMTNaFw0yNDA5MDYyMTQzMTNaMFcxCzAJBgNVBAYTAkdCMRMwEQYDVQQIDApTb21lLVN0YXRlMRIwEAYDVQQHDAlTb21lLUNpdHkxDTALBgNVBAoMBFZ5T1MxEDAOBgNVBAMMB3Z5b3MuaW8wWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASp7D0vE3SKSAWAzr/lw9Eq9Q89r247AJR6ec/GT26AIcVA1bsongV1YaWvRwzTPC/yi5pkzV/PcT/WU7JQIyMWo3UwczAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIHgDATBgNVHSUEDDAKBggrBgEFBQcDATAdBgNVHQ4EFgQUBrAxRdFppdG/UBRdo7qNyHutaTQwHwYDVR0jBBgwFoAUBrAxRdFppdG/UBRdo7qNyHutaTQwCgYIKoZIzj0EAwIDSAAwRQIhAI2+8C92z9wTcTWkQ/goRxs10EBC+h78O+vgo9k97z5iAiBSeqfaVr5taQTS31+McGTAK3cYWNTg0DlOBI8aKO2oRg=="
+ private {
+ key "MIGHAgEAMBMGByqGSM49AgEGCCqGSM49AwEHBG0wawIBAQQgtOeEb0dMb5P/2Exi09WWvk6Cvz0oOBoDuP68ZimS2LShRANCAASp7D0vE3SKSAWAzr/lw9Eq9Q89r247AJR6ec/GT26AIcVA1bsongV1YaWvRwzTPC/yi5pkzV/PcT/WU7JQIyMW"
+ }
+ }
[edit]
vyos@vyos# commit
You do not need to copy the certificate to the other router. Instead, you need to retrieve its SHA-256 fingerprint. OpenVPN only supports SHA-256 fingerprints at the moment, so you need to use the following command:
vyos@vyos# run show pki certificate openvpn-local fingerprint sha256
5C:B8:09:64:8B:59:51:DC:F4:DF:2C:12:5C:B7:03:D1:68:94:D7:5B:62:C2:E1:83:79:F1:F0:68:B2:81:26:79
Note: certificate names don’t matter, we use ‘openvpn-local’ and ‘openvpn-remote’ but they can be arbitrary.
Repeat the procedure on the other router.
Setting up OpenVPN
Local Configuration:
Configure the tunnel:
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 protocol udp
set interfaces openvpn vtun1 persistent-tunnel
set interfaces openvpn vtun1 remote-host '203.0.113.11' # Public IP of the other side
set interfaces openvpn vtun1 local-port '1195'
set interfaces openvpn vtun1 remote-port '1195'
set interfaces openvpn vtun1 local-address '10.255.1.1' # Local IP of vtun interface
set interfaces openvpn vtun1 remote-address '10.255.1.2' # Remote IP of vtun interface
set interfaces openvpn vtun1 tls certificate 'openvpn-local' # The self-signed certificate
set interfaces openvpn vtun1 tls peer-fingerprint <remote cert fingerprint> # The output of 'run show pki certificate <name> fingerprint sha256
on the remote rout
Remote Configuration:
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 protocol udp
set interfaces openvpn vtun1 persistent-tunnel
set interfaces openvpn vtun1 remote-host '198.51.100.10' # Pub IP of other site
set interfaces openvpn vtun1 local-port '1195'
set interfaces openvpn vtun1 remote-port '1195'
set interfaces openvpn vtun1 local-address '10.255.1.2' # Local IP of vtun interface
set interfaces openvpn vtun1 remote-address '10.255.1.1' # Remote IP of vtun interface
set interfaces openvpn vtun1 tls certificate 'openvpn-remote' # The self-signed certificate
set interfaces openvpn vtun1 tls peer-fingerprint <local cert fingerprint> # The output of 'run show pki certificate <name> fingerprint sha256
on the local router
Server
Multi-client server is the most popular OpenVPN mode on routers. It always uses x.509 authentication and therefore requires a PKI setup. Refer this topic PKI to generate a CA certificate, a server certificate and key, a certificate revocation list, a Diffie-Hellman key exchange parameters file. You do not need client certificates and keys for the server setup.
In this example we will use the most complicated case: a setup where each client is a router that has its own subnet (think HQ and branch offices), since simpler setups are subsets of it.
Suppose you want to use 10.23.1.0/24 network for client tunnel endpoints and all client subnets belong to 10.23.0.0/20. All clients need access to the 192.168.0.0/16 network.
First we need to specify the basic settings. 1194/UDP is the default. The
persistent-tunnel option is recommended, it prevents the TUN/TAP device from
closing on connection resets or daemon reloads.
Note
Using openvpn-option -reneg-sec can be tricky. This option is used to renegotiate data channel after n seconds. When used at both server and client, the lower value will trigger the renegotiation. If you set it to 0 on one side of the connection (to disable it), the chosen value on the other side will determine when the renegotiation will occur.
set interfaces openvpn vtun10 mode server
set interfaces openvpn vtun10 local-port 1194
set interfaces openvpn vtun10 persistent-tunnel
set interfaces openvpn vtun10 protocol udp
Then we need to generate, add and specify the names of the cryptographic materials. Each of the install command should be applied to the configuration and commited before using under the openvpn interface configuration.
run generate pki ca install ca-1 # Follow the instructions to generate CA cert.
Configure mode commands to install:
set pki ca ca-1 certificate 'generated_cert_string'
set pki ca ca-1 private key 'generated_private_key'
run generate pki certificate sign ca-1 install srv-1 # Follow the instructions to generate server cert.
Configure mode commands to install:
set pki certificate srv-1 certificate 'generated_server_cert'
set pki certificate srv-1 private key 'generated_private_key'
run generate pki dh install dh-1 # Follow the instructions to generate set of
Diffie-Hellman parameters.
Generating parameters...
Configure mode commands to install DH parameters:
set pki dh dh-1 parameters 'generated_dh_params_set'
set interfaces openvpn vtun10 tls ca-certificate ca-1
set interfaces openvpn vtun10 tls certificate srv-1
set interfaces openvpn vtun10 tls dh-params dh-1
Now we need to specify the server network settings. In all cases we need to specify the subnet for client tunnel endpoints. Since we want clients to access a specific network behind our router, we will use a push-route option for installing that route on clients.
set interfaces openvpn vtun10 server push-route 192.168.0.0/16
set interfaces openvpn vtun10 server subnet 10.23.1.0/24
Since it’s a HQ and branch offices setup, we will want all clients to have fixed addresses and we will route traffic to specific subnets through them. We need configuration for each client to achieve this.
Note
Clients are identified by the CN field of their x.509 certificates,
in this example the CN is client0:
set interfaces openvpn vtun10 server client client0 ip 10.23.1.10
set interfaces openvpn vtun10 server client client0 subnet 10.23.2.0/25
OpenVPN will not automatically create routes in the kernel for client subnets when they connect and will only use client-subnet association internally, so we need to create a route to the 10.23.0.0/20 network ourselves:
set protocols static route 10.23.0.0/20 interface vtun10
Additionally, each client needs a copy of ca cert and its own client key and cert files. The files are plaintext so they may be copied either manually from the CLI. Client key and cert files should be signed with the proper ca cert and generated on the server side.
HQ’s router requires the following steps to generate crypto materials for the Branch 1:
run generate pki certificate sign ca-1 install branch-1 # Follow the instructions to generate client
cert for Branch 1
Configure mode commands to install:
Branch 1’s router might have the following lines:
set pki ca ca-1 certificate 'generated_cert_string' # CA cert generated on HQ router
set pki certificate branch-1 certificate 'generated_branch_cert' # Client cert generated and signed on HQ router
set pki certificate branch-1 private key 'generated_private_key' # Client cert key generated on HQ router
set interfaces openvpn vtun10 tls ca-cert ca-1
set interfaces openvpn vtun10 tls certificate branch-1
LDAP
Enterprise installations usually ship a kind of directory service which is used to have a single password store for all employees. VyOS and OpenVPN support using LDAP/AD as single user backend.
Authentication is done by using the openvpn-auth-ldap.so plugin which is
shipped with every VyOS installation. A dedicated configuration file is
required. It is best practise to store it in /config to survive image
updates
set interfaces openvpn vtun0 openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"
The required config file may look like this:
<LDAP>
# LDAP server URL
URL ldap://ldap.example.com
# Bind DN (If your LDAP server doesn't support anonymous binds)
BindDN cn=LDAPUser,dc=example,dc=com
# Bind Password password
Password S3cr3t
# Network timeout (in seconds)
Timeout 15
</LDAP>
<Authorization>
# Base DN
BaseDN "ou=people,dc=example,dc=com"
# User Search Filter
SearchFilter "(&(uid=%u)(objectClass=shadowAccount))"
# Require Group Membership - allow all users
RequireGroup false
</Authorization>
Despite the fact that AD is a superset of LDAP
<LDAP>
# LDAP server URL
URL ldap://dc01.example.com
# Bind DN (If your LDAP server doesn’t support anonymous binds)
BindDN CN=LDAPUser,DC=example,DC=com
# Bind Password
Password mysecretpassword
# Network timeout (in seconds)
Timeout 15
# Enable Start TLS
TLSEnable no
# Follow LDAP Referrals (anonymously)
FollowReferrals no
</LDAP>
<Authorization>
# Base DN
BaseDN "DC=example,DC=com"
# User Search Filter, user must be a member of the VPN AD group
SearchFilter "(&(sAMAccountName=%u)(memberOf=CN=VPN,OU=Groups,DC=example,DC=com))"
# Require Group Membership
RequireGroup false # already handled by SearchFilter
<Group>
BaseDN "OU=Groups,DC=example,DC=com"
SearchFilter "(|(cn=VPN))"
MemberAttribute memberOf
</Group>
</Authorization>
If you only want to check if the user account is enabled and can authenticate (against the primary group) the following snipped is sufficient:
<LDAP>
URL ldap://dc01.example.com
BindDN CN=SA_OPENVPN,OU=ServiceAccounts,DC=example,DC=com
Password ThisIsTopSecret
Timeout 15
TLSEnable no
FollowReferrals no
</LDAP>
<Authorization>
BaseDN "DC=example,DC=com"
SearchFilter "sAMAccountName=%u"
RequireGroup false
</Authorization>
A complete LDAP auth OpenVPN configuration could look like the following example:
vyos@vyos# show interfaces openvpn
openvpn vtun0 {
mode server
openvpn-option "--tun-mtu 1500 --fragment 1300 --mssfix"
openvpn-option "--plugin /usr/lib/openvpn/openvpn-auth-ldap.so /config/auth/ldap-auth.config"
openvpn-option "--push redirect-gateway"
openvpn-option --duplicate-cn
openvpn-option --client-cert-not-required
openvpn-option --comp-lzo
openvpn-option --persist-key
openvpn-option --persist-tun
server {
domain-name example.com
max-connections 5
name-server 203.0.113.0.10
name-server 198.51.100.3
subnet 172.18.100.128/29
}
tls {
ca-certificate ca.crt
certificate server.crt
dh-params dh1024.pem
}
}
Client
VyOS can not only act as an OpenVPN site-to-site or server for multiple clients. You can indeed also configure any VyOS OpenVPN interface as an OpenVPN client connecting to a VyOS OpenVPN server or any other OpenVPN server.
Given the following example we have one VyOS router acting as OpenVPN server and another VyOS router acting as OpenVPN client. The server also pushes a static client IP address to the OpenVPN client. Remember, clients are identified using their CN attribute in the SSL certificate.
Server Side
set interfaces openvpn vtun10 encryption cipher 'aes256'
set interfaces openvpn vtun10 hash 'sha512'
set interfaces openvpn vtun10 local-host '172.18.201.10'
set interfaces openvpn vtun10 local-port '1194'
set interfaces openvpn vtun10 mode 'server'
set interfaces openvpn vtun10 persistent-tunnel
set interfaces openvpn vtun10 protocol 'udp'
set interfaces openvpn vtun10 server client client1 ip '10.10.0.10'
set interfaces openvpn vtun10 server domain-name 'vyos.net'
set interfaces openvpn vtun10 server max-connections '250'
set interfaces openvpn vtun10 server name-server '172.16.254.30'
set interfaces openvpn vtun10 server subnet '10.10.0.0/24'
set interfaces openvpn vtun10 server topology 'subnet'
set interfaces openvpn vtun10 tls ca-cert ca-1
set interfaces openvpn vtun10 tls certificate srv-1
set interfaces openvpn vtun10 tls crypt-key srv-1
set interfaces openvpn vtun10 tls dh-params dh-1
set interfaces openvpn vtun10 use-lzo-compression
Client Side
set interfaces openvpn vtun10 encryption cipher 'aes256'
set interfaces openvpn vtun10 hash 'sha512'
set interfaces openvpn vtun10 mode 'client'
set interfaces openvpn vtun10 persistent-tunnel
set interfaces openvpn vtun10 protocol 'udp'
set interfaces openvpn vtun10 remote-host '172.18.201.10'
set interfaces openvpn vtun10 remote-port '1194'
set interfaces openvpn vtun10 tls ca-cert ca-1
set interfaces openvpn vtun10 tls certificate client-1
set interfaces openvpn vtun10 tls crypt-key client-1
set interfaces openvpn vtun10 use-lzo-compression
Options
We do not have CLI nodes for every single OpenVPN option. If an option is missing, a feature request should be opened at Phabricator so all users can benefit from it (see Issues/Feature requests).
If you are a hacker or want to try on your own we support passing raw OpenVPN options to OpenVPN.
Will add persistent-key at the end of the generated OpenVPN configuration.
Please use this only as last resort - things might break and OpenVPN won’t start
if you pass invalid options/syntax.
Will add push "keepalive 1 10" to the generated OpenVPN config file.
Note
Sometimes option lines in the generated OpenVPN configuration require
quotes. This is done through a hack on our config generator. You can pass
quotes using the " statement.
OpenVPN Data Channel Offload (DCO)
OpenVPN Data Channel Offload (DCO) enables significant performance enhancement in encrypted OpenVPN data processing. By minimizing context switching for each packet, DCO effectively reduces overhead. This optimization is achieved by keeping most data handling tasks within the kernel, avoiding frequent switches between kernel and user space for encryption and packet handling.
As a result, the processing of each packet becomes more efficient, potentially leveraging hardware encryption offloading support available in the kernel.
Note
OpenVPN DCO is not full OpenVPN features supported , is currently considered experimental. Furthermore, there are certain OpenVPN features and use cases that remain incompatible with DCO. To get a comprehensive understanding of the limitations associated with DCO, refer to the list of known limitations in the documentation.
https://community.openvpn.net/openvpn/wiki/DataChannelOffload/Features
DCO support is a per-tunnel option and it is not automatically enabled by default for new or upgraded tunnels. Existing tunnels will continue to function as they have in the past.
DCO can be enabled for both new and existing tunnels,VyOS adds an option in each tunnel configuration where we can enable this function .The current best practice is to create a new tunnel with DCO to minimize the chance of problems with existing clients.
Enable OpenVPN Data Channel Offload feature by loading the appropriate kernel module.
Disabled by default - no kernel module loaded.
Note
Enable this feature causes an interface reset.
VyOS provides some operational commands on OpenVPN.
Check status
The following commands let you check tunnel status.
Reset OpenVPN
The following commands let you reset OpenVPN.