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.
See also
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 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.
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.