VyOS Networks Blog

While working on an implementation for IPSec IKEv2 remote-access — or road-warriors as others call it — we once more hit a long-standing burden of VyOS on how encryption keys are handled. In the old Vyatta and VyOS 1.2 days, all encryption keys and certificates were stored as single files under the /config/auth directory, making it cumbersome to port configurations from router A to router B.

This led to a new subsystem which is now the backend for any service relying on encryption ciphers, which is the first buzzword of this blog's topic — PKI.

Public Key Infrastructure (PKI)

Phabricator Task T3642 describes a new CLI subsystem that serves as a "certstore" to all services requiring any kind of encryption key(s). In short, public and private certificates are now stored in PKCS#8 format in the regular VyOS CLI. Keys can now be added, edited, and deleted using the regular set/edit/delete CLI commands.

VyOS not only can now manage certificates issued by 3rd party Certificate Authorities, it can also act as a CA on its own. You can create your own root CA and sign keys with it by making use of some simple op-mode commands. You can find additional information in the PKI documentation on how to put this "assistant" into use.

The "certstore" ranges from a simple backend store holding CA and server certificates/keys to a full-blown PKI which supports issuing server certificates or providing OpenVPN and Diffie Hellman keypairs.

vyos@vyos:~$ show pki ca
Certificate Authorities:
Name            Subject                                                  Issuer CN          Issued               Expiry               Private Key    Parent
--------------  -------------------------------------------------------  -----------------  -------------------  -------------------  -------------  --------------
DST_Root_CA_X3  CN=ISRG Root X1,O=Internet Security Research Group,C=US  CN=DST Root CA X3  2021-01-20 19:14:03  2024-09-30 18:14:03  No             N/A
R3              CN=R3,O=Let's Encrypt,C=US                               CN=ISRG Root X1    2020-09-04 00:00:00  2025-09-15 16:00:00  No             DST_Root_CA_X3
vyos_rw         CN=VyOS RW CA,O=VyOS,L=Some-City,ST=Some-State,C=GB      CN=VyOS RW CA      2021-07-05 13:46:03  2026-07-04 13:46:03  Yes            N/A

vyos@vyos:~$ show pki certificate
Certificates:
Name       Type    Subject CN             Issuer CN      Issued               Expiry               Revoked    Private Key    CA Present
---------  ------  ---------------------  -------------  -------------------  -------------------  ---------  -------------  -------------
ac2        Server  CN=ac2.vyos.net        CN=R3          2021-07-05 07:29:59  2021-10-03 07:29:58  No         Yes            Yes (R3)
rw_server  Server  CN=VyOS RW             CN=VyOS RW CA  2021-07-05 13:48:02  2022-07-05 13:48:02  No         Yes            Yes (vyos_rw)

But why did we do it? I thought this post was about IPSec IKEv2 road-warriors and now you only talk about PKI cert handling?

IKEv2 IPSec road-warriors remote-access VPN

Internet Key Exchange version 2, IKEv2 for short, is a request/response protocol developed by both Cisco and Microsoft. It is used to establish — and secure — IPv4/IPv6 connections, be it a site-to-site VPN or from a road-warrior connecting to a hub site. IKEv2, when run in point-to-multipoint, or remote-access/road-warrior mode, secures the server-side with another layer by using an x509 signed server certificate — thus we needed a better way to handle server certificates than we did in the past by simply dropping them as files into the /config/auth directory.

Key exchange and payload encryption is still done using IKE and ESP proposals as known from IKEv1 but the connections are faster to establish, more reliable, and also support roaming from IP to IP (called MOBIKE which makes sure your connection does not drop when changing networks from e.g. WIFI to LTE and back).

Encryption is supported with up to 256-bit and can use ciphers like AES, 3DES, Camellia, and ChaCha20. This is nothing new, as we already support this for site-to-site VPNs as early as of VyOS 1.1.

The demand for personnel to work remotely changed heavily in the last 1+ years during the pandemic and thus this feature comes into play rather late, but better late than never!

Enough with the talking — show us how it works

