28.01.2022, aktualisiert am 02.10.2024

18082

IKEv2 VPN server for Windows and Apple clients on Raspberry Pi

Preamble

The following tutorial did not claim to be fully comprehensive and the Raspberry Pi should be taken here as an example. It works of course on every Linux distribution as well as on OpenWRT. Its a quick framework to show the basic functions of an IPsec IKEv2 VPN server and intentionally supports the onboard VPN clients in all OSes. The simple reason is they are always included anywhere and there is no need to install any additional 3rd party VPN clients or protocolls as its the case with e.g. Wireguard or OpenVPN.
Therefore it has a close relationship with the forum pfSense / OPNsense Firewall IKEv2 and L2TP VPN tutorials (see further links at the bottom). More or less every Unix based appliance uses the charon IPsec daemon as a foundation for IPsec.

Using IKEv2 onboard VPN clients on Windows and Apple always requires a server certificate. IKEv2 VPN clients use it to check the authenticity of the target VPN server to prevent being spoofed by a fake server.
It is not within the scope of this tutorial to be a fully basic knowledge tutorial for IPsec and PKI. The usage of a Raspberry Pi with Debian based Linux is only an example. Of course can this setup also be used with "bigger" hardware or VMs and different distros as well as with the famous free OpenWRT router firmware (strongswan- swanctl package).
A bit of Linux CLI knowledge and some basic network and PKI knowledge would be helpful to get familiar with the following configuration steps
A basic Linux machine with SSH access (e.g. PuTTY) is the starting point.

VPN server configuration

StrongSwan swanctl is a new portable command line utility for the IKE daemon charon. Its included since 5.2.0 and will replace the old starter syntax on a long term perspective.
To make Linux and here the Raspberry Pi IPsec capable, additional packages need to be installed with the APT package manager. This requires root user access rights (sudo su):

apt install strongswan strongswan-pki libstrongswan-extra-plugins charon-systemd libcharon-extra-plugins

Also IPv4 forwarding (routing) needs to be activated and can be done editing the file (nano editor) /etc/sysctl.conf and changing the line

 # Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1 

by removing the comment sign "#" at the beginning net.ipv4.ip_forward=1 and reboot the RasPi after the file was saved.
If that step is completed continue with the CA and certificate setup...

❗️FQDN domain names are used here with https://nip.io notation as a placeholder for real FQDNs or DDNS domain names. nip.io usage is very conveniant also in local lab setup, cause it makes the usage of DNS names very easy without existing (D)DNS hostnames or installing a DNS server.

CA setup and server certificate with StrongSwan PKI

As mentioned above, all the onboard VPN clients did a server certificate check to proof the servers authenticity. Hence it adds more security to the VPN and needs a small PKI infrastructure PKI. A CA is in a figurative sense an authority who issues an identiy card with a stamp (certificate) which can then be checked by the clients.
If there is an existing CA the only requirement is to issue another server certificate with that CA for the new RasPi server.
If no CA is active just follow the next steps to create one.

CA setup using StrongSwan PKI commands:

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/raspica-key.pem

pki --self --ca --lifetime 3650 --in /etc/swanctl/private/raspica-key.pem --type rsa --dn "CN=RasPi CA" --outform pem > /etc/swanctl/x509ca/raspica-cert.pem   

⚠️ The last, the file raspica-cert.pem, is the "authority" which needs to be exported into the VPN clients and should be saved on USB Stick etc.. Details can be found in the local pfSense / OPNsense Firewall VPN tutorial. (see further link section at the bottom)

Setup server certificate:

pki --gen --type rsa --size 2048 --outform pem > /etc/swanctl/private/server-key.pem

pki --pub --in /etc/swanctl/private/server-key.pem --type rsa | pki --issue --lifetime 1825 --cacert /etc/swanctl/x509ca/raspica-cert.pem --cakey /etc/swanctl/private/raspica-key.pem --dn "CN=0a630187.nip.io" --san 0a630187.nip.io --flag serverAuth --flag ikeIntermediate --outform pem > /etc/swanctl/x509/server-cert.pem  

