Strongswan windows client download

strongSwan — Download

strongSwan 5.x — Monolithic IKEv1/v2 Daemon

Current Release: 5.9.2

Developers Release: 5.9.3dr1

Developers Release: 6.0.dr6

strongSwan 2.x, 4.x and 5.x Security Patches

NetworkManager Applet

This applet is also available as package in several distributions. For an introduction and HOWTO see our wiki.

Current Release: 1.5.2

NetworkManager Applet 1.5.2 This version requires strongSwan 5.8.3 or newer, it’s not compatible with older releases. NetworkManager Applet 1.4.5 This version works with all strongSwan releases, but doesn’t support the new features introduced with 5.8.3.

Installation / Binary packages

Most distributions provide packages for strongSwan:

Download Mirrors

• download.strongswan.org Hochschule für Technik Rapperswil (100 Mbps)
• download2.strongswan.org strongSec GmbH (5 Mbps)

License statement

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

strongSwan

Documentation¶

Resources¶

strongSwan on Windows¶

Starting with 5.2.0, strongSwan can be built for the Windows platform using the MinGW toolchain. Supported are Windows 7 / Server 2008 R2 and newer releases. Older versions are unlikely to get ever supported, as they have some IPsec API limitations.

Important notes¶

• Beside some other limitations, the kernel-iph networking backend currently does not support the installation of virtual IP addresses. Such addresses are usually assigned to road-warrior clients, making the strongSwan Windows port not usable as client for this particular scenario.

• The socket-win socket plugin by default binds to UDP ports 500 and 4500. To receive any packets, the Windows native IKE service must be disabled by stopping/disabling the IKEEXT service. If you see any WFP MM failure errors, the IKEEXT service is probably running.

Ported functionality¶

strongSwan has a large codebase, and not all functionality has been ported to Windows. Beside the libstrongswan, libhydra and libcharon core libraries, the libtls and libtnccs libraries are known to work under Windows.

The following plugins are supported in Windows builds:

• test-vectors
• nonce
• pem
• pkcs1
• pkcs8
• pubkey
• acert
• x509
• openssl
• rdrand
• revocation
• constraints
• mysql and sqlite
• eap-identity
• eap-tls and eap-ttls
• eap-tnc using tnccs-2.0
• tnc-imv with imv-os and imv-attestation
• tnc-imc with imc-os and imc-attestation
• vici
• ext-auth (since 5.2.1)
• updown (since 5.2.1)

Many additional plugins might work without or with minor modifications, but have not yet been tested extensively.

The following additional components are supported:

• pki
• swanctl
• leak-detective, optionally using bfd-backtraces using libbfd

starter and ipsec.conf based configurations are not supported. Use the swanctl backend instead.

Windows specific components¶

Specifically for the Windows port, the following components have been introduced:

charon-svc	Windows IKE service using libcharon
socket-win	IKE socket implementation using Winsock2 API
winhttp	HTTP/HTTPS CRL/OCSP fetcher using WinHTTP API
kernel-iph	Networking backend using IP Helper API
kernel-wfp	Interface to native Windows IPsec backend in the Windows Filtering Platform

The kernel-iph and kernel-wfp plugins currently have some limitations and known issues, please consult their wiki pages.

Dependencies¶

There are no hard third party dependencies on the Windows platform, as strongSwan uses a native (non-pthread) threading backend on Windows. You’ll need a working crypto backend, though, and OpenSSL is known to work fine. Other crypto backends have not yet been tested, future releases might include a native Windows crypto backend.

Toolchain¶

The first option is usually simpler and recommended when building from Git sources.

The port has been done using the MinGW-W64 toolchain. Other compilers are currently not supported. Using Visual C compilers is not an option in the near future, as we heavily use some C99 features which MSVC does not support.

Note: In pre-3.2.0 MinGW-W64 releases, there is a bug in one of the required system headers. Apply the patch provided with the kernel-wfp sources to fix it. Newer releases have these changes included. strongSwan 5.2.2 requires a at least MinGW-W64 3.2.0 to properly handle TryAcquireSRWLockExclusive (MinGW builds having GCC 4.9.1 should have that fix).

In strongSwan 5.2.0, only monolithic builds are supported, hence pass
to ./configure.

Both x86_64 and i686 build variants are supported. The 32-bit build variants have been tested less extensively, though.

As many of the strongSwan default plugins are not supported, it is recommended to pass
to ./configure, and enable the specific options as required. A minimal set of ./configure options could look like:

It is usually a good idea to specify relative paths for strongswan.conf and swanctl, as it allows you to move these files freely along with your binaries.

Windows native build ¶

First install MinGW-W64, preferably using the installer. The 4.8.1 version is known to work fine using the x64 Architecture and native win32 threading.

To run ./configure, you’ll need MSYS, for example by using the MinGW-W64 MSYS builds. After extracting the .zip file, invoke msys.bat and run:
to complete the installation.

