StrongSwan: Difference between revisions
Major rework for new VICI framework underway. Saved changes so far. |
Major rework for new VICI framework underway. Finished to 'Configuring strongSwan' |
||
| Line 1: | Line 1: | ||
strongSwan is a VPN server that allows a connection over the | 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. | * Secure internet browsing, for example, over an insecure, open Wi-Fi connection. | ||
* Allows full access to your internal network securely over | * 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 | 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: | ||
* Certificate authentication. | * Certificate authentication. | ||
| Line 10: | Line 10: | ||
* ESP supports AES-GCM 128 & 256-bit for both encryption and authentication. | * ESP supports AES-GCM 128 & 256-bit for 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. | 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. | 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.''' | ||
strongSwan 5.6. | 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 backend, not the old stroke backend as strongSwan is starting to phase this method out. | We will be using the modern strongSwan VICI backend, not the old stroke backend as strongSwan is starting to phase this method out. | ||
| Line 35: | Line 35: | ||
* <code>firewalld</code> | * <code>firewalld</code> | ||
As this is a system package, restart the computer afterwards. We will be using <code>iptables</code> to manipulate the 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 | 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. | ||
= 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. | |||
= Creating the certificates = | = Creating the certificates = | ||
IKEv2 | 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. | 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. | ||
| Line 54: | Line 58: | ||
# Make sure you are in the correct directory above. | # Make sure you are in the correct directory above. | ||
# Generate a private key for the CA: | # Generate a private key for the CA: | ||
#:<pre> | #:<pre>pki --gen --type ecdsa --size 384 --outform pem > private/caKey.pem</pre> | ||
# Change the permissions of the private key, so that only root can access it: | # Change the permissions of the private key, so that only root can access it: | ||
#:<pre>chmod 600 private/ | #:<pre>chmod 600 private/caKey.pem</pre> | ||
# Now we have the private key, generate the CA certificate: | # Now we have the private key, generate the CA certificate: | ||
#:<pre> | #:<pre>pki --self --ca --lifetime 3650 --in private/caKey.pem --dn "C=GB, O=strongSwan, CN=strongSwan CA" --outform pem > cacerts/caCert.pem</pre> | ||
You now have a self-signed CA certificate, ready to sign any certificates to be used by the VPN server. | 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'''. | '''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. | ||
== Creating a certificate for the server == | == Creating a certificate for the server == | ||
| Line 68: | Line 72: | ||
# Make sure you are still in the correct directory. | # Make sure you are still in the correct directory. | ||
# Generate a private key for the certificate: | # Generate a private key for the certificate: | ||
#:<pre> | #:<pre>pki --gen --type ecdsa --size 384 --outform pem > private/serverKey.pem</pre> | ||
# Change the permissions of the private key, so that only root can access it: | # Change the permissions of the private key, so that only root can access it: | ||
#:<pre>chmod 600 private/ | #:<pre>chmod 600 private/serverKey.pem</pre> | ||
# Now we have the private key, generate the server certificate: | # Now we have the private key, generate the server certificate: | ||
#:<pre> | #:<pre>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</pre> | ||
The certificate created will be used to authenticate the VPN server. Only one needs creating. | The certificate created will be used to authenticate the VPN server. Only one needs creating. | ||
| Line 82: | Line 86: | ||
* The Common Name (<code>CN</code>) 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 Common Name (<code>CN</code>) 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 <code>CN</code> from the DN. | * 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 <code>CN</code> from the DN. | ||
* It '''MUST''' contain the <code>serverAuth</code> flag. | * It '''MUST''' contain the <code>serverAuth</code> flag. The <code>ikeIntermediate</code> is included for compatibility with MacOS and doesn't affect a Windows installation so is safe to add. | ||
== Creating a certificate for clients == | == Creating a certificate for clients == | ||
| Line 90: | Line 94: | ||
# Make sure you are still in the correct directory. | # Make sure you are still in the correct directory. | ||
# Generate a private key for the certificate: | # Generate a private key for the certificate: | ||
#:<pre>ipsec pki --gen --type ecdsa --size 384 --outform pem > private/ | #:<pre>ipsec pki --gen --type ecdsa --size 384 --outform pem > private/client1Key.pem</pre> | ||
# Change the permissions of the private key, so that only root can access it: | # Change the permissions of the private key, so that only root can access it: | ||
#:<pre>chmod 600 private/client1key.pem</pre> | #:<pre>chmod 600 private/client1key.pem</pre> | ||
# Now we have the private key, generate the server certificate: | # Now we have the private key, generate the server certificate: | ||
#:<pre> | #:<pre>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</pre> | ||
The <code>CN</code> in the DN this time | The <code>CN</code> in the DN this time can be anything for the Windows client. No flags are required. | ||
== Packaging the required certificates and keys for Windows == | == Packaging the required certificates and keys for Windows == | ||
All the keys and certificates required for the connection can be packaged into a PKCS#12 package, to allow easy installation on 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. | # Make sure you are still in the correct directory. | ||
# Use OpenSSL to create the PKCS#12 package: | # Use OpenSSL to create the PKCS#12 package: | ||
#:<pre>openssl pkcs12 - | #:<pre>openssl pkcs12 -in client1Cert.pem -inkey client1Key.pem -certfile caCert.pem -export -out client1.p12</pre> | ||
# Type a password you will remember when asked. This will protect the private key while it is in transit. | # 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. | # Retype the password you just typed. | ||
The | The .p12 file can then be copied to the Windows machine that it is to be installed on. | ||
= Configuring strongSwan = | = Configuring strongSwan = | ||