(Tip: It's useful to edit these commands in a text editor first and customize them to personal needs like filenames, timeframes etc.

Using an existing CA

If an exiting CA is active, the only need is to create a new, additional server certificate and export it together with the CA.
The following example shows it with a working CA on a pfSense or OPNsense firewall in the "Cert Manager" or "Trust" menu:
CA certificate and key export: (Menu "CA")

Server certificate and key export:: (Menu "Certificates")
Server cerificate is too exported with the "sun" icon (Mouseover) and the corresponting key with the "key" icon like with the above CA.

The generated certificate for an external server can be safely erased afterwards from the CA, cause it is only needed on the VPN Server itself.
Recommendation is to keep it, cause the validation timeframe can easily be extend without generating a new certificate.
The exported certificate and key files can be moved to the server with a usb stick or via network copy using SCP tools like (e.g. WinSCP) or with just copy and paste.
They need to be copied into the following server directories:

All key files into: /etc/swanctl/private
CA certificate into: /etc/swanctl/x509ca (optional)
Server certificate into: /etc/swanctl/x509

If all these files were created using the above StrongSwan PKI commands, the correct directories can be seen in the specific commands as well.

All these certificates and keys can of course be generated with other tools of own choice, like OpenSSL or the well known XCA suite as well.
The VPN enddevices (clients) only need the CA certificate to be imported under their trusted root certificates.

StrongSwan configuration

The general StrongSwan configuration is placed in the directory /etc/swanctl/conf.d and needs to have a .conf suffix like vpn-server.conf.
This can quickly be done with a simple texteditor like nano. A single command like nano /etc/swanctl/conf.d/vpn-server.conf creates the file and the following configuration can be inserted with simply cut and paste. Never forget to save and exit with <ctrl o> und <ctrl x> (nano) !
It is useful to perhaps replace the example settings used here with individual ones.

Replace PSK passwords with secret ones !
Internal example VPN client network: 172.25.25.0 /24
Local IP address on eth0 interface: 10.99.1.135 (DNS example: 0a630187.nip.io)
DNS server IPs propagated automatically to clients at dialin: 172.16.7.254 and 10.99.1.254
2 VPN example users with username/passwd combination user/test123 and user2/user2
Usernames/Passwords can not be used twice. (No multiple login with the same credentials, Parameter unique = replace). It can be allowed by simply omitting this parameter.

connections {
  ikev2-mobile-defaults {
    unique = replace
    version = 2
    proposals = aes256-sha512-modp2048,aes256-sha256-ecp256,aes256-sha256-modp2048,aes256-sha256-modp1024
    send_cert = always
    pools = pool-ipv4
    local_addrs = 10.99.1.135
    remote_addrs = 0.0.0.0/0,::/0
    local {
      auth = pubkey
      certs = server-cert.pem
      id = fqdn:0a630187.nip.io
    }
    remote {
        id = %any
        auth = eap-mschapv2
        eap_id = %any
    }
    children {
      ikev2-mobile {
        local_ts = 0.0.0.0/0
        esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1
      }
    }
  }
}
pools {
  pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 9.9.9.9
  }
}
secrets {
 eap-1 {
     id = user
     secret = "test123"  
     }
 eap-2 {
     id = user2
     secret = "user2"  
     }
} 

(Missing "-modpXXXX" in phase 2 cryptos (children, proposals) solves a problem with instable connections on Apple IKEv2 clients by recommended disabling of PFS. See here for details!)

When all the certificate and key files are stored in their correct directories the configuration can now be activated with:
swanctl -q
(It happens also automatically after every reboot) The daemon acknowledges this with