My testbed utilized both Windows 10 and iOS/iPadOS 14 and a fresh VyOS 1.4 rolling installation. The CA that I used in this example is CaCert so the CAs root and intermediate certificates are imported using the following two commands:

set pki ca CAcert_Class_3_Root certificate 'MIIGPTCCBCWgAwIBAgIDFOIoMA0GCSqGSIb3DQEBDQUAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMB4XDTIxMDQxOTEyMTgzMFoXDTMxMDQxNzEyMTgzMFowVDEUMBIGA1UEChMLQ0FjZXJ0IEluYy4xHjAcBgNVBAsTFWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzEcMBoGA1UEAxMTQ0FjZXJ0IENsYXNzIDMgUm9vdDCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAKtJNRFIfNImflOUz0Op3SjXQiqL84d4GVh8D57aiX3h++tykA10oZZkq5+gJJlz2uJVdscXe/UErEa4w75/ZI0QbCTzYZzA8pD6Ueb1aQFjww9W4kpCz+JEjCUoqMV5CX1GuYrz6fM0KQhF5Byfy5QEHIGoFLOYZcRD7E6CjQnRvapbjZLQ7N6QxX8KwuPr5jFaXnQ+lzNZ6MMDPWAzv/fRb0fEze5ig1JuLgiapNkVGJGmhZJHsK5I6223IeyFGmhyNav/8BBdwPSUp2rVO5J+TJAFfpPBLIukjmJ0FXFuC3ED6q8VOJrU0gVyb4z5K+taciX5OUbjchs+BMNkJyIQKopPWKcDrb60LhPtXapI19V91Cp7XPpGBFDkzA5CW4zt2/LP/JaT4NsRNlRiNDiPDGCbO5dWOK3z0luLoFvqTpa4fNfVoIZwQNORKbeiPK31jLvPGpKK5DR7wNhsX+kKwsOnIJpa3yxdUly6R9Wb7yQocDggL9V/KcCyQQNokszgnMyXS0XvOhAKq3A6mJVwrTWx6oUrpByAITGprmB6gCZIALgBwJNjVSKRPFbnr9s6JfOPMVTqJouBWfmh0VMRxXudA/Z0EeBtsSw/LIaRmXGapneLNGDRFLQsrJ2vjBDTn8Rq+G8T/HNZ92ZCdB6K4/jc0m+YnMtHmJVABfvpAgMBAAGjgfIwge8wDwYDVR0TAQH/BAUwAwEB/zBhBggrBgEFBQcBAQRVMFMwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLkNBY2VydC5vcmcvMCwGCCsGAQUFBzAChiBodHRwOi8vd3d3LkNBY2VydC5vcmcvY2xhc3MzLmNydDBFBgNVHSAEPjA8MDoGCysGAQQBgZBKAgMBMCswKQYIKwYBBQUHAgEWHWh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZy9jcHMucGhwMDIGA1UdHwQrMCkwJ6AloCOGIWh0dHBzOi8vd3d3LmNhY2VydC5vcmcvY2xhc3MzLmNybDANBgkqhkiG9w0BAQ0FAAOCAgEAxh6td1y0KJvRyI1EEsC9dnYEgyEH+BGCf2vBlULAOBG1JXCNiwzB1Wz9HBoDfIv4BjGlnd5BKdSLm4TXPcE3hnGjH1thKR5dd3278K25FRkTFOY1gP+mGbQ3hZRB6IjDX+CyBqS7+ECpHTms7eo/mARN+Yz5R3lzUvXs3zSX+z534NzRg4i6iHNHWqakFcQNcA0PnksTB37vGD75pQGqeSmx51L6UzrIpn+274mhsaFNL85jhX+lKuk71MGjzwoThbuZ15xmkITnZtRQs6HhLSIqJWjDILIrxLqYHehK71xYwrRNhFb3TrsWaEJskrhveM0Os/vvoLNkh/L3iEQ5/LnmLMCYJNRALF7I7gsduAJNJrgKGMYvHkt1bo8uIXO8wgNV7qoU4JoaB1ML30QUqGcFr0TI06FFdgK2fwy5hulPxm6wuxW0v+iAtXYx/mRkwQpYbcVQtrIDvx1CT1k50cQxi+jIKjkcFWHw3kBoDnCos0/ukegPT7aQnk2AbL4c7nCkuAcEKw1BAlSETkfqi5btdlhh58MhewZv1LcL5zQyg8w1puclT3wXQvy8VwPGn0J/mGD4gLLZ9rGcHDUECokxFoWk+u5MCcVqmGbsyG4q5suS3CNslsHURfM8bQK4oLvHR8LCHEBMRcdFBn87cSvOK6eB1kdGKLA8ymXxZp8='

