strongSwan is a VPN server that allows a connection over an insecure network, such as the internet, to access a secure private network. The connection is encrypted and authenticated for confidentiality and to prevent tampering of the data. It allows the following:

Secure internet browsing, for example, over an insecure, open Wi-Fi connection.
Allows full access to your internal network securely over an insecure network.

We will be setting up the connection to allow a connection from this server to a Windows 10 1809 (October 2018 Update) client, although this should still work with later versions. Windows 10 1809 supports the Internet Key Exchange v2 (IKEv2) protocol, which is a modern VPN protocol and has some provisions for working over the internet, such as MOBIKE. This helps in situations where the internet connection may be unreliable and has to reconnect. Windows 10 1809 supports the use of the following modern ciphers:

Certificate authentication.
ECDSA certificates (256 and 384-bit keys).
ESP supports AES-GCM 128 & 256-bit which does both encryption and authentication.

We will be configuring our connection to use ECDSA 384-bit certificates and AES256-GCM encryption/authentication, currently the strongest supported settings (at least on Windows).

Note that Windows initially uses VERY weak encryption (3DES) and authentication schemes by default (from the Windows 2000 era) so it is very important to set up the connection correctly and not use the default Windows settings. strongSwan => 5.6.1 has deprecated the default Windows scheme by disabling 3DES and MODP-1024 as these are insecure. As such, Windows will not just work "out of the box" any more and requires configuration to use stronger ciphers.

strongSwan 5.6.3 in openSUSE Tumbleweed (8th April 2019) was used as the basis for this guide.

We will be using the modern strongSwan VICI back-end, not the old stroke back-end. strongSwan is starting to phase the stroke back-end out.

Commands under Windows with the icon may need administrator credentials to complete them.

Packages needed

Make sure the following packages are installed:

strongswan
openssl

These packages are usually installed by default in an normal setup. If installing, allow any dependencies the packages asks for.

IKEv2 requires port 500 and 4500 to be port forwarded/opened in the firewall/router.

Remove the following packages:

firewalld

As this is a system package, restart the computer afterwards. We will be using iptables to manipulate the network traffic, not firewalld as we don't run a firewall at the server level, it is run further up. It can be configured through the SuSEFirewall2 but we do not use this so additional research is required if you use this setup. The package may need to be marked as Taboo in Tumbleweed so that it doesn't try to reinstall it later.

Important note

openSUSE has not implemented all of the modern VICI backend yet. As such, to run the service, strongswan can be enabled at startup. However, the swanctl --load-all needs to be loaded manually on each reboot. This notice will be removed when the strongswan-swanctl and charon-systemd packages are added.

Creating the certificates

Certificates when created correctly are the strongest possible way to authenticate. IKEv2 does allow the use of a Username/Pre-shared Key (PSK) but this is a very weak method and can be easily brute-forced without further provisions.

We will be creating modern, elliptic curve certificates. These use very short keys (384-bits) compared to RSA keys (4096-bits) but provide the equivalent security.

Initial setup

As most of this work will require root privileges, open a Terminal and elevate to root by typing su. Type the root user password.
Create a working directory to create all the certificates and keys in. A good place would be a separate folder in the home directory. I usually use /home/'user'/Documents/strongswan.
Create the correct directories in /etc/swanctl as these are not created by default at the moment. Use the following:

cd /etc/swanctl
mkdir x509
mkdir x509ca
mkdir ecdsa

Creating a self-signed certificate authority (CA)

To sign out certificates we will be creating, we first need to create a CA certificate.

Make sure you are in the correct directory above.

Generate a private key for the CA:

pki --gen --type ecdsa --size 384 --outform pem > caKey.pem

Change the permissions of the private key, so that only root can access it:
```
chmod 600 private/caKey.pem
```

Now we have the private key, generate the CA certificate:

pki --self --ca --lifetime 3650 --in caKey.pem --dn "C=GB, O=strongSwan, CN=strongSwan CA" --outform pem > caCert.pem

You now have a self-signed CA certificate, ready to sign any certificates to be used by the VPN server.

IMPORTANT: The private key, created in the private folder must NEVER be disclosed. If anybody were to obtain access to this key, they would be able to create any certificate they like, impersonate you and connect to the server. As this is the CA certificate, a compromise would require a whole new CA key, certificate and any certificates signed by the old, compromised CA. KEEP THIS SAFE. It would be advisable to keep this on a memory stick, away from the server, once done until it is needed in the future to sign more certificates.