root@raspi:/home/pi# swanctl -q
loaded certificate from '/etc/swanctl/x509/RasPiServer.crt'
loaded certificate from '/etc/swanctl/x509ca/pfsenseCA.crt'
loaded RSA key from '/etc/swanctl/private/RasPiServer.key'
loaded RSA key from '/etc/swanctl/private/pfsenseCA.key'
loaded eap secret 'eap-1'
loaded eap secret 'eap-2'
no authorities found, 0 unloaded
loaded pool 'pool-ipv4'
successfully loaded 1 pools, 0 unloaded
loaded connection 'ikev2-mobile-defaults'
successfully loaded 1 connections, 0 unloaded 

Loopback interface with second IP

As an option it makes sense to set a second IP on the server loopback interface lo especially when using one armed vServers. The second IP makes it possible to ping the server from active VPN clients to verify the connection. And, more important, it can also serve as a tunnel keepalive IP for routers and firewalls or can be used for local service forwarding. (See later section with Nginx proxy)
For the second lo interface address a new unused network segment must be used. In this example 172.25.24.1 is taken, cause it could later be set with a /23 prefix in the VPN peer setup to include both the VPN client address pool 172.25.25.0/24 and the second lo address. (172.25.24.0/23 includes all addresses from 72.25.24.1 to 72.25.25.254)
ip addr add 172.25.24.1/32 dev lo adds it temporarly. (Check with ip a). To make it permanent to survive a reboot the IP should be added in /etc/network/interfaces:
.# The loopback network interface
auto lo
iface lo inet loopback
iface lo inet static
address 172.25.24.1
netmask 255.255.255.255

Further troubleshooting can be done by observing the live log with swanctl -T. (Stop with <ctrl c>) or ip xfrm state.
With every configuration change, a new swanctl -q is mandatory to activate the changes !
With these steps the server is ready and next is the VPN client setup...

Windows, Apple and Android VPN client configuration

Usually Windows, Apple and all smartphones/tablets have 2 onboard VPN clients. One based on the L2TP VPN protocol and one for native IPsec in tunnel mode with IKEv2. Here we deal with the latter one.
One caveat is the Microsoft VPN client, which uses weak ciphers in the default settings. When a higher security is required, tweaking with Powershell or a Windows registry setup is mandatory here.
Apple uses stronger default security in their clients (AES256,SHA256,DH14) and is not affected. Btw. often the reason why Windows can connect but not Apple due to a higher cipher request which fail in the VPN client negotiation.
In a Windows setup that supports the default, out-of-the-box settings without changes, SHA1 Hashing and DH Group 2 support need to be activated. This can be seen in the above StrongSwan configuration setting unter (proposals = ...).

Take note that ALL clients need to have the CA root certificate be imported first !
The import into the trusted root certificates folder can be done under Windows with a simple doubleclick or via the certificate manager. Mac OS a doubleclick and set the certificate to always trust.
On mobile devices the easiest way is to send it via email attachment or USB memory stick and doubleclick it. More details for Apple devices can be found in the firewall tutorial.

Windows VPN client

⚠️ 21H2 requires patch here !

The Windows client setup via GUI is pretty easy and can be seen here:

⚠️ Make sure to use the FQDN as hostname if it is used in the generated server certificate for the server! ("--dn "CN=0a630187.nip.io" --san 0a630187.nip.io")
It must match to what is configured under "id = fqdn:0a630187.nip.io" in the above Strongswan config!
(FQDN is automatically send as remote ID by the Windows client and therefore must match the "local ID" settings in the Strongswan config and server certificate (SAN)!

Type IKEv2, Username/Password. Automatic deployment of username/passwd can be set with the checkmark in the VPN adapter attributes:

Also if the VPN client should use the tunnel for his default gateway (Gateway Redirect) or should only reach the remote networks (Split Tunneling).

Windows client: Increasing VPN security settings

The following topic is only for users who need to increase their Windows VPN client security.
If the defaults are sufficient this step can be ignored.

The easiest option is to tweak the specific VPN connection with a Powershell command:
Set-VpnConnectionIPsecConfiguration -ConnectionName "RasPi" -AuthenticationTransformConstants None -CipherTransformConstants AES256 -EncryptionMethod AES256 -IntegrityCheckMethod SHA256 -DHGroup Group14 -PfsGroup None -PassThru -AllUserConnection
Note that the parameter -ConnectionName "RasPi" needs to match exactly the VPN connection name ! (Here the firewall turorial has more information for the VPN customization via Powershell).

Another alternative to gain higher VPN security is the Windows Registry:

1.) Edit Registry with regedit or use GPO: HKLM\SYSTEM\CurrentControlSet\Services\RasMan\Parameters\
2.) Create a new DWORD value: NegotiateDH2048_AES256
3.) DWORD value to 1 or 2

