IPsec Remote Access VPN using IKEv2 with EAP-TLS¶

This recipe is a guide for configuring a remote access VPN using IPsec authenticated via EAP-TLS, which allows external users to securely connect and reach network resources through TNSR.

This is a “point-to-multipoint” type connection as there is one “server” configuration on TNSR through which multiple clients connect.

Tip

This style of setup may be known by several different names, including “Mobile IPsec”, “Road Warrior IPsec”, “Client IPsec”, “RA IPsec”, “IPsec/IKEv2”, “IKEv2”, and other similar names.

IKEv2 Server Configuration ¶

This example uses EAP-TLS to authenticate clients. EAP-TLS utilizes certificates to establish identities and validate that clients are allowed to access the VPN. The server holds a copy of the Certificate Authority (CA) and that can be used to validate that the client certificates have been signed by that same CA. In the other direction, clients can also use the CA to ensure that the server is authentic.

There are several components to configure which together allow TNSR to accommodate remote access IPsec clients using EAP-TLS:

A PKI certificate structure for the VPN (CA, server certificate, client certificates)
The IPsec tunnel
The IPIP interface

IKEv2 PKI Certificate Structure ¶

Certificate Authority¶

The first requirement is a certificate authority that will sign both the server certificate and the client certificates. This example calls this ca ipsec-ca and uses that same name for both the PKI entry and the common name:

tnsr(config)# pki private-key ipsec-ca generate
tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name ipsec-ca
tnsr(config)# pki signing-request set digest sha512
tnsr(config)# pki signing-request ipsec-ca generate
tnsr(config)# pki signing-request ipsec-ca sign self purpose ca

Server Certificate¶

Next, create a certificate for the TNSR side of the remote access IPsec setup, also called the “server” in this style of configuration.

The common name of this certificate should be the fully qualified domain name (FQDN) of the TNSR device. The hostname should exist in public DNS and connecting clients should use the hostname when connecting if possible. Additionally, the FQDN and any IP addresses on TNSR to which clients will connect should be added as subject alternative name (SAN) entries. This helps the clients to properly validate the server certificate. The IP address is not strictly necessary, but it can help in situations where a client may not support connecting to a server by hostname.

In this example, the hostname is tnsr.example.com and the IP address is 203.0.113.2.

tnsr(config)# pki private-key ipsec-server generate key-length 4096
tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name tnsr.example.com
tnsr(config)# pki signing-request set subject-alt-names add hostname tnsr.example.com
tnsr(config)# pki signing-request set subject-alt-names add ipv4-address 203.0.113.2
tnsr(config)# pki signing-request set digest sha512
tnsr(config)# pki signing-request ipsec-server generate
tnsr(config)# pki signing-request ipsec-server sign ca-name ipsec-ca days-valid 398
                  digest sha512 purpose server

Replace the hostname and IP address of the server in the commands above with the address of the TNSR device.

Client Certificates¶

Now create a certificate for each client.

Warning

Client certificates must have a Subject Alternative Name (SAN) set the same as the PKI name and common name. To make the certificate easier to identify when imported on client operating systems, it helps to keep the PKI name and common name the same.

In this example the user is ipsec-myuser:

tnsr(config)# pki private-key ipsec-myuser generate key-length 4096
tnsr(config)# pki signing-request settings clear
tnsr(config)# pki signing-request set common-name ipsec-myuser
tnsr(config)# pki signing-request set subject-alt-names add hostname ipsec-myuser
tnsr(config)# pki signing-request set digest sha512
tnsr(config)# pki signing-request ipsec-myuser generate
tnsr(config)# pki signing-request ipsec-myuser sign ca-name ipsec-ca days-valid 365
                  digest sha512 purpose client

Repeat that process for each user that will connect to the IPsec remote access tunnel.

Exporting Certificates¶

Different clients have different requirements for how they import or utilize client certificates. Most clients can use PKCS#12 archives which contain the CA certificate along with the client certificate and private key in one file.

Exporting PKCS#12 for most operating systems (except macOS):

tnsr# pki pkcs12 ipsec-myuser generate export-password abcd1234 ca-name ipsec-ca

Replace the example password with a stronger version.

After running the command, a copy of the PKCS#12 archive will be stored in the home directory of the TNSR CLI user. This file can then be copied off the TNSR device using SCP or similar methods.

Exporting PKCS#12 for macOS, which does not support the high level of encryption that is used by default:

tnsr# pki pkcs12 ipsec-myuser generate export-password abcd1234 ca-name ipsec-ca
          key-pbe-algorithm PBE-SHA1-3DES certificate-pbe-algorithm PBE-SHA1-3DES
          mac-algorithm sha1

If a client expects the certificate data in separate files, they can be exported individually:

tnsr(config)# pki ca ipsec-ca get
<copy/paste output and save as ipsec-ca.crt>

tnsr(config)# pki private-key ipsec-myuser get
<copy/paste output and save as ipsec-myuser.key>

tnsr(config)# pki certificate ipsec-myuser get
<copy/paste output and save as ipsec-myuser.crt>

IPIP Tunnel ¶

The underlying IPIP tunnel must be defined before configuring the IPsec tunnel. This must be a point-to-multipoint IPIP tunnel which means it only contains a source address and no remote addresses.

tnsr(config)# tunnel ipip 2
tnsr(config-ipip)# source ipv4 address 203.0.113.2
tnsr(config-ipip)# exit