Creating a certificate for the server

Make sure you are still in the correct directory.

Generate a private key for the certificate:

pki --gen --type ecdsa --size 384 --outform pem > serverKey.pem

Change the permissions of the private key, so that only root can access it:
```
chmod 600 serverKey.pem
```

Now we have the private key, generate the server certificate:

pki --issue --in serverKey.pem --type priv --cacert caCert.der --cakey caKey.der --dn "C=GB, O=strongSwan, CN=thinkserver.freddythechick.net" --san "thinkserver.freddythechick.net" --flag serverAuth --flag ikeIntermediate --lifetime 1825 --outform pem > serverVCert.pem

The certificate created will be used to authenticate the VPN server. Only one needs creating.

IMPORTANT NOTES

When customising to fit your server, certain parts of the server certificate generation must be done correctly for Windows to allow the certificate to be used. If not done correctly, Windows will refuse to connect. It is advisable to make sure these are correct in the first place to avoid errors further down the line and painstaking troubleshooting.

The Common Name (CN) part of the Distinguishable Name (DN) MUST be the DNS resolvable name you will be using to connect to the VPN server from Windows.
The SAN MUST also be the DNS resolvable name you will be using to connect to the VPN server from Windows. It MUST also match the CN from the DN.
It MUST contain the serverAuth flag. The ikeIntermediate is included for compatibility with MacOS and doesn't affect a Windows installation so is safe to add.

Creating a certificate for clients

Each client that needs to connect to the server requires a certificate to be generated for it.

Make sure you are still in the correct directory.

Generate a private key for the certificate:

ipsec pki --gen --type ecdsa --size 384 --outform pem > client1Key.pem

Change the permissions of the private key, so that only root can access it:
```
chmod 600 client1Key.pem
```

Now we have the private key, generate the client certificate:

pki --issue --in client1Key.der --type priv --cacert caCert.der --cakey caKey.der --dn "C=GB, O=strongSwan, CN=client1.freddythechick.net" --san "client1.freddythechick.net" --lifetime 1825 --outform pem> client1Cert.pem

The CN in the DN this time can be anything for the Windows client. No flags are required.

One of these must be created for each client you would like to connect to the server. Keep the CA key secure as this will be needed each time you want to sign a client certificate.

Packaging the required certificates and keys for Windows

All the keys and certificates required for the connection can be packaged into a convenient PKCS#12 package, to allow for easy installation on Windows.

Make sure you are still in the correct directory.

Use OpenSSL to create the PKCS#12 package:

openssl pkcs12 -in client1Cert.pem -inkey client1Key.pem -certfile caCert.pem -export -out client1.p12

Type a password you will remember when asked. This will protect the private key while it is in transit.
Retype the password you just typed.

The .p12 file can then be copied to the Windows machine that it is to be installed on.

Configuring strongSwan

Configuration is carried out in /etc/swanctl/swanctl.conf. These basic code snippets will be enough to get the VPN tunnel working, but can be tweaked and configured to your requirements.

Copying the certificates to the correct places

As the certificates are now generated, the certificates need to be copied to the correct places for strongSwan to find them. If they are moved to the correct places, strongSwan will search the folders and load everything it finds in the folders, needing no further configuration to find them. I would copy them as oppose to moving them, as you will have a backup copy where you stored them, should you need to start fresh. Don't forget the trailing / when copying or it will copy it to this name rather than the folder.

Copy serverCert.pem to /etc/swanctl/x509/:

cp serverCert.pem /etc/swanctl/x509/

Copy serverKey.pem to /etc/swanctl/ecdsa/:

cp serverKey.pem /etc/swanctl/ecdsa/

Copy caCert.pem to /etc/swanctl/x509ca/:

cp caCert.pem /etc/swanctl/x509ca/

That is all that needs to be copied to make the server function. DO NOT copy the CA key or any client certificates or keys! The CA key must be kept secure and away from the server and is only needed when signing new client certificates. Client certificates and keys are only needed on the clients that will be connecting to this server and are not needed by the server. Client certificates and keys would only be needed by StrongSwan if you were using this computer to connect to another server.

`/etc/swanctl/swanctl.conf`

connections {

  windows {
     local_addrs = 192.168.1.9
     pools = primary-ipv4

     local {
        auth = pubkey
        id = thinkserver.freddythechick.net
     }

     remote {
        auth = pubkey
     }

     children {
        net {
           local_ts  = 0.0.0.0/0
           updown = /usr/lib/ipsec/_updown iptables
           esp_proposals = aes256gcm16-ecp384
        }
     }
     version = 2
     proposals = aes256gcm16-sha384-ecp384
  }
}

