You can authenticate IKE peers during IKE phase 1 with X.509 certificates (RFC 5280). Certificate-based authentication is a public key cryptographic system.

Each IKE gateway owns a private key and an associated certificate, containing identification information and the piece of equipment’s public key. The certificate is delivered and signed by a Certification Authority.

IKE peers trust this CA and believe that the CA will only deliver certificates to authorized equipment. An IKE gateway authenticates an IKE peer by verifying that its certificate was delivered by the CA (thanks to the CA’s certificate), and that the IKE peer owns the private key associated to its certificate.

When a new device is added to the network, it requests and gets a certificate from the CA. You do not need to reconfigure other devices.

A certificate is valid for a given period of time. When it expires, you must request a new certificate from the CA.

Certificate Revocation List
List of certificates established and later revoked by a Certification Authority. It informs that the listed certificates must no longer be trusted.
Certification Authority
Entity identified by a self-signed certificate and owning the associated private key.
Dynamic VPN

VPN whose SAs are dynamically established using the IKE protocol. The protocol also ensures dynamic re-keying, which improves security.

The establishment of a secure communication channel comprises two phases: IKE phase 1 and IKE phase 2.


Internet Key Exchange is a protocol developed specifically for IPsec which aims at providing authentication and key exchange mechanisms adapted to most of the situations which can occur on the Internet.

IKE can be used with two authentication methods:

  1. Use of pre-shared keys.
  2. Use of certificates.

Before configuring IKE, you must have configured authentication methods:

IKE assumes that the necessary certificates are already loaded on Turbo IPsec. Several certificates may be available on a single Turbo IPsec server. This is the case when a device belongs to different communities.

IKE Phase 1

IKEv1 name: ISAKMP phase

IKEv2 name: IKE SA phase

IKE gateways authenticate each other and negotiate cryptographic material (ISAKMP SAs for IKEv1, IKE SAS for IKEv2), to secure one or more IKE phase 2 exchanges.

IKE Phase 2

IKEv1 name: Quick Mode

IKEv2 name: Child SA phase

IKE gateways negotiate the IPsec security association themselves. One or more successive phase 2 exchanges are authenticated and encrypted thanks to cryptographic material negotiated during IKE phase 1.

IPsec rule

An IPsec rule specifies the IPsec policy applied to an IP flow going from one zone to another (basically applying IPsec, letting traffic in clear-text, or discarding traffic).

When a rule states to apply IPsec, the IPsec rule is linked to a VPN definition, which specifies the involved IPsec devices, the details of the IPsec cryptographic material, and the way it is negotiated.

An IPsec rule comprises two parts:

  • a filter that defines a traffic flow,
  • an action, which describes the IPsec processing applied to the traffic flow.

Several IPsec rules may be linked to the same VPN.

As traffic flow definitions may overlap, IPsec rules are ordered via a priority value.

If a packet matches two or more IPsec rules, the rule with the smallest priority applies. Two IPsec rules with the same priority should consequently not overlap, to avoid ambiguities.

Pre-shared key

You can authenticate IKE peers during IKE phase 1 with a pre-shared key. A pre-shared key is a secret key shared by two IKE peers to authenticate each other. This key must be loaded on both peers.

Pre-shared keys do not scale well: when you install a new device, you must generate a new pre-shared key for each remote device communicating with the new one, then load the key on the new device and on remote devices.

Security Association

The IPsec processing applied to a packet is defined by a Security Association. An SA is an agreement between two hosts, that defines notably:

  • the IP destination of the communication
  • the IPsec protocol to apply (AH or ESP), and its mode
  • cryptographic algorithms and keys

An SA is uniquely identified by the following tuple:

  • destination address
  • type of IPsec protocol (AH or ESP)
  • SPI

SAs are stored on each machine in a SAD. A pair of SAs is defined or negotiated for each IPsec rule and IPsec protocol.

Static VPN

VPN whose SAs are manually defined by the user. The secret keys are provided during configuration and do not change until a new configuration is issued.

Static VPNs are useful when you cannot or do not want to use IKE, for experimental platforms or when attempting to interoperate with a piece of equipment that does not implement IKE, for instance.


A VPN associates two IPsec devices acting as security gateways to secure traffic going from one to the other. A VPN defines the general rules to be applied to any traffic transiting from Turbo IPsec to another IPsec device.

You can configure two types of VPNs:

VPN template

A VPN template describes the level of security to be applied to a VPN. It is designed to alleviate the work of configuring VPNs.

You can either:

  • use 6WIND pre-defined templates, based on pre-shared keys or certificates, or,
  • define your own templates.


Designing new templates is a difficult task that requires a lot of security expertise. A bad configuration may lead to either:

  • security leaks, or,
  • very poor performance.
IP security secures traffic between two IPsec devices (Turbo IPsec and a remote device) that interconnect two sites. Each site may contain several security zones that require different handling in terms of security. A security zone can be a subnetwork or a single host. Two zones are interconnected through a connection secured by IPsec.