IPsec Remote Access VPN using IKEv2 with EAP-RADIUS¶
This recipe is a guide for configuring a remote access VPN using IPsec authenticated via EAP-RADIUS, which allows external users to securely connect and reach network resources through TNSR after TNSR authenticates the user against a RADIUS server (RADIUS User Authentication).
This is a “point-to-multipoint” type connection as there is one “server” configuration on TNSR through which multiple clients connect.
There are several components to configure which together allow TNSR to accommodate remote access IPsec clients using EAP-RADIUS:
The RADIUS server
A PKI certificate structure for the VPN (CA, server certificate)
The IPsec tunnel
The IPIP interface
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.
RADIUS Configuration¶
The cornerstone of authenticating IKEv2 using EAP-RADIUS is the RADIUS server which will authenticate users as they connect.
First, define the RADIUS server as described in RADIUS User Authentication:
tnsr(config)# radius
tnsr(config-radius)# server name auth1 host 198.51.100.3 secret abcd1234 timeout 3
tnsr(config-radius)# exit
Next, define an authentication server group including the RADIUS server:
tnsr(config)# auth server-group radauth
tnsr(config-auth-server-group)# type radius
tnsr(config-auth-server-group)# priority 20 radius auth1
tnsr(config-auth-server-group)# exit
Finally, configure IPsec to use this server group:
tnsr(config)# ipsec global-options eap-radius server-group radauth
PKI Certificate Structure¶
The server presents a certificate to establish its identity and the clients use the CA to validate that certificate and ensure that the server is authentic.
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.
Exporting the CA¶
Clients will need a copy of the CA certificate to validate the server certificate. They do not need a copy of any other certificate for this type of VPN.
To export the CA certificate, use pki ca <name> get:
tnsr(config)# pki ca ipsec-ca get
-----BEGIN CERTIFICATE-----
<encoded-text>
-----END CERTIFICATE-----
Copy and paste that block (including the BEGIN and END armor lines) into
a text editor and save it as ipsec-ca.crt.
Alternately, copy the CA file from the PKI storage directory and copy it from
TNSR using scp or similar. The file is located in
/etc/pki/tls/tnsr/CA/<name>.crt, for example,
/etc/pki/tls/tnsr/CA/ipsec-ca.crt.
IKEv2 Server Configuration¶
With the RADIUS server and PKI structure in place, now it is time to configure the remote access IPsec instance.
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 3
tnsr(config-ipip)# source ipv4 address 203.0.113.2
tnsr(config-ipip)# exit
tnsr(config)#
The source IP address must exist on a TNSR interface.
Note
This example uses an instance ID of 3, assuming that there are multiple
other IPsec tunnels already in the configuration. Any other alternate ID
can be used so long as it does not conflict with existing tunnels.
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 3
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 tunnel to use eap-radius. This
directs the IPsec daemon to use the RADIUS server defined by ipsec
global-options eap-radius server-group.
strt tnsr(config-ipsec-crypto-ike)# authentication remote
strt tnsr(config-ike-authentication)# round 1
strt tnsr(config-ike-authentication-round)# eap-radius
strt tnsr(config-ike-authentication-round)# exit
strt 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.221.100 to 10.2.221.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 ipip3
tnsr(config-interface)# enable
tnsr(config-interface)# ip address 10.2.221.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.