Choosing a Mobile IPsec Style

Currently only one type of mobile IPsec may be configured at a time, though there are multiple different styles to choose from.

  • IKEv2 with EAP-MSCHAPv2 for local username and password authentication

  • IKEv2 with EAP-RADIUS for remote username and password authentication

  • IKEv2 with EAP-TLS for per-user certificate authentication

  • Xauth+PSK for local or remote username and password authentication

  • Xauth+RSA for certificates and local or remote username and password authentication

  • Pre-Shared Key for basic IPsec connectivity from older clients

  • L2TP/IPsec for local or remote username and password authentication with clients that do not support one of the above methods.

As of this writing, most current operating systems natively support IKEv2 or can use an app/add-on. It is currently the best available choice. Windows 7 and later, Android 11 and later, macOS 10.11 (El Capitan) and later, iOS 9 and later, and most Linux distributions have support built in for IKEv2. There is also a simple-to-use strongSwan IKEv2 app for various operating systems including older versions of Windows as well as Android 4.x and later.

Note

All IKEv2 types require a certificate structure including at least a Certificate Authority and a Server Certificate, and in some cases user certificates. For more information on Certificates, see Certificate Management. Clients can be picky about certificate attributes, so pay close attention to this chapter when creating the certificate structure.

Warning

When generating a Server Certificate for use with IKEv2, the Common Name of the certificate must be the hostname of the firewall as it exists in DNS. The name must be repeated again as an FQDN type Subject Alternative Name (SAN). The SAN step is handled automatically by the Certificate Manager on current versions of pfSense® software. The IP address of the firewall must also be present as an IP Address type SAN when possible. This information will be repeated later when relevant, but requires extra emphasis due to its importance. See Create a Server Certificate

IKEv2 with EAP-MSCHAPv2

With support for IKEv2 now widespread, IKEv2 with EAP-MSCHAPv2 is an ideal choice for current operating systems. Though there are several variations, EAP-MSCHAPv2 is the easiest to configure since it does not require generating or installing per-user certificates and does not require a working RADIUS server. The CA Certificate must still be installed onto the client as a trusted root certificate.

Tip

Many current clients will also work with a server certificate generated by the ACME Package. ACME certificates are already trusted by most clients natively, thus using ACME will bypass the need to install a CA entry on those clients.

EAP-MSCHAPv2 allows for username and password authentication using passwords stored on the Pre-Shared Keys tab under VPN > IPsec (IPsec Pre-Shared Keys Tab). These passwords are stored in plain text, so it is not as secure as using a RADIUS server, though it is more convenient.

IKEv2 with EAP-RADIUS

EAP-RADIUS works identically to EAP-MSCHAPv2 except that user authentication happens via RADIUS. When EAP-RADIUS is chosen, a RADIUS server must be selected on the Mobile Clients tab. The RADIUS server must accept and understand EAP requests and it must also allow MSCHAPv2. Password security is left up to the RADIUS server. VPN access can be optionally limited by RADIUS group membership using the Group Authentication options on the Mobile Clients tab.

EAP-RADIUS is typically the best choice when a RADIUS server is available.

IKEv2 with EAP-TLS

EAP-TLS uses per-user certificate authentication instead of username and password authentication. As such, EAP-TLS requires generating certificates for each user, which makes it a bit more cumbersome from an administration standpoint. Certificates are validated against the CA similar to OpenVPN. The CA certificate, user certificate and its associated key must all be imported to the client properly.

Warning

When creating user certificates, the username must be used as the certificate common name and as a DNS/FQDN type Subject Alternative Name. If the same name is not present in both places, clients may not be validated properly. This is handled automatically by the Certificate Manager on current versions of pfSense software.

IKEv1 with Xauth and Pre-Shared Keys

Xauth+PSK works on a majority of platforms, the notable exception being current versions of Android. Windows XP through Windows 8 can use the Shrew Soft client, but Windows 10 does not currently work with any available client. macOS and iOS can use their built-in client to connect.

Note

When using Xauth, local users must exist in the User Manager and those users must have the User - VPN - IPsec Xauth Dialin privilege.

IKEv1 with Xauth and RSA Certificates

Xauth+RSA works in most of the same conditions as Xauth+PSK, though it does in fact work on current Android devices. Certificates must be made for each user, and the certificates must be imported into the clients.

IKEv1 with Pre-Shared Keys Only

Pre-Shared Key only IPsec VPNs for mobile IPsec have become rare in modern times. Support was not very common, only found in the Shrew Soft client, some very specific Android versions such as those from Motorola, and in other third-party clients. They are not very secure, and are no longer recommended for general use. The only time they may be needed is in cases when client devices cannot support any other method.

L2TP/IPsec (IKEv1)

L2TP/IPsec is a unique combination that, unfortunately, does not work very well in practice. In this style of setup mobile IPsec is setup to accept Transport Mode connections which secure all traffic between the public IP address endpoints of clients and the firewall. An L2TP connection is made across this transport mode channel to tunnel user traffic in a more flexible way. Though support for this model is found in most versions of Windows, MAC, Android, and other Operating Systems, they are all picky in different incompatible ways about what will work.

For example the Windows client does not work properly when the client system is behind NAT, which is the most common place that a VPN client would find itself. The problem is in an interaction between the client and the IPsec daemon used on pfSense, strongSwan. The strongSwan project states that it is a bug in the Windows client, but it is unlikely to be fixed since both strongSwan and Windows have focused their mobile client efforts on more modern and secure implementations such as IKEv2 instead.

Warning

L2TP/IPsec should be avoided when possible.