OpenVPN

OpenVPN is a popular open source solution for setting up VPNs, and has been included in VyOS.

Remote Access

Using TLS

Setting up the VyOS configuration

We will assume all the certificates have already been made, and are stored in /config/auth/keys. If this is not the case then they need to be generated, either by following the instructions under Creating x509 Certificates, generated using other software or obtained through a third party.

If using easyrsa to generate your certificates, than the server certificate should be built using ./build-key-server (the client still needs to be build using ./build-key).

First, we need to create the virtual tunnel interface. We will set the subnet for connecting clients as 192.168.0.0/24.

configure
edit interfaces openvpn vtun0
set mode server
set server subnet 192.168.0.0/24

Next, all the certificate locations need to be specified.

edit tls
set ca‐cert‐file /config/auth/keys/ca.crt
set cert-file /config/auth/keys/server.crt
set dh-file /config/auth/keys/dh1024.pem
set key-file /config/auth/keys/server.key

If a crl file is also used, it needs to be included here.

set crl-file /config/auth/keys/crl.pem

The configuration should now be complete.

commit
save

A route may be required to access the network from the client's machine. Assuming the network we wish to access was 10.0.0.0/24 (on the OpenVPN side), we could set up a route as follows (assuming linux is used). Here 192.168.200.1 is the address of the remote side of the tunnel (so on the VyOS side).

sudo route add -net 10.0.0.0 netmask 255.255.255.0 gw 192.168.200.1

This would route traffic destined for 10.0.0.0/24 through the VPN tunnel created by OpenVPN.

Creating the client configuration file

Next, to connect to this VPN, a configuration file needs to be created. The ca certificate and client certificate/key pair needs to be copied over to the client's machine. The following is an example of a configuration file which can be used to connect to this VPN.

# Using a tunnel interface
dev tun

# Indicate that we are a client
client

# The address of the vpn to connect to 
remote 23.90.55.23

# Location of the certificates/keys needed
ca /path/to/ca.crt
cert /path/to/client.crt
key /path/to/client.key

# Only connect to servers built using ./build-key-server.
ns-cert-type server

It is also possible to connect to this vpn using VyOS on a separate machine. The set up is nearly identical to setting up the server. The virtual tunnel interface first needs to be created, and the remote host (the address of the vpn to connect to) set.

configure
edit interfaces openvpn vtun0
set mode client
set remote-host 23.90.55.23

Next, the certificate (ca certificate and client certificate/key) locations need to be specified.

edit tls
set ca‐cert‐file /config/auth/keys/ca.crt
set cert-file /config/auth/keys/client.crt
set key-file /config/auth/keys/client.key

The client configuration is now complete.

commit
save

Site-to-Site

For these scenarios, as with site-to-site VPNs in the L2TP/IPsec section, we will assume that site 1 has a public IP of 23.90.55.5 and private IP of 10.0.0.1/24, and that site 2 has a public IP of 23.90.55.6 and a private IP of 192.168.200.1/24. The tunnel interface on site 1 will have IP 172.16.0.1 and on site 2 it will have IP 172.16.0.2.

Pre-Shared Secret

Firstly, we need to generate our pre-shared key (PSK). This can be done on any machine, but needs to be eventually stored locally on both machines.

generate openvpn key /config/auth/keys/secret.key

Now, assuming we are on site 1, we now need to set the mode as site-to-site.

configure
edit interfaces openvpn vtun0 
set mode site‐to‐site