set pki ca CAcert_Signing_Authority certificate 'MIIG7jCCBNagAwIBAgIBDzANBgkqhkiG9w0BAQsFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0wMzAzMzAxMjI5NDlaFw0zMzAzMjkxMjI5NDlaMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnMIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAziLA4kZ97DYoB1CW8qAzQIxL8TtmPzHlawI229Z89vGIj053NgVBlfkJ8BLPRoZzYLdufujAWGSuzbCtRRcMY/pnCujW0r8+55jE8Ez64AO7NV1sId6eINm6zWYyN3L69wj1x81YyY7nDl7qPv4coRQKFWyGhFtkZip6qUtTefWIonvuLwphK42yfk1WpRPs6tqSnqxEQR5YYGUFZvjARL3LlPdCfgv3ZWiYUQXw8wWRBB0bF4LsyFe7w2t6iPGwcswlWyCR7BYCEo8y6RcYSNDHBS4CMEK4JZwFaz+qOqfrU0j36NK2B5jcG8Y0f3/JHIJ6BVgrCFvzOKKrF11myZjXnhCLotLddJr3cQxyYN/Nb5gznZY0dj4kepKwDpUeb+agRThHqtdB7Uq3EvbXG4OKDy7YCbZZ16oE/9KTfWgu3YtLq1i6L43qlaegw1SJpfvbi1EinbLDvhG+LJGGi5Z4rSDTii8aP8bQUWWHIbEZAWV/RRyH9XzQQUxPKZgh/TMfdQwEUfoZd9vUFBzugcMd9Zi3aQaRIt0AUMyBMawSB3s42mhb5ivUfslfrejrckzzAeVLIL+aplfKkQABi6F1ITe1Yw1nPkZPcCBnzsXWWdsC4PDSy826YreQQejdIOQpvGQpQsgi3Hia/0PsmBsJUUtaWsJx8cTLc6nloQsCAwEAAaOCAX8wggF7MB0GA1UdDgQWBBQWtTIb1Mfz4OaO873SsDrusjkY0TAPBgNVHRMBAf8EBTADAQH/MDQGCWCGSAGG+EIBCAQnFiVodHRwOi8vd3d3LmNhY2VydC5vcmcvaW5kZXgucGhwP2lkPTEwMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzAxBgNVHR8EKjAoMCagJKAihiBodHRwOi8vY3JsLmNhY2VydC5vcmcvcmV2b2tlLmNybDAzBglghkgBhvhCAQQEJhYkVVJJOmh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AuY2FjZXJ0Lm9yZzAfBgNVHSMEGDAWgBQWtTIb1Mfz4OaO873SsDrusjkY0TANBgkqhkiG9w0BAQsFAAOCAgEAR5zXs6IX01JTt7Rq3b+bNRUhbO9vGBMggczo7R0qIh1kdhS6WzcrDoO6PkpuRg0L3qM7YQB6pw2V+ubzF7xl4C0HWltfzPTbzAHdJtjaJQw7QaBlmAYpN2CLB6Jeg8q/1Xpgdw/+IP1GRwdg7xUpReUA482l4MH1kf0W0ad94SuIfNWQHcdLApmno/SUh1bpZyeWrMnlhkGNDKMxCCQXQ360TwFHc8dfEAaq5ry6cZzm1oetrkSviE2qofxvv1VFiQ+9TX3/zkECCsUB/EjPM0lxFBmu9T5Ih+Eqns9ivmrEIQDv9tNyJHuLsDNqbUBal7OoiPZnXk9LH+qb+pLf1ofv5noy5vX2a5OKebHe+0Ex/A7e+G/HuOjVNqhZ9j5Nispfq9zNyOHGWD8ofj8DHwB50L1Xh5H+EbIoga/hJCQnRtxWkHP699T1JpLFYwapgplivF4TFv4fqp0nHTKC1x9gGrIgvuYJl1txIKmxXdfJzgscMzqpabhtHOMXOiwQBpWzyJkofF/w55e0LttZDBkEsilV/vW0CJsPs3eNaQF+iMWscGOkgLFlWsAS3HwyiYLNJo26aqyWPaIdc8E4ck7Sk08WrFrHIK3EHr4n1FZwmLpFAvucKqgl0hr+2jypyh5puA3KksHF3CsUzjMUvzxMhykh9zrMxQAHLBVrGwc='