Table of DWORD values:

⚠️ If the Windows Registry has this VPN setting (DWORD), Windows will always use these stronger ciphers ! Hence it could effect existing VPN connections which perhaps use weaker or default ciphers !
The Powershell option is more flexible here, cause it can individually be configured on a per connection basis.

Apple VPN client

Apple uses strong ciphers by default. Here just the login credentials and the certificate DN or --san name (remote ID) are needed for the VPN access:

Android VPN client

Recommendation here is to always use the onboard IKEv2 VPN client. Due to different Android vendors the VPN client features are not always the same like under iOS. Best bet is to use the free Strongswan App from the Google Play store which works rock solid. No wonder, cause there is Strongswan on the other end too.
A detailed Android client setup can be found here (German)

Mobile enddevices

As mentioned before, certificate and key files can be send by email attachment or USB. In case a larger amount of Apple mobile devices need to be configured the Apple Configurator 2 eases this step with a simple template which can be created and distributed automatically.

Jumphost setup with vServer and VPN router

One exampe of a useful, practical live setup is a jumphost design for DS-Lite customer connections.
Due to DS-Lite there is no possibility to realize IPv4 connection from remote to a DS-Lite connected router oder firewall. All those connections stuck and are blocked at the provider CGN gateway. IPv6 is of course not affected in most cases. DS-Lite/CGN is related to IPv4 only !
As a workaround a home IPsec VPN router like the popular AVM FritzBox and all others with onboard IPsec VPN capabilities, can establish a VPN connection with IPv4 to a public jumphost (vServer with StrongSwan) to connect the local LAN network. From the "other side" this server is conntected via IPv4 from the VPN clients. The server acts more or less as a relay station to access the local LAN network from remote and avoid DS-Lite IPv4 obstacles.

That way DS-Lite users can get rid of the CGN limitations or unsafe and dangerous public VPN providers.
Just to make sure: This design is ONLY useful for private home or company connections based on DS-Lite ! All (normal) dual-stack connections with a public IPv4 on the WAN/xDSL router port can of course use the simple design above.

StrongSwan Jumphost configuration

The Strongswan configuration needs to be modified for this setup by adding the FritzBox connection. (For the AVM FritzBox settings special thanks to @colinardo !)

Replace PSKs with safe ones !
Replace vServer IP <server_hoster_ip> and FQDN <server_FQDN> with personal IP and FQDN values
In case the AVM FritzBox uses a different local LAN as 192.168.178.0/24 it needs to be changed under "remote_ts = x.y.z.h"

As described above, the configuration file e.g. jumphost.conf is placed in the directory /etc/swanctl/conf.d and looks like the following:

