StrongSwan: Difference between revisions

Line 4:

* 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. 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:

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 ~~for~~ both encryption and authentication.

* 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 ~~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.'''

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.

Line 35:

* <code>firewalld</code>

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 further 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.

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 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, </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.

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 when the <code>strongswan-swanctl</code> and <code>charon-systemd</code> packages are added.

= Creating the certificates =

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.

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 ~~same or better~~ security.

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 ==

Line 71:

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

'''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 ==

Line 127:

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

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

* Copy <code>serverCert.pem</code> to <code>/etc/swanctl/x509/</code>:

Line 136:

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

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.'''

== <code>/etc/swanctl/swanctl.conf</code> ==

Line 143:

windows {

local_addrs = 192.168.1.9

pools = primary-ipv4

Line 295:

* The connection should now be ready to use!

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

Note: <code>GCMAES256</code> is used under <code>AuthenicationTransformConstants</code>, <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code>, even though strongSwan only supports ESP over IKEv2. This is due to an oddity within Windows where if only <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code> 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)==

@@ Line 4: / Line 4: @@
 * 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. 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:
+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 for both encryption and authentication.
+* 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 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.'''
+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.
@@ Line 35: / Line 35: @@
 * <code>firewalld</code>
-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 further 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.
+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 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, </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.
+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 when the <code>strongswan-swanctl</code> and <code>charon-systemd</code> packages are added.
 = Creating the certificates =
-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.
+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 same or better security.
+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 ==
@@ Line 71: / Line 71: @@
 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 once done until it would be needed in the future to sign more certificates.
+'''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 ==
@@ Line 127: / Line 127: @@
 == 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 last <code>/</code> when copying or it will copy it to this name rather than the folder.
+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 <code>/</code> when copying or it will copy it to this name rather than the folder.
 * Copy <code>serverCert.pem</code> to <code>/etc/swanctl/x509/</code>:
@@ Line 136: / Line 136: @@
   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 known by the server initially.'''
+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.'''
 == <code>/etc/swanctl/swanctl.conf</code> ==
@@ Line 143: / Line 143: @@
     windows {
-       local_addrs  = 192.168.1.9
+       local_addrs = 192.168.1.9
        pools = primary-ipv4
@@ Line 295: / Line 295: @@
 * The connection should now be ready to use!
-Note: <code>GCMAES256</code> is used under <code>AuthenicationTransformConstants</code>, <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code>, even though strongSwan only supports ESP over IKEv2. This is due to an oddity within Windows where if only <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code> are configured, Windows either sends the wrong encryption proposal (AES256 without GCM) or refused to connect with a policy mismatch. Once all three fields are defined, the connection works correctly
+Note: <code>GCMAES256</code> is used under <code>AuthenicationTransformConstants</code>, <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code>, even though strongSwan only supports ESP over IKEv2. This is due to an oddity within Windows where if only <code>CipherTransformsConstants</code> and <code>EncryptionMethod</code> 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)==