Please note that when loading the certificate you need to manually strip the -----BEGIN KEY----- and -----END KEY----- tags. Also, the certificate/key needs to be presented in a single line without line breaks (\n), this can be done using the following shell command:

$ tail -n +2 server.key | head -n -1 | tr -d '\n'

After importing the CA certificates we also need to load our CA signed server certificates. The certificate we use is identified as "vyos". 

set pki certificate vyos certificate 'MIIE45s...'
set pki certificate vyos private key 'MIIEvgI...'

After the PKI certs are all set up we can start configuring our IPSec/IKE proposals used for key-exchange end data encryption. The used encryption ciphers and integrity algorithms vary from operating system to operating system. The ones used in this post are validated to work on both Windows 10 and iOS/iPadOS 14.

set vpn ipsec esp-group ESP-RW compression 'disable'
set vpn ipsec esp-group ESP-RW lifetime '3600'
set vpn ipsec esp-group ESP-RW pfs 'disable'
set vpn ipsec esp-group ESP-RW proposal 10 encryption 'aes128gcm128'
set vpn ipsec esp-group ESP-RW proposal 10 hash 'sha256'

set vpn ipsec ike-group IKE-RW key-exchange 'ikev2'
set vpn ipsec ike-group IKE-RW lifetime '7200'
set vpn ipsec ike-group IKE-RW mobike 'enable'
set vpn ipsec ike-group IKE-RW proposal 10 dh-group '14'
set vpn ipsec ike-group IKE-RW proposal 10 encryption 'aes128gcm128'
set vpn ipsec ike-group IKE-RW proposal 10 hash 'sha256'

Every connection/remote-access pool we configure also needs a pool where we can draw our client IP addresses from. We provide one IPv4 and IPv6 pool. Authorized clients will receive an IPv4 address from the 192.0.2.128/25 prefix and an IPv6 address from the 2001:db8:2000::/64 prefix. We can also send some DNS nameservers down to our clients used on their connection.

set vpn ipsec remote-access pool ra-rw-ipv4 name-server '192.0.2.1'
set vpn ipsec remote-access pool ra-rw-ipv4 prefix '192.0.2.128/25'

set vpn ipsec remote-access pool ra-rw-ipv6 name-server '2001:db8:1000::1'
set vpn ipsec remote-access pool ra-rw-ipv6 prefix '2001:db8:2000::/64'

VyOS supports multiple IKEv2 remote-access connections. Every connection can have its dedicated IKE/ESP ciphers, certificates or local listen address for e.g. inbound load balancing.

We configure a new connection named "rw" for road-warrior, that identifies itself as '192.0.2.1' to the clients and uses the "vyos" certificate signed by the CAcert_Class3_Root intermediate CA.  We select our previously specified IKE/ESP groups and also link the IP address pool to draw addresses from.

set vpn ipsec remote-access connection rw authentication id '192.0.2.1'
set vpn ipsec remote-access connection rw authentication server-mode 'x509'
set vpn ipsec remote-access connection rw authentication x509 ca-certificate 'CAcert_Class_3_Root'
set vpn ipsec remote-access connection rw authentication x509 certificate 'vyos'
set vpn ipsec remote-access connection rw esp-group 'ESP-RW'
set vpn ipsec remote-access connection rw ike-group 'IKE-RW'
set vpn ipsec remote-access connection rw local-address '192.0.2.1'
set vpn ipsec remote-access connection rw pool 'ra-rw-ipv4'
set vpn ipsec remote-access connection rw pool 'ra-rw-ipv6'