pools {
    primary-ipv4 {
        addrs = 10.1.0.0/16
        }
}

Loading the new settings

Once strongSwan is configured, the settings need loading into the VICI back-end. This is done by typing:

swanctl --load-all

You should get an output similar to the following:

loaded certificate from '/etc/swanctl/x509/serverCert.der'
loaded certificate from '/etc/swanctl/x509ca/caCert.der'
opening directory '/etc/swanctl/x509ocsp' failed: No such file or directory
opening directory '/etc/swanctl/x509aa' failed: No such file or directory
opening directory '/etc/swanctl/x509ac' failed: No such file or directory
opening directory '/etc/swanctl/x509crl' failed: No such file or directory
opening directory '/etc/swanctl/pubkey' failed: No such file or directory
opening directory '/etc/swanctl/private' failed: No such file or directory
opening directory '/etc/swanctl/rsa' failed: No such file or directory
loaded ecdsa key from '/etc/swanctl/ecdsa/serverKey.der'
opening directory '/etc/swanctl/bliss' failed: No such file or directory
opening directory '/etc/swanctl/pkcs8' failed: No such file or directory
opening directory '/etc/swanctl/pkcs12' failed: No such file or directory
no authorities found, 0 unloaded
loaded pool 'primary-ipv4'
successfully loaded 1 pools, 0 unloaded
loaded connection 'windows'
successfully loaded 1 connections, 0 unloaded

Ignore any failed directories. We do not use these in this configuration. You will be checking the files in the x509, x509ca and ecdsa files have loaded correctly, as they have above. You should also have 1 pool and 1 connection at this point.

Configuring `iptables`

So that the packets are routed to the correct place, iptables should be configured or no traffic will flow through the tunnel. In this case, we are forwarding all traffic to/from the tunnel. First, we need some information to correctly configure iptables

Find out the name of the network interface under Linux that you are using for the tunnel. This can be done by typing:

ip a

This returns all the network cards on the computer like this:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.0/24 brd 192.168.1.255 scope global eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::0000:0000:0000:0000/64 scope link
       valid_lft forever preferred_lft forever

In this case, we are using eth1. Remember this for later.
Look in the pool section we created earlier in /etc/swanctl/swanctl.conf. In this setup it is 10.1.0.0/16. Remember this for later.

Now we have the correct information, type the following into a terminal (as a superuser):

 iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o eth1 -m policy --pol ipsec --dir out -j ACCEPT
 iptables -t nat -A POSTROUTING -s 10.1.0.0/16 -o eth1 -j MASQUERADE

Make sure to change the IP address range to the one from your pool and the network interface for the correct one in your case.

Configuring Windows

This part is arguably the more trickier part of the procedure. The Windows "Agile VPN" client has particular ways it must be configured or the VPN connection will fail. Error messages emitted when the connection fails are generally unhelpful and need manual troubleshooting to find the problem. If followed correctly, these procedures will allow you to connect successfully first time. These instructions work for Windows >7.

Installing the certificates

Before we can install the certificate, the .p12 file we generated earlier must be copied locally to the computer it will be installed on.

Remember that each client must have its own certificate generated. Certificates should not be reused for other machines.

Double-click on the .p12 certificate file.
On the first "Welcome to the Certificate Import Wizard" page, change the "Store Location" from Current User to Local Machine.
Click Next.
The file name provided should be OK. Click Next.
In the password box, type the password you provided to generate the file earlier. Make sure the "Include all extended properties." check box is ticked.
If you would like to be able to backup the certificate later, you may want to check the "Mark this key as exportable. This will allow you to back up or transport your keys at a later time." check box. Bearing in mind, if you have the certificates and keys on the server, these can be exported at a later time if needed. If this text box is not ticked, your private key is kept secure if, for example, your computer was stolen.
Click Next.
The radio box should be in "Automatically select the certificate store based on the type of certificate" box. This is OK.
Click Next.
On the "Completing the Certificate Import Wizard" page, click Finish. You should get a prompt saying the import was successful. This will complete the import.

For the certificates to work correctly with the VPN server, they must be installed in the Computer store, not the User store. Hence, make sure the "Store Location" is changed from Current User to Local Machine.

Making the VPN profile