connections {
fritzbox {
        local_addrs = <vserver_ip_address>
        remote_addrs = 0.0.0.0/0
        local {
            auth = psk
            id = <vserver_ip_address>
        }
        remote {
            auth = psk
            id = keyid:strongswan@fritz.box
        }
        children {
            net {
                local_ts = 172.25.24.0/23
                remote_ts = 192.168.178.0/24
                esp_proposals = aes256-sha512-modp2048,aes256-sha256-modp2048,aes256-sha1-modp1024
            }
        }
        version = 1
        proposals = aes256-sha512-modp2048,aes256-sha512-modp1024
    }

  ikev2-mobile-defaults {
    unique = replace
    version = 2
    proposals = aes256-sha512-modp2048,vpn-server.conf,aes256-sha256-modp2048,aes256-sha256-modp1024
    send_cert = always
    pools = pool-ipv4
    local_addrs = <vserver_ip_address>
    remote_addrs = 0.0.0.0/0,::/0
    local {
      auth = pubkey
      certs = server-cert.pem
      id = fqdn:<server_FQDN>
    }
    remote {
        id = %any
        auth = eap-mschapv2
        eap_id = %any
    }
    children {
      ikev2-mobile {
        local_ts = 0.0.0.0/0
        esp_proposals = aes256-sha512,aes256-sha384,aes256-sha256,aes256-sha1
      }
    }
  }
}
pools {
  pool-ipv4 {
    addrs = 172.25.25.0/24
    dns = 9.9.9.9,192.168.178.1
  }
}
secrets {
 eap-1 {
     id = user1
     secret = "test123"  
     }
 eap-2 {
     id = user2
     secret = "user2"  
     }
 ike-3 {
      id = keyid:strongswan@fritz.box
      secret = "test1234"  
     }
} 

(local_ts = 172.25.24.0/23 with larger subnet mask shows that the FritzBox tunnel transfers both: pool and lo networks!)

Hint:
In case of multiple VPN router / firewall peers this combined configuartion file can be separated into two config files like client-vpn-server.conf and fritzbox.conf. Depending on personal taste this may ease the management of either the client vpn part and the router vpn peering.
Strongswan will automatically load all .conf config files which are located inside the .../conf.d/ directory on startup.

FritzBox VPN configuration file

The corresponding FritzBox VPN configuration file looks like this. Its a simple text file editable with e.g. Notepad++ and can be loaded into the FritzBox over the GUI. (Internet -> Freigabe -> VPN)

Replace <server_hoster_ip> with the live vServer IP or FQDN

vpncfg {
        connections {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "StrongSwan";  
                always_renew = yes;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = <vserver_ip_address>;
                remote_virtualip = 0.0.0.0;
                keepalive_ip = 172.25.24.1;
			localid {
                        key_id = "strongswan@fritz.box";  
                }
                        remoteid {
                        ipaddr = <server_hoster_ip>;
                }
                mode = phase1_mode_idp;
                phase1ss = "LT8h/all/all/all";  
                keytype = connkeytype_pre_shared;
                key = "test1234";  
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 172.25.24.0;
                                mask = 255.255.254.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";  
                accesslist = "permit ip any 172.25.24.0 255.255.254.0";  
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500",   
                            "udp 0.0.0.0:4500 0.0.0.0:4500";  
} 

(For further details regarding FritzBox IPsec crypto profiles see HERE)
⚠️ AVM Firmware 8.0 do not support SHA512 anymore with DH Group2 but only DH Group14 (2048). Tutorial is updated for this to support all models.

Client VPN and NAT

If VPN clients are active in the above jumphost design they can work on all remote VPN networks but lose their Internet connection. Windows shows this with the taskbar globe symbol while the VPN is active.
This is obvious, cause VPN clients use their pool RFC 1918 private IP address (172.25.25.0/24) as source address to access the Internet via the vServer interface. RFC 1918 are non routed networks in the Internet therefore providers will instantly drop that traffic which finally results in a connection loss to all Internet targets.

The solution is quite simple in masquerading all VPN client traffic to the Internet on the vServer except the VPN tunneltraffic.
Due to the fact that modern distros only use the new nftables firewall framework to control the system firewall a standard nft ruleset is shown here.
A simple ruleset at the end of the etc/nftables.conf file achieves this.
The nft firewall needs to be restarted with systemctl restart nftables after this change and the active ruleset can be displayed with nft list ruleset.

table ip nat {

        define VPN_NETS = {
        192.168.178.0/24
        }
        # masquerade VPN client pakets to Internet except VPN networks
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname eth0 ip daddr $VPN_NETS accept
                ip saddr 172.25.25.0/24 oif eth0 masquerade
        }
} 