VyOS also supports (currently) two different modes of authentication, local and RADIUS.

To create a new local user named "vyos" with a password of "vyos" use the following commands.

set vpn ipsec remote-access connection rw authentication client-mode 'eap-mschapv2'
set vpn ipsec remote-access connection rw authentication local-users username vyos password 'vyos'

If you feel better forwarding all authentication requests to your enterprises' RADIUS server, use the commands below.

set vpn ipsec remote-access connection rw authentication client-mode 'eap-radius'
set vpn ipsec remote-access radius server 192.0.2.2 key 'secret'

Client Configuration

Configuring VyOS to act as your IPSec access concentrator is one thing, but you also need to setup your client connecting to the server so they can talk to the IPSec gateway.

Microsoft Windows (10+)

Windows 10 does not allow a user to choose the integrity and encryption ciphers using the GUI and it uses some older proposals by default. A user can only change the proposals on the client side by configuring the IPSec connection profile via PowerShell. Luckily VyOS comes with a nice IPSec profile generator.

We now generate a connection profile used by Windows clients that will connect to the "rw" connection on our VyOS server on the VPN servers IP address/fqdn vpn.vyos.net.

Note: Windows expects the server name to be also used in the server's certificate common name, so it's best to use this DNS name for your VPN connection.

vyos@vyos:~$ generate ipsec profile windows-remote-access rw remote vpn.vyos.net


==== <snip> ====
Add-VpnConnection -Name "VyOS IKEv2 VPN" -ServerAddress "vpn.vyos.net" -TunnelType "Ikev2"

Set-VpnConnectionIPsecConfiguration -ConnectionName "VyOS IKEv2 VPN" -AuthenticationTransformConstants GCMAES128 -CipherTransformConstants GCMAES128 -EncryptionMethod GCMAES128 -IntegrityCheckMethod SHA256128 -PfsGroup None -DHGroup "Group14" -PassThru -Force
==== </snip> ====

As both Microsoft Windows and Apple iOS/iPadOS only support a certain set of encryption ciphers and integrity algorithms we will validate the configured IKE/ESP proposals and only list the compatible ones to the user — if multiple are defined. If there are no matching proposals found — we can not generate a profile for you.

When first connecting to the new VPN the user is prompted to enter proper credentials.

Apple iOS/iPadOS (14.2+)

Like on Microsoft Windows, Apple iOS/iPadOS out of the box does not expose all available VPN options via the device GUI.

If you want, need, and should use more advanced encryption ciphers (default is still 3DES) you need to provision your device using a so-called "Device Profile". A profile is a simple text file containing XML nodes with a .mobileconfig file extension that can be sent and opened on any device from an E-Mail.

Profile generation happens from the operational level and is as simple as issuing the following command to create a profile to connect to the IKEv2 access server at vpn.vyos.net with the configuration for the "rw" remote-access connection group.

Note: iOS/iPadOS expects the server name to be also used in the server's certificate common name, so it's best to use this DNS name for your VPN connection.

vyos@vyos:~$ generate ipsec profile ios-remote-access rw remote vpn.vyos.net

==== <snip> ====
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
</plist>
==== </snip> ====

In the end, an XML structure is generated which can be saved as vyos.mobileconfig and sent to the device by E-Mail where it later can be imported.

During profile import, the user is asked to enter its IPSec credentials (username and password) which is stored on the mobile. If a custom CA is used that is not present on your mobile — no problem — we will always embed the CA certificate into the profile so that you won't experience any certificate issues.

Recap

I hope you enjoyed reading about yet another new feature in the 1.4 release cycle. As this is still a very new feature added in VyOS 1.4 please expect all kinds of buggy behavior. We are more than happy for every user testing this implementation and sending us feedback, bugfixes, or updates to our more than lacking IPSec VPN documentation.

I once more want to say thank you GeFoekoM e.V. for providing me with VMs and subnets for my lab setups and Simon Arthur for his contributions in the IPSec and PKI field!

Get VyOS 1.4 nightly builds here