The source IP address must exist on a TNSR interface.

IPsec Tunnel ¶

Now configure the IPsec tunnel. The encryption options shown in this example are a good secure starting point, but can be adjusted provided that all connecting clients support the algorithms in question.

First, start configuring the tunnel and the initial IKE configuration:

tnsr(config)# ipsec tunnel 2
tnsr(config-ipsec-tunnel)# enable
tnsr(config-ipsec-tunnel)# crypto config-type ike
tnsr(config-ipsec-tunnel)# crypto ike
tnsr(config-ipsec-crypto-ike)# version 2
tnsr(config-ipsec-crypto-ike)# lifetime 28800
tnsr(config-ipsec-crypto-ike)# proposal 1
tnsr(config-ike-proposal)# encryption aes256gcm16
tnsr(config-ike-proposal)# group modp2048
tnsr(config-ike-proposal)# prf prfsha256
tnsr(config-ike-proposal)# exit

By default the tunnel will not allow the same client to connect multiple times. If users require multiple simultaneous connections, then configure the unique identifier policy to allow that function:

tnsr(config-ipsec-crypto-ike)# unique-id-policy never

Next, configure the local IKE identity. The local identity is typically either set to the FQDN or IP address to which clients will connect. This value must also match one of the SAN entries in the server certificate.

tnsr(config-ipsec-crypto-ike)# identity local
tnsr(config-ike-identity)# type address
tnsr(config-ike-identity)# value 203.0.113.2
tnsr(config-ike-identity)# exit

As the remote access clients will all have different identities, this must be set to %any with a type of none:

tnsr(config-ipsec-crypto-ike)# identity remote
tnsr(config-ike-identity)# type none
tnsr(config-ike-identity)# value %any
tnsr(config-ike-identity)# exit

For local authentication, configure the server certificate created earlier:

tnsr(config-ipsec-crypto-ike)# authentication local
tnsr(config-ike-authentication)# round 1
tnsr(config-ike-authentication-round)# certificate ipsec-server
tnsr(config-ike-authentication-round)# exit
tnsr(config-ike-authentication)# exit

For remote authentication, configure the certificate authority for EAP-TLS:

tnsr(config-ipsec-crypto-ike)# authentication remote
tnsr(config-ike-authentication)# round 1
tnsr(config-ike-authentication-round)# eap-tls-ca-certificate ipsec-ca
tnsr(config-ike-authentication-round)# exit
tnsr(config-ike-authentication)# exit

Next, configure IPv4 and/or IPv6 remote access address pools. TNSR will assign addresses from these pools to connecting clients:

tnsr(config-ipsec-crypto-ike)# remote-access address-pools
                               ipv4-range 10.2.220.100 to 10.2.220.254

The optional DNS server entries can also be pushed to clients if needed. Ensure that the address pools above are granted access to perform recursive queries against these servers:

tnsr(config-ipsec-crypto-ike)# remote-access dns resolver 1 address 10.2.0.1

Now configure the child proposal:

tnsr(config-ipsec-crypto-ike)# child 1
tnsr(config-ike-child)# lifetime 3600
tnsr(config-ike-child)# proposal 1
tnsr(config-ike-child-proposal)# encryption aes256gcm16
tnsr(config-ike-child-proposal)# group modp2048
tnsr(config-ike-child-proposal)# exit

Traffic selectors are optional and allow “split tunneling” where clients will only send traffic matching the traffic selectors over the VPN. Without traffic selectors, clients will send all of their traffic, including Internet traffic, across the tunnel.

tnsr(config-ike-child)# traffic-selector 1 local 10.2.0.0/16

Warning

Client behavior varies when it comes to traffic selectors. Windows clients do not respect traffic selectors automatically, while macOS/iOS, Ubuntu, and Android (strongSwan) clients do. Windows clients can be configured for split tunneling but it is a manual process. See the client configuration notes for details.

Now exit out to complete the IPsec tunnel configuration.

tnsr(config-ike-child)# exit
tnsr(config-ipsec-crypto-ike)# exit
tnsr(config-ipsec-tunnel)# exit
tnsr(config)#

IPIP Interface ¶

Now configure the interface for the IPIP tunnel. The prefixes configured on this interface must contain the remote access address pools configured on the IPsec tunnel.

tnsr(config)# interface ipip2
tnsr(config-interface)# enable
tnsr(config-interface)# ip address 10.2.220.1/24

If traffic from remote access clients will exit out to the Internet and TNSR should perform NAT on that traffic, then the NAT configuration must be adjusted to account for the client addresses. For VPF NAT, this means an additional rule in the NAT ruleset on the WAN interface. For dataplane NAT this means declaring the ipip2 interface to be an inside NAT interface.

Now exit the interface configuration and at this point the tunnel is ready for clients.

tnsr(config-interface)# exit

Lastly, remember to save the configuration:

tnsr(config)# configuration copy running startup

Client Configuration ¶

Each mobile client device needs a VPN instance or client configured. In some cases a third-party IPsec client may be required. There are many different IPsec clients available for use, some free, and some commercial applications. With IKEv2, as used in this example, many operating systems have native VPN clients and do not need extra software.

Common clients are covered in IPsec Remote Access Client Configuration.

IPsec Remote Access VPN using IKEv2 with EAP-TLS¶

IKEv2 Server Configuration¶

IKEv2 PKI Certificate Structure¶