The local address (site 1's end of the tunnel) needs to be set.

set local‐address 172.16.0.1

The remote address (site 2's end of the tunnel) also needs to be set.

set remote‐address 172.16.0.2      # Refers to site 2's end of the tunnel

The remote host needs to point to the IP address of site 2.

set remote‐host 23.90.55.6

Now we need to set the authentication we are using (pre shared secret)

set shared‐secret‐key‐file /config/auth/keys/secret.key

top

A static route is required so that the site 2's subnet (192.168.0.0/24) can be accessed from site 1, which is done by routing it through the tunnel.

set protocols static interface‐route 192.168.0.0/24 next‐hop‐interface vtun0

That completes the configuration on site 1.

commit
save

This configuration now needs to be repeated on site 2, with local-address and remote-address switched around, and the remote-host pointing to site 1. The routing also now needs to refer to site 1's subnet (10.0.0.0/24).

configure
edit interfaces openvpn vtun0
set local‐address 172.16.0.2
set mode site‐to‐site
set remote‐address 172.16.0.1
set remote‐host 23.90.55.5
set shared‐secret‐key‐file /config/auth/keys/secret.key

top 

set protocols static interface‐route 10.0.0.0/24 next‐hop‐interface vtun0
commit
save

It should also be noted that only one remote-host actually needs to be set between the two sites, as long as a connection can be made from one.

TLS

Using the same scenario above, we will be creating a site-to-site VPN using TLS instead of using a pre-shared secret. In this we will assume all the necessary certificates/keys are stored in /config/auth/keys, and that the static-routes from beforehand have already been set up.

The configuration for site 1 is similar to the configuration when using a pre-shared secret, except certificates are used instead. In this case we will assume that site 1 takes the "passive" role, that is it listens for the TLS connections. The certificate for the passive site needs to be built using ./build-key-server, while the active site should be built using ./build-key.

Firstly, the virtual tunnel interface needs to be created, similarly to how it was done above.

configure
edit interfaces openvpn vtun0
set local‐address 172.16.0.1
set mode site‐to‐site
set remote‐address 172.16.0.2
set remote‐host 23.90.55.6

Now the certificates and role needs to be specified.

edit tls
set role passive
set ca‐cert‐file /config/auth/keys/ca.crt
set cert‐file /config/auth/keys/site1.crt
set key‐file /config/auth/keys/site1.key
set dh‐file /config/auth/keys/dh1024.pem

If you wish to use a list of revoked certificates (and if it exists).

set crl-file /config/auth/keys/crl.pem

Again, a static route is required so that the site 2's subnet (192.168.0.0/24) can be accessed from site 1, which is done by routing it through the tunnel.

top

set protocols static interface‐route 192.168.0.0/24 next‐hop‐interface vtun0

Finally commit and save.

commit
save

Site 2 follows a similar configuration, but takes the "active" role, that is it initiates the TLS connection. This means that it does not require a crl-file or dh-file.

Firstly we need to set up the virtual tunnel interface.

configure
edit interfaces openvpn vtun0
set local‐address 172.16.0.2
set mode site‐to‐site
set remote‐address 172.16.0.1
set remote‐host 23.90.55.5

The certificates and role needs to be specified.

edit interfaces openvpn vtun0 tls
set role active
set ca‐cert‐file /config/auth/keys/ca.crt
set cert‐file /config/auth/keys/site2.crt
set key‐file /config/auth/keys/site2.key

If you wish to use a list of revoked certificates (and if it exists).

set crl-file /config/auth/keys/crl.pem

The static route is also required.

top

set protocols static interface‐route 10.0.0.0/24 next‐hop‐interface vtun0

Finally commit and save.

commit
save

Further features

Encryption

By default OpenVPN uses Blowfish (with 128-bit keys) for encryption and SHA-1 for hashing, although this can be changed.

set interfaces openvpn vtun0 encryption <ENCRYPTION>
set interfaces openvpn vtun0 hash <HASH>

The available encryption algorithms are:

  • des: DES algorithm
  • 3des: DES algorithm with triple encryption
  • bf128: Blowfish algorithm with 128-bit key
  • bf256: Blowfish algorithm with 256-bit key
  • aes128: AES algorithm with 128-bit key
  • aes192: AES algorithm with 192-bit key
  • aes256: AES algorithm with 256-bit key

The available hashing algorithms are:

  • md5: MD5 algorithm
  • sha1: SHA-1 algorithm
  • sha256: SHA-256 algorithm
  • sha512: SHA-512 algorithm

Static client IPs

In some cases static IPs might be needed for clients. Say we wish to give a client a static IP of 192.68.200.23. This could be achieved with the following configuration commands. Note that the client is specified through their common name.

set interfaces openvpn vtun0 server client <CLIENT> ip 192.168.200.23

Limiting access

Say you wish to limit the client's access to the VPN's network (10.0.0.0/24). This can be done using push-route, and specifying the desired addresses which they can access. In this case, the client is given access to the entire network.

set interfaces openvpn vtun0 server client <CLIENT> push-route 10.0.0.0/24

The client's local subnet (192.168.0.0/24) should also be set.

set interfaces openvpn vtun0 server client <CLIENT> subnet 192.168.0.0/24

If we wish to allow the actual VyOS machine access to the client's subnet, we need to route traffic intended for the subnet through the tunnel.

set protocols static interface‐route 192.168.0.0/24 next‐hop‐interface vtun0

Multiple remote endpoints

It is also possible to add multiple remote host endpoints, to provide fall-back servers or for load balancing. When using a configuration file, this can be done by adding extra remote lines. OpenVPN will go through these sequentially until it finds one it can connect to. The float command is required when this is done.

# List of vpns to try and connect to 
remote 23.90.55.23
remote 12.34.56.78
remote 1.2.3.4

float

If you wish to randomise which vpn to connect to (load balancing), simply add the following line.

remote-random

If using VyOS as a client, additional remote host commands are required. As with above, they will be checked sequentially until it finds one it can connect to.

set interfaces openvpn vtun0 server remote host 23.90.55.23
set interfaces openvpn vtun0 server remote host 12.34.56.78
set interfaces openvpn vtun0 server remote host 1.2.3.4

Using a firewall with the openvpn interface

Since an openvpn interface is being used, a firewall can also be set up on it.

set firewall name openvpn-local
.....
set interfaces openvpn vtun0 firewall local name openvpn-local
commit