IPsec Terminology

Before delving too deeply into configuration there are a few terms used throughout the chapter which require explanation. Other terms are explained in more detail upon their use in configuration options.

IKE

IKE stands for Internet Key Exchange and comes in two different varieties: IKEv1 and IKEv2. Nearly all devices that support IPsec can use IKEv1. Most modern implementations also support IKEv2. The newer IKEv2 protocol is an updated version of IKE that solves some of the difficulties present in the earlier version. For example, IKEv2 has MOBIKE which is a standard for mobile clients that allows them to switch addresses dynamically. It also has built-in NAT traversal and standard mechanisms for reliability similar to DPD. In general IKEv2 provides a more stable and reliable experience provided both ends support it sufficiently.

ISAKMP Security Association

ISAKMP stands for Internet Security Association and Key Management Protocol. It gives both parties a mechanism by which they can set up a secure communications channel including exchanging keys and providing authentication.

An ISAKMP Security Association (ISAKMP SA or IKE SA) is a one-way policy which defines how traffic will be encrypted and handled. Each active IPsec tunnel will have two security associations, one for each direction. The ISAKMP Security Associations are setup between the public IP addresses for each endpoint. Knowledge of these active security associations is kept in the Security Association Database (SAD).

Security Policy

A security policy manages the complete specifications of the IPsec tunnel. As with security associations these are one-way, thus for each tunnel there will be one in each direction. These entries are kept in the Security Policy Database (SPD). The SPD is populated with two entries for each tunnel connection as soon as a tunnel is added. By contrast SAD entries only exist upon successful negotiation of the connection.

In pfSense software security policies for policy-based IPsec tunnels control which traffic will be intercepted by the kernel for delivery via IPsec.

Phase 1

There are two phases of negotiation for an IPsec tunnel. During phase 1 the two endpoints of a tunnel setup a secure channel between using ISAKMP to negotiate the IKE SA entries and exchange keys. This also includes authentication, checking identifiers, and checking the pre-shared keys (PSK) or certificates. When phase 1 is complete the two ends can exchange information securely, but they have not yet decided which traffic will traverse the tunnel or its encryption.

Phase 2

In phase 2 the two endpoints negotiate how to encrypt and send the data for the private hosts based on security policies. This part builds an entry referred to as a “Child SA”. This forms the connection used to transfer data between the endpoints and clients whose traffic is handled by those endpoints. If the policies on both side agree and a phase 2 child SA is successfully established the tunnel will be up and ready for use.

Mobile IPsec

Mobile IPsec refers to IPsec connections from individual client devices rather than site-to-site connections. This is also commonly called a “Road Warrior” or “Remote Access” style VPN.

Th main purpose of a mobile IPsec VPN is for users who are not in the office who need to connect back to the main network. Common use cases are for employees working from home, sales personnel using Wi-Fi on a business trip, or even the boss from his cabin via LTE modem.

Most of these use cases are forced to deal with dynamic IP addresses, unknown IP addresses, NAT (regular and Carrier Grade NAT), and other complications. Without a router or firewall supporting IPsec a traditional IPsec tunnel will not work.

In telecommuting scenarios, it’s usually undesirable and unnecessary to connect a entire home networks to the office network, and doing so can reduce security and introduce routing complications. This is where IPsec Mobile Clients are most useful.

Instead of relying on a fixed address for the remote end of the tunnel, Mobile IPsec uses authentication to allow distinguish between authorized users. For example, this could be a username and password with IKEv2 and EAP, a per-user Identifier and Pre-Shared Key pair, or a certificate.