Windows >7 can make a new VPN profile via the Control Panel. Windows 10 can make a new VPN profile both via the Control Panel or the Settings App. We will be using the Control Panel method as this allows more control of the profile.

Open the Control Panel. Change to the Large Icon view if needed.
Click "Network and Sharing Centre".
Under your active networks section, in the "Change your network settings" section, click "Set up a new connection or network".
Under "Choose a connection option", click "Connect to a workplace". Then click Next.
Under "How do you want to connect?", click "Use my Internet connection (VPN)".
In the Internet address box, type your DNS name to your VPN server (thinkserver.freddythechick.net).
In the Destination name box, give your profile a name of your choosing (Thinkserver).
Make sure the "Allow other people to use this connection" tick box is checked.
Click Create. Your new profile will then be created.

You MUST use the same DNS name as you specified earlier on the certificate under CN in the DN and the SAN.

You MUST click the "Allow other people to use this connection" tick box so that it becomes a system wide connection and it can use the Machine Certificates.

We must now set the connection to use IKEv2.

In the previous Network and Sharing Centre window, click "Change adapter settings" down the left hand side.
There will be a new connection created here with the name you gave it earlier (Thinkserver). Right click on the connection and click 'Properties'.
Click on the "Security" tab.
Under the "Type of VPN" drop-down menu, change the type to IKEv2. The options under "Authentication" should change. Click and select the Use machine certificates radio button. Then click OK.

The connection is now ready.

Configuring strong encryption/ECDSA for the VPN connection

Windows PowerShell is used to change the encryption settings for the VPN connection. This only works on Windows 10 machines as these support the newer ciphers whereas Windows <10 does not support them so well.

In the Start menu, type "powershell". Click "Windows PowerShell" when it appears. It may take a few moments for the prompt to be appear and become ready to use.
The following code snippet needs to be typed in to change the encryption settings for the VPN settings

Set-VpnConnectionIPsecConfiguration -ConnectionName "VPN Connection" -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants GCMAES256 -EncryptionMethod GCMAES256 -IntegrityCheckMethod SHA384 -DHGroup ECP384
-PfsGroup none -PassThru -AllUserConnection

Press the ↵ Enter key.
Type Y to confirm the settings and press the ↵ Enter key.
The connection should now be ready to use!

Note: GCMAES256 is used under AuthenicationTransformConstants, CipherTransformsConstants and EncryptionMethod, even though strongSwan only supports ESP over IKEv2. This is due to an oddity within Windows where if only CipherTransformsConstants and EncryptionMethod are configured, Windows either sends the wrong encryption proposal (AES256 without GCM) or refuses to connect with a policy mismatch. Once all three fields are defined, the connection works correctly.

Forwarding all traffic through the VPN (Full Tunnel)

By default, at least in Windows 10 1809, only traffic for your local network behind the VPN server will be forwarded over the VPN connection. Connections to the internet will be forwarded over your local internet connection. This is known as "split-tunnelling". If you are creating this connection for ultimate security and want all your traffic to be forwarded over the tunnel, we need to configure a "full-tunnel".

Open the Control Panel
Click "Network and Sharing Centre"
Click "Change adapter settings" down the left pane.
Find the VPN connection (Thinkserver). Right-click it and click "Properties"
Click the "Networking" tab
Under the "This connection uses the following items:" header, click on "Internet Protocol Version 4 (TCP/IPv4)" line (not the check box)
Towards the bottom of the new window, click the "Advanced" button
Tick the "Use default gateway on remote network" checkbox. Click OK on all the settings windows.

This changes the tunnel from a split-tunnel to a full-tunnel. All traffic will be forwarded over the tunnel now.

Miscellaneous Settings

NOTE: This doesn't seem to have any effect on Windows 10 if your are manually configuring the connection with PowerShell.

There is a Windows registry key that may need to be enabled to allow the use of stronger encryption settings. It is not clear at this stage if these settings are required, but the instructions are left here in case they are needed. These settings are, however, needed for Windows 7 clients which falls back to weak encryption if this is not configured and is probably needed since StrongSwan doesn't support the weak ciphers proposed by Windows 7 any more.

Press ⊞ Win+R to open the Run box.
Type regedit and click OK.
Navigate to the following registry path:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\

Right-click in the right pane, hover over New and click DWORD (32-bit) Value.
Give the new key the name NegotiateDH2048_AES256.
Double-click the key to open the key. In the value box, change the 0 to a 2. Click OK.
Close the Registry Editor
Restart the machine.

StrongSwan