StrongSwan: Difference between revisions

We will be setting up the connection to allow a connection from this server to a Windows 10 1809 (October 2018 Update) client. Windows 10 1809 supports the Internet Key Exchange v2 (IKEv2), 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 maybe unreliable and has to reconnect. Windows 10 1809 supports the use of the following modern ciphers:

* ESP supports AES-GCM 128 & 256-bit for both encryption and authentication.

Note that Windows initially uses '''VERY''' weak encryption (3DES) and authentication schemes by default (from the Windows 2000 days) 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" anymore and requires configuration to use stronger ciphers.'''

We will be using the modern strongSwan VICI backend, not the old stroke backend as strongSwan is starting to phase this method out.

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

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

Certificates, especially 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 is easily brute-forced.

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

'''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 once done until it would be needed in the future to sign more certificates.

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

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

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 last <code>/</code> when copying or it will copy it to this name rather than the folder.

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 known by the server initially.'''

       local_addrs = 192.168.1.9

             local_ts  = dynamic

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

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.

Before we can install the certificate, the .p12 file we generated earlier must be copied locally to the computer it will be installed on. They don't seem to install properly when you try installing from a network share.

For the certificates to be found by the VPN client, 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.

Windows 10 has two ways of making a new VPN profile, via the Control Panel or via the Settings App. We will be using the Control Panel method as this allows more control of the profile.

* Click Network and Sharing Centre.

* In the Internet address box, type your DNS name to your VPN server.

* In the Destination name box, give your profile a name of your choosing.

* 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. [[File:Administrator_Shield.png]] Right click on the connection and click Properties.

* Click on the Security tab.

Windows PowerShell is used to change the encryption settings for the VPN connection.

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.

* Press {{key press|Win}}+{{key press|R}} to open the Run box.