StrongSwan - Revision history

Sam: /* Miscellaneous Settings */ Added to Windows 7 statement

2021-06-03T03:22:54Z

Miscellaneous Settings: Added to Windows 7 statement

← Older revision		Revision as of 03:22, 3 June 2021
Line 316:		Line 316:
	'''NOTE: This doesn't seem to have any effect on Windows 10 if your are manually configuring the connection with PowerShell.'''		'''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.		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 {{key press\|Win\|R}} to open the Run box.		* Press {{key press\|Win\|R}} to open the Run box.

Sam: /* Miscellaneous Settings */ Use combined key press

2021-05-29T06:04:18Z

Miscellaneous Settings: Use combined key press

← Older revision		Revision as of 06:04, 29 May 2021
Line 318:		Line 318:
	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.		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.

	* Press {{key press\|Win~~}}+{{key press~~\|R}} to open the Run box.		* Press {{key press\|Win\|R}} to open the Run box.
	* [[File:Administrator_Shield.png]] Type <code>regedit</code> and click OK.		* [[File:Administrator_Shield.png]] Type <code>regedit</code> and click OK.
	* Navigate to the following registry path:		* Navigate to the following registry path:

Sam: /* Miscellaneous Settings */ Added statement about Windows 7

2021-05-26T23:15:39Z

Miscellaneous Settings: Added statement about Windows 7

← Older revision		Revision as of 23:15, 26 May 2021
Line 316:		Line 316:
	'''NOTE: This doesn't seem to have any effect on Windows 10 if your are manually configuring the connection with PowerShell.'''		'''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.		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.

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

Sam: /* Configuring strong encryption/ECDSA for the VPN connection */ Added statement on Windows version support

2021-05-26T23:13:15Z

Configuring strong encryption/ECDSA for the VPN connection: Added statement on Windows version support

← Older revision		Revision as of 23:13, 26 May 2021
Line 285:		Line 285:
	== Configuring strong encryption/ECDSA for the VPN connection ==		== Configuring strong encryption/ECDSA for the VPN connection ==

	Windows PowerShell is used to change the encryption settings 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". [[File:Administrator_Shield.png]] Click "Windows PowerShell" when it appears. It may take a few moments for the prompt to be appear and become ready to use.		* In the Start menu, type "powershell". [[File:Administrator_Shield.png]] Click "Windows PowerShell" when it appears. It may take a few moments for the prompt to be appear and become ready to use.

Sam: /* Making the VPN profile */ Added statement on supported Windows versions

2021-05-26T23:12:19Z

Making the VPN profile: Added statement on supported Windows versions

← Older revision		Revision as of 23:12, 26 May 2021
Line 258:		Line 258:
	== Making the VPN profile ==		== Making the VPN profile ==

	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.		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.		* Open the Control Panel. Change to the Large Icon view if needed.

Sam: /* Configuring Windows */ Added statement for supported Windows versions

2021-05-26T23:09:44Z

Configuring Windows: Added statement for supported Windows versions

← Older revision		Revision as of 23:09, 26 May 2021
Line 235:		Line 235:
	= Configuring Windows =		= 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.		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 ==		== Installing the certificates ==

Sam: /* Creating a certificate for clients */ Changed server to client, removed redundancy

2021-05-26T23:07:16Z

Creating a certificate for clients: Changed server to client, removed redundancy

← Older revision		Revision as of 23:07, 26 May 2021
Line 102:		Line 102:
	# 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 client1Key.pem</pre>		#:<pre>chmod 600 client1Key.pem</pre>
	# Now we have the private key, generate the ~~server~~ certificate:		# Now we have the private key, generate the client certificate:
	#:<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>		#:<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 can be anything for the Windows client. No flags are required.		The <code>CN</code> 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 ~~but safe~~ as this will be needed each time you want to sign a client certificate.'''		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 ==		== Packaging the required certificates and keys for Windows ==

Sam: Reworded a few parts to make more sense

2020-11-29T17:52:27Z

Reworded a few parts to make more sense

← Older revision		Revision as of 17:52, 29 November 2020
Line 4:		Line 4:
	* Allows full access to your internal network securely over an insecure network.		* 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.		* Certificate authentication.
	* ECDSA certificates (256 and 384-bit keys).		* 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).		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.		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>		* <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 =		= 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 =		= 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 ==		== 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.		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 ==		== Creating a certificate for the server ==
Line 127:		Line 127:
	== Copying the certificates to the correct places ==		== 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>:		* Copy <code>serverCert.pem</code> to <code>/etc/swanctl/x509/</code>:
Line 136:		Line 136:
	cp caCert.pem /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 ~~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> ==		== <code>/etc/swanctl/swanctl.conf</code> ==
Line 143:		Line 143:

	windows {		windows {
	local_addrs = 192.168.1.9		local_addrs = 192.168.1.9
	pools = primary-ipv4		pools = primary-ipv4

Line 295:		Line 295:
	* The connection should now be ready to use!		* 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)==		== Forwarding all traffic through the VPN (Full Tunnel)==

Sam: /* /etc/swanctl/swanctl.conf */ Added missing space to code box

2019-04-09T02:42:25Z

/etc/swanctl/swanctl.conf: Added missing space to code box

← Older revision		Revision as of 02:42, 9 April 2019
Line 154:		Line 154:
	auth = pubkey		auth = pubkey
	}		}

	children {		children {
	net {		net {

Sam: /* /etc/swanctl/swanctl.conf */ Removed commented lines, corrected local_ts

2019-04-09T02:41:58Z

/etc/swanctl/swanctl.conf: Removed commented lines, corrected local_ts

← Older revision		Revision as of 02:41, 9 April 2019
Line 144:		Line 144:
	windows {		windows {
	local_addrs = 192.168.1.9		local_addrs = 192.168.1.9
	~~#local_addrs = %any~~
	pools = primary-ipv4		pools = primary-ipv4
	~~#encap = yes~~

	local {		local {
Line 155:		Line 153:
	remote {		remote {
	auth = pubkey		auth = pubkey

	}		}

	children {		children {
	net {		net {
	local_ts = ~~dynamic~~		local_ts = 0.0.0.0/0
	updown = /usr/lib/ipsec/_updown iptables		updown = /usr/lib/ipsec/_updown iptables
	esp_proposals = aes256gcm16-ecp384		esp_proposals = aes256gcm16-ecp384