Use this shell to ./configure and build strongSwan.

Unix cross-compile build ¶

After installing the MinGW-W64 toolchain and the Windows system headers for your distribution, add
or, for 32-bit builds,
to ./configure to enable cross-compilation.

Installation¶

To extract the binaries, you may use make install using a specific DESTDIR, or manually copy the requires binaries from the .libs subdirectories. A future version hopefully provides a more convenient way to create a redistributable binary package.

Next steps¶

Refer to charon-svc for instructions how to install the IKE service or run it in a console window. swanctl has more information about configuring the IKE service accordingly.

Strongswan windows client download

strongSwan — Download

strongSwan 5.x — Monolithic IKEv1/v2 Daemon

Current Release: 5.9.2

Developers Release: 5.9.3dr1

Developers Release: 6.0.dr6

strongSwan 2.x, 4.x and 5.x Security Patches

NetworkManager Applet

This applet is also available as package in several distributions. For an introduction and HOWTO see our wiki.

Current Release: 1.5.2

NetworkManager Applet 1.5.2 This version requires strongSwan 5.8.3 or newer, it’s not compatible with older releases. NetworkManager Applet 1.4.5 This version works with all strongSwan releases, but doesn’t support the new features introduced with 5.8.3.

Installation / Binary packages

Most distributions provide packages for strongSwan:

Download Mirrors

• download.strongswan.org Hochschule für Technik Rapperswil (100 Mbps)
• download2.strongswan.org strongSec GmbH (5 Mbps)

License statement

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

strongSwan

Documentation¶

Resources¶

Windows Clients¶

Windows 7 and newer releases (including Windows Phone 8.1 and newer) support the IKEv2 and MOBIKE (RFC 4555) standards through Microsoft’s Agile VPN functionality and are therefore able to interoperate with a strongSwan VPN gateway using these protocols.

Windows does not currently support IKE redirection (RFC 5685).

strongSwan currently can authenticate Windows clients either on the basis of X.509 Machine Certificates using RSA signatures (case A), X.509 User Certificates using EAP-TLS (case B), or Username/Password using EAP-MSCHAPv2 (case C). The client does not support multiple authentication rounds (RFC 4739).

Make sure to fulfill the certificate requirements to successfully authenticate Windows clients.

A) Authentication using X.509 Machine Certificates¶

The strongSwan VPN gateway and each Windows client needs an X.509 certificate issued by a Certification Authority (CA). OpenSSL or pki can be used to generate these certificates.

On the Windows Client¶

On the strongSwan VPN Gateway¶

B) Authentication using X.509 User Certificates¶

This is very similar to case A, but certificates are stored in a user specific keystore (using smart cards is also possible in this case). The client authentication has to be done with EAP-TLS in this case. As an EAP identity exchange is needed, make sure to have the eap-identity plugin loaded.

On the Windows Client¶

• Storing the user certificate is basically the same as storing a machine certificate simply select My user account instead of Computer account in the Certificates MMC snap-in. Actually, since this keystore is used by default, you can simply double click the certificate to install it.
• Please note that the CA certificate used to authenticate the VPN gateway has still to be installed in the Computer account keystore.
• Configuring a Windows Agile VPN connection

On the strongSwan VPN Gateway¶

C) Authentication using EAP-MSCHAP v2¶

In order to prevent man-in-the-middle attacks the strongSwan VPN gateway always authenticates itself with an X.509 certificate using a strong RSA/ECDSA signature. After a secure communication channel has been set up by the IKEv2 protocol, the Windows clients authenticate themselves using the EAP-MSCHAPv2 protocol based on user name, optional windows domain and user password. As an EAP identity exchange is needed for this to work, make sure to have the eap-identity plugin loaded.

EAP-MSCHAPv2 requires MD4 to generate the NT-Hashes, so either the md4 plugin or one of the crypto library wrappers (OpenSSL, Gcrypt) is required. This is not needed if the authentication is delegated to an AAA server via eap-radius plugin.