The variable VPN_NETS defines here the remote reachable Fritzbox (router) LAN addresses and can be extended by a wider subnet mask or by adding further comma separated network addresses. Interface eth0 must be changed into the used one shown by ip a command.
A systemctl restart nftables restarts the vServer firewall with the new rule and VPN clients have Internet access afterwards. Active ruleset can be checked with nft list ruleset.

Port Forwarding

A VPN should always be the first choice for a secure access to a home or company network or its content. But for example operating an own, private Cloud with Nextcloud or providing content from a local hosted webserver to the public can be a worthwhile reason to use port forwarding on top.
The following picture shows this scenario with the above jumphost setup as the foundation.

The blue dotted line symbolizes this direct webserver access over the jumphost as an example.
There are 2 options for a technical solution:

Port forwarding with source NAT using the vServer local firewall (nftables)
Access using a proxy like Nginx

First option using detailed NAT rules is overall not an easy task and it bears a risk for the vServer security.
The proxy solution is more secure and easier to configure for beginners.
Another advantage of the Nginx proxy is that it can not only forward webports (TCP 80, 443) but also other ports like SSH etc.
apt install nginx installs the Nginx proxy.

The following easy configuration example shows a port translation to avoid exposing the popular TCP 80 (HTTP) port to the public and port scanners.
The vServer can be accessed with TCP 58080 and forwards the traffic to the local webserver with TCP 80. http://<ip_adresse_hostname>:58080
In case TCP 443 should be forwarded the Listen ports should be changed into "443" and "proxy_pass http:/ /192.168.188.222:443;" too. Same for TCP 80.
The simple config under /etc/nginx/sites-available/default should look like this:

# Default server configuration
# Reverse proxy any port to other internal hosts
server {
        listen 58080;
        listen [::]:58080;

        location / {
                proxy_bind 172.25.24.1;
                proxy_pass http://192.168.188.222:80;
                include proxy_params;
                }
} 

After a configuration change the proxy needs to be restarted with systemctl restart nginx to activate the new settings.
The Nginx reverse proxy is very powerful with flexible config options. The description of all possible options is beyond the scope of this tutorial.

Secure port forwarding with nftables firewall

To let only wanted traffic pass through the vServer ingress port it makes sense to secure it also with the nftables firewall by customizing the startup config under /etc/nftables.conf. The complete ruleset looks like this:

table inet filter {
        chain input {
                type filter hook input priority 0; policy drop;
                # accept traffic on localhost Interface
                iif lo accept

                # accept traffic from vServer
                ct state established,related accept

                # accept ICMP types
                ip protocol icmp icmp type {time-exceeded, parameter-problem, destination-unreachable } accept
                # accept inbound traffic for system services, 22=SSH, 443=HTTPS, 58080=WebProxy
                tcp dport { ssh, https, 58080 } ct state new accept
	        # accept IPsec VPN traffic
                udp dport { isakmp, ipsec-nat-t } accept 
                ip protocol esp accept 
                # allow VPN Tunneltraffic
                meta ipsec exists accept
                # accept IPv6 neighbour discovery, otherwise no IPv6 connectivity
                ip6 nexthdr icmpv6 icmpv6 type { nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert } accept

                # logging and counting blocked traffic. (uncomment for troubleshooting, monitoring)
                # log prefix "[nftables]Denied: " counter drop 
                # counts blocked traffic
                counter drop
        }
        chain forward {
                type filter hook forward priority 0;
        }
        chain output {
                type filter hook output priority 0;
        }
}

table ip nat {

        define VPN_NETS = {
        192.168.178.0/24
        }
        # masquerade VPN Clients to Internet except VPN tunnel
        chain postrouting {
                type nat hook postrouting priority 100; policy accept;
                oifname ens192 ip daddr $VPN_NETS accept
                ip saddr 172.25.25.0/28 oif ens192 masquerade
        }
} 