Some Windows clients will always send a domain part in the user name field (e.g. Windows Phone\User ). Depending on the backend used to authenticate the users the domain part may have to be stripped away (see #612-3 for an example regarding FreeRADIUS), or be included when defining the credentials (e.g. in EAP secrets in ipsec.secrets).

Important: strongSwan releases before 4.3.1 are not compatible with Windows 7 RC (Build 7100) or later, because Microsoft’s EAP-MSCHAPv2 implementation changed from Beta to Release Candidate.

On the Windows Client¶

On the strongSwan VPN Gateway¶

Rekeying behavior¶

IKE_SA rekeying¶

The Windows 7 client supports IKE_SA rekeying, but can’t handle unsupported Diffie Hellman groups. If a strongSwan gateway initiates IKE_SA rekeying, it must use modp1024 as the DH group in the first attempt, otherwise rekeying fails. You can achieve this by setting modp1024 as the first (or only) DH group in the gateways ike proposal.

CHILD_SA rekeying¶

Rekeying CHILD_SAs is also supported by the Windows 7 client. For some reason, a client behind NAT does not accept a rekeying attempt and rejects it with a Microsoft specific notify 12345, containing an error code ERROR_IPSEC_IKE_INVALID_SITUATION.

To work around the issue, let the client initiate the rekeying (set rekey=no on the server). It will do so about every 58 minutes and 46 seconds, so set the gateway rekey time a little higher. There is no way known to change the rekey time (the netsh.ras.ikev2saexpiry options affect the Windows Server implementation only).

Another option is to set no rekey time, but only a hard lifetime to delete the CHILD_SA. The client will renegotiate the SA when required.

Bugs & Features¶

IKEv2 Fragmentation¶

IKEv2 fragmentation is supported since the v1803 release of Windows 10 and Windows Server. All versions of Windows also support the proprietary IKEv1 fragmentation.

Split routing on Windows 10 and Windows 10 Mobile¶

Microsoft changed Windows 10 Desktop and Mobile VPN routing behavior for new VPN connections. Option «Use default gateway on remote network option» in the Advanced TCP/IP settings of the VPN connection is now disabled by default. You can enable this option on Desktop but there is no way to do this on Mobile. Fortunately, Windows sends DHCP request upon connection and add routes supplied in option 249 of DHCP reply.

Sample configuration file for dnsmasq:

Where 192.168.103.0 is your (internal) network. It pushes 2 separate routes which cover entire IPv4 range. Gateway could be anything (set to 0.0.0.0 in an example) as it’s ignored by Windows.
Note that you can’t ignore DHCP routes in Windows.

Windows doesn’t add an IPv6 route by default. There are thee workarounds:

• Add a permanent default route manually using the following or a similar command:
  Where 27 is your IKEv2 interface ID.
  or
  to avoid problems with interface ID change between reboots.

• Configure and use a router advertisement daemon (requires custom patch for strongSwan, see #817)

• on Windows 10, and presumably all future versions where PowerShell is available, you can use MS PowerShell Add-VpnConnectionRoute cmdlet.
  This cmdlet will not allow you add default route 0::/0. However, in most cases you do not really need default route over VPN. Current (as of 2/2020) IANA IPv6 space assignment specifies only 2000::/3 block as Global Unicast, and adding this prefix is perfectly sufficient for routing all traffic over VPN interface. Cmdlet will will take care of adding route upon VPN connection and also removing it upon disconnection.
  Also, unlike netsh, this usually does not require administrator privileges and is fully integrated with Windows GUI, saving you trouble with batch files.

AES-256-CBC and MODP2048¶

By default, the Windows Agile VPN Client only offers AES-128-CBC, AES-192-CBC, AES-256-CBC, 3DES, SHA-1,SHA-256, SHA-384 and MODP-1024.
By creating and setting the following registry key as a DWORD key, support for MODP2048 can be enabled, disabled or enforced.

The values that can be used are 0, 1 or 2. The table tells you what the values mean.

value	meaning
0 (default)	disable AES-256-CBC and MODP-2048
1	Enable AES-256-CBC and MODP-2048
2	Enforce the usage of AES-256-CBC and MODP-2048

By using the Set-VpnConnectionIPsecConfiguration PowerShell cmdlet it is possible to use even more algorithms like AES-GCM and ECP DH groups (at least on Windows 10). The VPN connection may be added in the GUI or via «Add-VpnConnection» cmdlet.

Serving different IDs/Domain names¶

The native Windows VPN Client does not send a responder identity (IDr) when initiating an IKE_SA, so two connection configurations can only be distinguished if their authentication type differs or the clients send different certificate for the different certificates’ root CAs.

Accessing the VPN server via VPN¶

Windows doesn’t seem to be able to reach the VPN server’s physical IP address (to which the IKE_SA was established) via VPN connection. To access the server via VPN, use any other IP address that is assigned to it and included in the traffic selector (if necessary, assign an IP address to any local interface and maybe adjust the traffic selector).

Links¶

• Windows OS product behavior in regards to IKE

• Adrian Dimcev’s blog provides valuable information on Agile VPN connections between Windows 7 Beta and Windows Server 2008 R2 Beta.

• MoPo users at the University of Freiburg can connect to a strongSwan VPN gateway using Windows 7 (in German).

• Microsoft Windows 8, Microsoft Windows Server 2012, Microsoft Windows RT Common Criteria Supplemental Admin Guidance for IPsec VPN Clients

Acknowledgements¶

Many thanks go to Edward Chang and Gleb Sechenov from the Information Security Institute (ISI) of the Queensland University of Technology (QUT) who provided the initial Windows 7 Beta and Ubuntu Linux test setup.