Advanced configuration, performance and scalability¶

In this section we focus on parameters useful to tune the scalability and performance of IKE.

Initiator-only
Logging
Extended Sequence Number (ESN)
Replay window size
Virtual IPs and configuration attributes
Retransmission constants
Dead Peer Detection (DPD)
Lifetime of SA acquire messages
DoS protection
IKE worker threads
IKE SA hash table parameters
IPsec SP hash table parameters
Reverse route injection
- Global install-routes option for non-svti child SAs
- Per security-policy inject-routes option, for svti child SAs
IKEv2 Mobility and Multihoming Protocol (MOBIKE)
SNMP
Manually controlling SAs
Post-quantum Cryptography
- PPKs
IKE Command reference

Initiator-only ¶

The IKE daemon can operate in an initiator-only mode. In this mode, the Host Network Accelerator solely acts as an initiator for all IKE tunnels, and any tunnel initiate requests from remote peers will be rejected.

By default, this option is set to false. It is essential to understand that changing this option will cause the IKE daemon to restart, thereby terminating all existing tunnels.

vsr running config# / vrf main ike global-options initiator-only true

Logging ¶

The IKE service is liable to issue many log messages. The verbosity of these logs is configurable per subsystem.

Messages issued by the IKE service are classified in 5 levels:

0	Very basic auditing logs, (e.g. SA up/SA down)
1	Generic control flow with errors, a good default to see whats going on
2	More detailed debugging control flow
3	Including RAW data dumps in hex
4	Also include sensitive material in dumps, e.g. keys

Messages may be issued by the following subsystems:

asn1	Low-level encoding/decoding (ASN.1, X.509 etc.)
child	CHILD_SA/IPsec SA processing
config	Configuration management and plugins
daemon	Main daemon setup/cleanup/signal handling
encoding	Packet encoding/decoding encryption/decryption operations
ike	IKE_SA/ISAKMP SA processing
ipsec	Libipsec library messages
job	Jobs queuing/processing and thread pool management
kernel	IPsec/Networking kernel interface
manager	IKE_SA manager, handling synchronization for IKE_SA access
network	IKE network communication

The logs may be sent to syslog facilities daemon and authpriv.

The default configuration for ike logs is the following:

vsr> show config / vrf main ike logging
logging
    daemon
        default 0
        ..
    authpriv
        default disable
        ..
    ..

This configuration means that:

messages of level 0 from all subsystems are sent to syslog facility daemon,
no message from any subsystem is sent to syslog facility authpriv.

To alter this configuration, use the following command:

/ vrf main ike logging FACILITY SUBSYSTEM LEVEL

Where:

FACILITY is the syslog facility (daemon or authpriv),
SUBSYSTEM is the subsystem (see IKE log subsystems), or default to specify the default log level for all subsystems,
LEVEL is the maximum log level of messages in the specified subsystem, (see IKE log levels) or disable to disable all messages,

Example

The following commands modify which log messages are sent to facility authpriv:

messages up to level 2 from the ike subsystem are logged to facility authpriv,
messages up to level 1 from other subsystems are logged to facility authpriv.

vsr running config# / vrf main ike logging authpriv default 1
vsr running config# / vrf main ike logging authpriv ike 2

Note

Depending on the configuration, messages may be logged twice, once in facility daemon, and a second time in facility authpriv.

According to the configuration, log messages are sent to the daemon and/or authpriv syslog facilities with the notice severity. The severity is not configurable.

Extended Sequence Number (ESN)¶

With throughputs getting higher and higher, the 32 bit IPsec sequence number may reach its maximum value before it is expected, so much that an Extended Sequence Number (ESN) option was defined (see RFC 4304), that extends the sequence number to 64 bits.

The use of ESN can be configured in each esp-proposal or ah-proposal in the ipsec-policy-template (or VPN ipsec-policy). By default, ESN is disabled.

Require the use of ESN:

vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 1 enc-alg aes128-cbc
vsr running config#! / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 1 auth-alg hmac-sha256
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 1 esn true

Refuse the use of ESN (default behavior):

vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 2 enc-alg aes128-cbc
vsr running config#! / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 2 auth-alg hmac-sha256
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 2 esn false

To specify that ESN is not mandatory but should be negotiated, specify both esn true and esn false, by order of preference:

vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 3 enc-alg aes128-cbc
vsr running config#! / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 3 auth-alg hmac-sha256
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 3 esn true
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 3 esn false

If no esn statement is specified, then ESN is disabled.

Replay window size ¶

There is no guarantee that IPsec packets are received by the security gateway in the same order as they were sent. With throughputs getting higher and higher, out-of-order IPsec packets may be dropped by the IPsec replay protection system if their lateness exceeds the replay window size. The size of the replay window can be increased to avoid such problem.

The replay window size option can be configured in the ipsec-policy-template (or VPN ipsec-policy):

vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 replay-window 4096

replay-window is an integer number of packets, in the range 0 to 4096 packets (default 32, 0 disables replay protection).

Note that the replay window size is a local choice, it does not impact the replay window size chosen by the remote peer.

Virtual IPs and configuration attributes ¶

A device may request internal addresses (also known as VIPs) as well as configuration attributes, via an IKEv2 Configuration Payload (see RFC 7296) or via the IKEv1 Mode Config extension. The information exchanged is similar to what the device would acquire with DHCP if it were directly connected to a LAN.

When receiving a Configuration Payload request, the IKE peer is expected to return at most one VIP per requested INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS attribute, and any number and type of additional configuration attributes (whether or not they were listed in the request).

The Host Network Accelerator supports sending and replying to Configuration Payload requests.

Requesting a virtual IP ¶

The Host Network Accelerator may request VIPs when acting as the initiator of an IKE negotiation.

In addition to the requested VIPs, the reply may include additional configuration attributes.

To request one or more VIPs, use the vip-request list in the vpn definition:

vsr running config# / vrf main ike vpn vpn-to-hq vip-request 0.0.0.0
vsr running config# / vrf main ike vpn vpn-to-hq vip-request ::

This example requests one IPv4 and one IPv6 VIP.

By default, the VIPs assigned by and received from the peer will be installed on the same network interface as the local address used for the IKE negotiation, with a prefix length of 32 for IPv4 and 128 for IPv6.

It is possible to specify another interface, in the global-options section:

vsr running config# / vrf main ike global-options install-vip-on loopback0

The VIPs are encoded as INTERNAL_IP4_ADDRESS for IPv4 VIPs, and INTERNAL_IP6_ADDRESS for IPv6 VIPs.

The Host Network Accelerator also handles the following attributes:

INTERNAL_IP4_DNS: add the IPv4 address in the list of the device DNS servers.
INTERNAL_IP6_DNS: add the IPv6 address in the list of the device DNS servers.

All other attributes are ignored.

Assigning a virtual IP and configuration attributes from a pool ¶

The Host Network Accelerator may reply to Configuration Requests that request a VIP, when acting as the responder of an IKE negotiation.

To proceed, the responder maintains one or more pools of VIPs:

vsr running config# / vrf main ike pool my-pool address 192.168.1.1-192.168.2.127
vsr running config# / vrf main ike pool my-pool dns 192.168.3.99
vsr running config# / vrf main ike pool my-pool nbns 192.168.3.99
vsr running config# / vrf main ike pool my-pool dhcp 192.168.3.100
vsr running config# / vrf main ike pool my-pool subnet 172.16.0.0/12
vsr running config# / vrf main ike pool my-pool subnet fc00:1234::/64
vsr running config# / vrf main ike pool my-pool netmask 255.240.0.0

Supported attributes:

CLI keyword	Configuration attribute	Code	Description
`address`	INTERNAL_IP4_ADDRESS	1	List of VIPs that can be assigned. Each list item can be a single address, a range of addresses or a subnet
`address`	INTERNAL_IP6_ADDRESS	8
`dns`	INTERNAL_IP4_DNS	3	Optional list of DNS server addresses
`dns`	INTERNAL_IP6_DNS	10	Optional list of DNS server addresses
`nbns`	INTERNAL_IP4_NBNS	4	Optional list of NBNS server addresses
`nbns`	INTERNAL_IP6_NBNS	11	Optional list of NBNS server addresses
`dhcp`	INTERNAL_IP4_DHCP	6	Optional list of DHCP server addresses
`dhcp`	INTERNAL_IP6_DHCP	12	Optional list of DHCP server addresses
`subnet`	INTERNAL_IP4_SUBNET	13	Optional list of subnets protected by the responder
`subnet`	INTERNAL_IP6_SUBNET	15	Optional list of subnets protected by the responder
`netmask`	INTERNAL_IP4_NETMASK	2	Optional value for the internal network’s netmask
`netmask`	INTERNAL_IP6_NETMASK	9	Optional value for the internal network’s netmask

A vpn can then reference a list of pools in its configuration:

vsr running config# / vrf main ike vpn vpn-secgw vip-pool my-pool

To include this dynamically assigned address in a security policy, make sure that no remote-ts is configured, or at least that the remote-ts subnet is unset (other fields such as the protocol may still be specified):

vsr running config# / vrf main ike vpn vpn-secgw security-policy dynamic-vip local-ts subnet 10.100.0.64/26
vsr running config# / vrf main ike vpn vpn-secgw security-policy dynamic-vip remote-ts protocol 6

If an IKE initiator requests a VIP, it will be assigned one of the addresses in the VIP pools, and the optional attributes (dns, nbns, dhcp…).

Warning

If IKE HA is enabled, then HA-compatible VIP pools, defined in the ha sub-context, must be used instead. IP pools defined directly in the ike context are not synchronized between the master and the backup node. (see IKE HA-compatible virtual IP pools).

Assigning a virtual IP and configuration attributes from a RADIUS server ¶

When using Remote peer authentication by EAP via RADIUS or Remote peer authentication by PSK via RADIUS, the RADIUS server may return various attributes. If the initiator sent a Configuration Request, some of the RADIUS attributes may be transmitted in the Configuration Reply.

To proceed, the vpn must include the radius keyword in the list of VIP pools:

vsr running config# / vrf main ike vpn vpn-secgw ike-policy remote-auth-method eap-radius
vsr running config# / vrf main ike vpn vpn-secgw vip-pool radius

Note

The radius keyword does not refer to an actual VIP pool. Instead, each IKE SA will have its own dedicated pool created from the RADIUS attributes received with the successful authentication of the RADIUS user. This pool is not shared with any other IKE SA, even those using the same RADIUS user.

If the initiator sends a Configuration Request, various RADIUS attributes may be converted to IKE configuration attributes and sent with the Configuration Reply (see RADIUS attribute support).

Retransmission constants ¶

As recommended in RFC 7296#section-2.4, the IKE daemon uses an exponential backoff algorithm to calculate the timeout of packets before retransmission. The timeout grows exponentially with the number of tries.

The retransmission constants can be configured in the global-options section:

vsr running config# / vrf main ike global-options retransmit-tries 3
vsr running config# / vrf main ike global-options retransmit-timeout 3.0
vsr running config# / vrf main ike global-options retransmit-base 1.0
vsr running config# / vrf main ike global-options retransmit-jitter 20
vsr running config# / vrf main ike global-options retransmit-limit 12

retransmit-tries is an integer value ranging from 0 to 100 (default 5).
retransmit-timeout is a decimal number of seconds ranging from 0.000 to 60.000 (default 4.0).
retransmit-base is a decimal multiplier ranging from 0.000 to 10.000 (default 1.8).
retransmit-jitter is a percent ranging from 0 to 20 (default 0).
retransmit-limit is an integer value in seconds ranging from 0 to 100 (default 0).

Basic settings ¶

With default values of the retransmission constants, retransmission timeout is calculated according to the formula:

timeout_try = retransmit-timeout × retransmit-base^try

Where try ranges from 0 to retransmit-tries. After retransmit-tries unsuccessful retransmissions, the IKE daemon gives up the retransmission.

With the default values, in case the peer does not reply to an IKE message, packets will be retransmitted as follows:

Retransmission	Formula	Relative timeout	Total timeout
Try 0	4 × 1.8⁰	4s	4s
Try 1	4 × 1.8¹	7s	11s
Try 2	4 × 1.8²	13s	24s
Try 3	4 × 1.8³	23s	47s
Try 4	4 × 1.8⁴	42s	89s
Try 5	4 × 1.8⁵	76s	165s

Retransmit-limit ¶

In order to prevent calculated timeout from growing exponentially to very large values, it is possible to cap it to the value of retransmit-limit. A value of 0 disables this limit. With retransmit-limit configured, the above formula becomes:

timeout-with-limit_try = min(retransmit-limit, retransmit-timeout × retransmit-base^try)

With the default values and retransmit-limit set to 40, in case the peer does not reply to an IKE message, packets will be retransmitted as follows:

Retransmission	Formula	Relative timeout	Total timeout
Try 0	4 × 1.8⁰, limit 40	4s	4s
Try 1	4 × 1.8¹, limit 40	7s	11s
Try 2	4 × 1.8², limit 40	13s	24s
Try 3	4 × 1.8³, limit 40	23s	47s
Try 4	4 × 1.8⁴, limit 40	40s	87s
Try 5	4 × 1.8⁵, limit 40	40s	127s

Retransmit-jitter ¶

In order to avoid synchronization between parallel negotiations, it is possible to add a jitter in the calculation of retransmit timeouts using the retransmit-jitter parameter. The calculated timeout is reduced by a random percentage ranging from 0 to retransmit-jitter. A value of 0 disables the jitter.

With retransmit-jitter configured, the above formula becomes:

timeout_try = timeout-with-limit_try × (1 - random(0, retransmit-jitter) / 100)

If retransmit-jitter is configured as 20, the timeout calculation will be as follows:

Retransmission	Formula	Relative timeout		Total timeout
Retransmission	Formula	Range	Example	Range	Example
Try 0	(4 × 1.8⁰, limit 40) - rand(0 to 20%)	3.2s-4s	3.7s	3.2s-4s	3.7s
Try 1	(4 × 1.8¹, limit 40) - rand(0 to 20%)	5.6s-7s	6.8s	8.8s-11s	10.5s
Try 2	(4 × 1.8², limit 40) - rand(0 to 20%)	10.4s-13s	12.1s	19.2s-24s	22.6s
Try 3	(4 × 1.8³, limit 40) - rand(0 to 20%)	18.4s-23s	19.2s	37.6s-47s	41.8s
Try 4	(4 × 1.8⁴, limit 40) - rand(0 to 20%)	32s-40s	38.7s	69.6s-87s	80.5s
Try 5	(4 × 1.8⁵, limit 40) - rand(0 to 20%)	32s-40s	34.5s	101.6s-127s	115s

Dead Peer Detection (DPD)¶

The IKE daemon considers receiving IKE traffic from an IKE SA as a proof of liveness, as well as receiving IPsec traffic processed by one of its child SAs.

If no cryptographically protected messages have been received on an IKE SA or any of its child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. This is called DPD.

The use of DPD can be enabled in the ike-policy-template (or in the VPN ike-policy):

dpd-delay is a time duration. If no proof of liveness of an IKE SA has been received for this duration, then an active DPD exchange is initiated (default 0, which disables DPD).

In IKEv2, an active DPD exchange is initiated by sending an empty informational request. Like all IKEv2 requests, this message must be acknowledged by the peer; if the peer does not reply, then the retransmission mechanism starts and the request will be retransmitted according to an exponential backoff algorithm, as described in Retransmission constants. The total timeout with the default parameters is 165s.

In IKEv1, an active DPD exchange is initiated by sending an R-U-THERE informational message. The peer is supposed to send an R-U-THERE-ACK informational message in response, but any proof of liveness will be accepted. The IKE daemon will continue sending R-U-THERE messages every dpd-delay seconds until a proof of the peer’s liveness is received or a DPD timeout occurs. Although the retransmission mechanism is not involved, the DPD total timeout is calculated as the total retransmission timeout, so that it matches the total timeout of IKEv2 DPD.

If an active DPD exchange times out, the IKE SA is terminated. The action to perform to each of its child SAs is configured in the ipsec-policy-template (or in the VPN ipsec-policy):

dpd-action is one of:
- clear closes the child SA and does not take further action.
- restart immediately tries to re-negotiate the child SA under a fresh IKE SA. This is the default value.
- trap installs a trap policy, which will catch matching traffic and try to re-negotiate the tunnel on-demand.

vsr running config# / vrf main ike ike-policy-template iketemp1 ike-proposal 1 enc-alg aes128-cbc
vsr running config#! / vrf main ike ike-policy-template iketemp1 ike-proposal 1 auth-alg hmac-sha512
vsr running config#! / vrf main ike ike-policy-template iketemp1 ike-proposal 1 dh-group modp2048
vsr running config# / vrf main ike ike-policy-template iketemp1 dpd-delay 10s
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 1 enc-alg aes128-cbc
vsr running config#! / vrf main ike ipsec-policy-template ipsectemp1 esp-proposal 1 auth-alg hmac-sha256
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 start-action none
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 close-action none
vsr running config# / vrf main ike ipsec-policy-template ipsectemp1 dpd-action clear
vsr running config# / vrf main ike vpn vpn-hq ike-policy template iketemp1
vsr running config#! / vrf main ike vpn vpn-hq ipsec-policy template ipsectemp1

See also

RFC 7296#section-2.4 for details about IKEv2 DPD.
RFC 3706 for details about IKEv1 DPD.

Lifetime of SA acquire messages ¶

By default IKE negotiations are triggered by outgoing traffic (ipsec-policy-template start-action trap).

When an outgoing packet matches a security policy that requires IPsec protection, but no suitable SA is available, an SA acquire message is raised to trigger the negotiation and a temporary IPsec SA is created in the IPsec stack.

This acquire SA prevents further acquire messages to be raised until the negotiation succeeds, or the acquire SA times out.

The default lifetime of an acquire SA is 30 seconds, which is smaller than the total retransmission time of an IKE message that would receive no answer, with default retransmission constants.

This lifetime may be adjusted in the global-options section:

vsr running config# / vrf main ike global-options acquire-timeout 60

acquire-timeout is an integer number of seconds (default 30).

DoS protection ¶

The IKE daemon provides Denial of Service (DoS) protection using cookies and aggressiveness checks.

All DoS protection mechanisms are configured in the global-options dos-protection section.

vsr running config# / vrf main ike global-options dos-protection cookie-threshold 12
vsr running config# / vrf main ike global-options dos-protection block-threshold 6
vsr running config# / vrf main ike global-options dos-protection init-limit-half-open 100
vsr running config# / vrf main ike global-options dos-protection init-limit-job-load 1
vsr running config# / vrf main ike global-options dos-protection ike-sa-limit 2000

cookie-threshold is the number of half-open IKE SAs that activate the cookie mechanism. It is an integer number or the keyword always (default 10). 0 disables the cookie mechanism. always activates it whatever the number of half-open SAs.
block-threshold is the maximum number of half-open IKE SAs for a single peer IP. It is an integer number (default 5). 0 disables the limit.
init-limit-half-open fixes a limit to the number of half open IKE SAs. New IKE connections are refused if this limit is reached. It is an integer number (default 0). 0 disables the limit.
init-limit-job-load fixes a limit to the number of pending jobs waiting for an available thread. New IKE connections are refused if this limit is reached. It is an integer number (default 0). 0 disables the limit.
ike-sa-limit is the number of established IKE SAs after which all new connection attempts will be blocked (default 0). 0 disables the limit.

IKE worker threads ¶

The IKE daemon is a multi-threaded application.

The total number of threads it uses may be configured in the global-options section.

vsr running config# / vrf main ike global-options threads 20

threads is an 32 bit integer (default 16).

IKE SA hash table parameters ¶

The IKE SA hash table size can be increased to improve performance when a high number of SAs is managed by the IKE daemon. It can be split into segments to improve performance when a high number of SAs is managed by the IKE daemon on multiple cores. Each segment will get its own lock.

It can be configured in the global-options section.

vsr running config# / vrf main ike global-options sa-table-size 128
vsr running config# / vrf main ike global-options sa-table-segments 16

sa-table-size is the size of the SA hash table (default 1).
sa-table-segments is the number of segments (default 1).

IPsec SP hash table parameters ¶

The IPsec security policy database (SPD) is an ordered list of rules, the security policies (SPs), that specify what IPsec processing must be applied to packets. They are composed of a packet selector (direction, source subnet, destination subnet, protocol, port) and an action (esp, ah, pass or drop). By default, these SPs are stored in a linked list. The time to browse this list increases with the number of SPs in O(n).

When the IKE daemon establishes a child SA, it configures SPs in the IPsec stack. If the number of SPs grows, the time to add SPs grows in O(n), which slows down the negotiation rate.

When the network stack processes traffic, it looks up for the IPsec policy to apply to outbound and inbound packets. If the number of SPs grows, the time to lookup for the right policy grows in O(n), which slows down the throughput, regardless if packets need IPsec processing or not.

To solve this scalability issue, the IPsec stack maintains a hash table of security policies. SPs are hashed based on the source and destination address of their selector. These addresses are subnets with variable prefix lengths, which prevents from hashing on all bits of the addresses. Some SPs cannot be hashed because their selector is too wide (the address prefix lengths are too small). These un-hashed SPs are stored in the linked list.

Thresholds are defined, to select which SPs will be hashed and how many bits of address will be included in the hash key:

vsr running config# / vrf main ike global-options sp-hash-ipv4 local 16 remote 24
vsr running config# / vrf main ike global-options sp-hash-ipv6 local 56 remote 64

sp-hash-ipv4 local and remote are the local and remote address minimum prefix lengths of hashed IPv4 SPs. They range from 0 to 32 (default 32).
sp-hash-ipv6 local and remote are the local and remote address minimum prefix lengths of hashed IPv6 SPs. They range from 0 to 128 (default 128).

SPs whose local and remote address prefix lengths are greater or equal to the thresholds are hashed (which speeds up the lookup and insertion), others are simply looked up in sequence. For hashed SPs, the high order bits of the address (up to the threshold) are included in the hash key calculation.

Example:

dir out src 10.22.0.0/20 dst 10.24.1.0/24 => hashed
dir out src 10.22.0.0/16 dst 10.24.0.0/16 => unhashed
dir in  src 10.24.1.1/32 dst 10.22.0.0/16 => hashed

dir out src 3ffe:304:124:2200::/60 dst 3ffe:304:124:2401::/64 => hashed
dir out src 3ffe:304:124:2200::/56 dst 3ffe:304:124:2400::/56 => unhashed
dir in  src 3ffe:304:124:2401::2/128 dst 3ffe:304:124:2200::/56 => hashed

Hash thresholds not only determine which policies will be hashed, but also the number of bits of the local and remote address that will be used to calculate the hash key. Big thresholds mean potentially fewer hashed policies, but better distribution in the hash table, and vice versa.

A good trade off must be found depending on the prefix lengths used in the SPD.

Reverse route injection ¶

Global install-routes option for non-svti child SAs ¶

Routes can be inserted into a separate routing table for established IPsec tunnels. This enables to inject routes to the remote network discovered during an IKE negotiation.

vsr running config# / vrf main ike global-options install-routes true
vsr running config# / vrf main ike global-options routing-table 230
vsr running config# / vrf main ike global-options routing-table-prio 230

install-routes activates or deactivates route installation (default false).
routing-table is the number of the routing table in which routes will be injected (Default 220).
routing-table-prio is the priority of the Policy-Based Routing (PBR) rule that requests to lookup in the routing table (default 220).

If the option is enabled, then when a child SA is established, a route is added to the remote-ts, via the same next-hop as the route to the remote IKE peer.

Note

This global option applies to all non-SVTI child SAs, i.e. child SAs derived from a security-policy without an svti-id-out parameter.

Per security-policy inject-routes option, for svti child SAs ¶

For several reasons, the install-routes global option does not apply to SVTI child SAs (i.e. child SAs derived from a security-policy with an svti-id-out parameter):

the next-hop would typically be the referenced SVTI interface (or a neighbor address directly connected to the SVTI interface) instead of the next-hop to the IKE peer,
it is quite tricky to find the referenced SVTI, supposing that it exists: one must find an SVTI in an unpredictable VRF, based on its (svti-id, link-vrf) pair,
the traffic selectors when using SVTIs are often wildcards (0.0.0.0/0), or may overlap between 2 SVTIs. In this case, adding a route is nonsense and dangerous.
the SVTI may be cross-VRF (this is often the reason why one uses them), in which case the SVTI is in a VRF different from IKE. The route needs to be installed in the SVTI VRF, not the IKE VRF.

However, dynamically adding routes to the discovered remote-ts remains useful in some use cases with SVTI interfaces, for example when a single SVTI is used for concentrating IPsec connections while performing cross-VRF IPsec, rather than for doing route-based IPsec.

For this purpose, a per security-policy option exists, named inject-routes. The next-hop must be explicitly specified, and optionally a VRF, a routing table id or an L3VRF.

vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel local-ts subnet 192.168.0.0/16
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel remote-ts subnet 10.0.0.0/8
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel svti-id-out 100
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel svti-id-in 100
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel inject-routes next-hop svti100
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel inject-routes vrf trusted
vsr running config# / vrf untrusted ike vpn myvpn security-policy mytunnel inject-routes table 300

Of course, the svti100 interface must exist in VRF trusted, with a link-VRF equal to the IKE VRF (untrusted), and a PBR rule must exist in VRF trusted, that requests to lookup in table 300.

The parameters of the inject-routes option are:

next-hop specifies the next hop (IP address or interface name) (mandatory)
vrf is the route VRF (default, the same as IKE)
table is the routing table id (default: the main table, i.e. 254)
l3vrf is the route L3VRF (optional. Options table and l3vrf are exclusive)

IKEv2 Mobility and Multihoming Protocol (MOBIKE)¶

MOBIKE (RFC 4555) allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.

MOBIKE can be enabled in the IKE policy template:

vsr running config# / vrf untrusted ike ike-policy-template iketemp1 mobike true

Alternatively, it can be enabled in the VPN IKE policy:

vsr running config# / vrf untrusted ike vpn myvpn ike-policy mobike true

By default, when MOBIKE is enabled, the SA addresses are not modified if the routing path is still usable. Enabling mobike-prefer-best-path in global options dynamically changes this behavior: on routing change, if a cheaper path exists, the SA will be updated dynamically.

To enable the mobike-prefer-best-path option:

vsr running config# / vrf untrusted ike global-options mobike-prefer-best-path true

SNMP ¶

In order to monitor IKE through SNMP it must be explicitly enabled for each relevant VRF:

vsr running config# / vrf main ike global-options snmp true

Manually controlling SAs ¶

Showing SAs ¶

To show a summary of the IKE SAs, use the show ike ike-sa command:

vsr> show ike ike-sa
VPN    Local-Addr Local-ID          Remote-Addr  Remote-ID          State       Child-SAs
vpn-hq 192.0.2.1  localgw.6wind.net 198.51.100.1 remotegw.6wind.net established 1

Use option details for details on IKE and child SAs:

vsr> show ike ike-sa details
vpn-hq: #1, ESTABLISHED, IKEv2, ba564968485027c8_i d5bc00215d370faa_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  established 1s ago, rekeying in 13623s
  trunk: #2, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3342s, expires in 3959s
    in  c53d6ff3, 0 bytes, 0 packets
    out c0f25a26, 0 bytes, 0 packets
    local  192.168.0.0/24
    remote 192.168.99.0/24

To also display keys, use option with-keys:

vsr> show ike ike-sa with-keys
vpn-hq: #1, ESTABLISHED, IKEv2, ba564968485027c8_i d5bc00215d370faa_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  sk_ei 82be33972f24d7f151cc3f42f8304616fa4581d76628e583c6b3fbfd1175444d3d416802
  sk_er de6e6243ba8f554d43329b53de687b7c10a8db130b0be7619956f8ba1ece3f8ad484855b
  established 1s ago, rekeying in 13623s
  trunk: #2, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3342s, expires in 3959s
    in  c53d6ff3, 0 bytes, 0 packets
    out c0f25a26, 0 bytes, 0 packets
    encr-key-in acecaadf5b6e85f951e531b37ebd3c01442953d546a47213eb21f8eb022b035a89d52797
    encr-key-out e04c738d5202312c22cd4f5b15a7e0166d5e30ec0cae38557cb7f971085ee509b23d9203
    local  192.168.0.0/24
    remote 192.168.99.0/24

See also

The command reference for show ike.

Manually initiating SA negotiations ¶

To initiate an IKE negotiation, use the cmd ike initiate command.

To negotiate a child SA (and its IKE SA if not yet established), specify its security policy name:

vsr> cmd ike initiate child-sa security-policy trunk
initiating IKE_SA vpn-hq[3] to 198.51.100.1
received strongSwan vendor ID
received cert request for "CN=gnmi-ca"
sending cert request for "CN=gnmi-ca"
authentication of 'localgw.6wind.net' (myself) with pre-shared key
establishing CHILD_SA trunk{3}
authentication of 'remotegw.6wind.net' with pre-shared key successful
IKE_SA vpn-hq[3] established between 192.0.2.1[localgw.6wind.net]...198.51.100.1[remotegw.6wind.net]
scheduling rekeying in 13328s
maximum IKE_SA lifetime 14768s
CHILD_SA trunk{3} established with SPIs c8f78eab_i c691944f_o and TS 192.168.0.0/24 === 192.168.99.0/24

vsr> show ike ike-sa details
vpn-hq: #3, ESTABLISHED, IKEv2, 7851b3c100ac8792_i c8a276323bec2b30_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  established 1s ago, rekeying in 13327s
  trunk: #3, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3386s, expires in 3959s
    in  c8f78eab, 0 bytes, 0 packets
    out c691944f, 0 bytes, 0 packets
    local  192.168.0.0/24
    remote 192.168.99.0/24

It is also possible to establish a childless IKE SA as follows:

vsr> cmd ike initiate ike-sa vpn vpn-hq
initiating IKE_SA vpn-hq[2] to 198.51.100.1
received strongSwan vendor ID
received cert request for "CN=gnmi-ca"
sending cert request for "CN=gnmi-ca"
authentication of 'localgw.6wind.net' (myself) with pre-shared key
authentication of 'remotegw.6wind.net' with pre-shared key successful
IKE_SA vpn-hq[2] established between 192.0.2.1[localgw.6wind.net]...198.51.100.1[remotegw.6wind.net]
scheduling rekeying in 13165s
maximum IKE_SA lifetime 14605s

See also

The command reference for initiate child-sa.
The command reference for initiate ike-sa.

Manually rekeying SAs ¶

To manually rekey IKE and child SAs, use the cmd ike rekey command.

To rekey all IKE SAs issued from a given VPN, do as follows:

vsr> cmd ike rekey ike-sa vpn vpn-hq
Initiated 1 IKE SA rekey.

The IKE SAs are replaced by fresh ones, and the child SAs are inherited:

vsr> show ike ike-sa details
vpn-hq: #4, ESTABLISHED, IKEv2, 1510d7948135be02_i bdc028955ffd8ea1_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  established 1s ago, rekeying in 13061s
  trunk: #3, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 2s ago, rekeying in 3385s, expires in 3958s
    in  c8f78eab, 0 bytes, 0 packets
    out c691944f, 0 bytes, 0 packets
    local  192.168.0.0/24
    remote 192.168.99.0/24

To rekey all child SAs issued from a given security policy, do as follows:

vsr> cmd ike rekey child-sa security-policy trunk
Initiated 1 child SA rekey.

The IKE SAs are preserved, and the child SAs are replaced by fresh ones:

vsr> show ike ike-sa details
vpn-hq: #4, ESTABLISHED, IKEv2, 1510d7948135be02_i bdc028955ffd8ea1_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  established 2s ago, rekeying in 13060s
  trunk: #3, reqid 1, DELETED, TUNNEL    local  192.168.0.0/24
    remote 192.168.99.0/24
  trunk: #4, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3339s, expires in 3959s
    in  cd9cd177, 0 bytes, 0 packets
    out c579a482, 0 bytes, 0 packets
    local  192.168.0.0/24
    remote 192.168.99.0/24

A specific IKE or child SA may also be rekeyed, by specifying its unique ID.

The unique ID is the number prefixed with # right next to the SA name.

vsr> cmd ike rekey ike-sa unique-id 4
Initiated 1 IKE SA rekey.

vsr> cmd ike rekey child-sa unique-id 4
Initiated 1 child SA rekey.

Finally, IKE SAs may be reauthenticated with the cmd ike reauth command, identified by their VPN name or unique ID:

vsr> cmd ike reauth ike-sa vpn vpn-hq
Initiated 1 IKE SA reauthentication.

New IKE and child SAs are established (including the authentication step), and the old ones are deleted.

The order of operations of a reauth depends on the value of the make-before-break global option: if true, then the new SAs are negotiated and installed before deleting the old ones. If false, the old SAs are first deleted:

vsr> show config / vrf main ike global-options make-before-break
make-before-break false

See also

The command reference for rekey child-sa.
The command reference for rekey ike-sa.
The command reference for reauth ike-sa.

Manually clearing SAs ¶

IKE SAs and child SAs can be manually cleared using the flush command and specifying either the VPN name or the unique ID of the SA.

vsr> flush ike child-sa security-policy trunk
closing CHILD_SA trunk{5} with SPIs cbeece64_i (0 bytes) ce0b1baf_o (0 bytes) and TS 192.168.0.0/24 === 192.168.99.0/24

vsr> flush ike ike-sa vpn vpn-hq
deleting IKE_SA vpn-hq[5] between 192.0.2.1[localgw.6wind.net]...198.51.100.1[remotegw.6wind.net]

Specifying a VPN will flush all the SAs derived from it, flushing a single SA can be done by specifying its unique ID instead.

A specific IKE or child SA may also be cleared, by specifying its unique ID.

The SA unique ID can be found in the detailed output which is obtained by appending details to the show ike ike-sa command:

vsr> show ike ike-sa details
vpn-hq: #6, ESTABLISHED, IKEv2, 58f7c2905a765e84_i 6bc9d695a065b9cf_r
  local  'localgw.6wind.net' @ 192.0.2.1[500]
  remote 'remotegw.6wind.net' @ 198.51.100.1[500]
  aes256-gcm-128/prf:hmac-sha512/ecp256
  established 1s ago, rekeying in 13458s
  trunk: #6, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3450s, expires in 3959s
    in  c401e509, 0 bytes, 0 packets
    out cde6f0b0, 0 bytes, 0 packets
    local  192.168.0.0/24
    remote 192.168.99.0/24

The unique ID is the number prefixed with # right next to the SA name.

vsr> flush ike child-sa unique-id 6
closing CHILD_SA trunk{6} with SPIs c401e509_i (0 bytes) cde6f0b0_o (0 bytes) and TS 192.168.0.0/24 === 192.168.99.0/24

vsr> flush ike ike-sa unique-id 6
deleting IKE_SA vpn-hq[6] between 192.0.2.1[localgw.6wind.net]...198.51.100.1[remotegw.6wind.net]

See also

The command reference for flush child-sa.
The command reference for flush ike-sa.

Post-quantum Cryptography ¶

IKEv2 was not specifically designed to be secure against attacks using quantum computers and so additional configuration is required in order to attain that level of security.

PPKs ¶

A PPK is an additional secret used when generating keys for IKEv2 which allows for the process to become quantum secure, provided that the secret has sufficient entropy.

See also

RFC 8784

When responding to a connection attempt, a PPK is used only if the IKE peer requests a PPK identity that is configured locally. Otherwise, key generation will proceed without using a PPK.

To configure a PPK, an identity and secret pair must be declared within the ppk list:

vsr running config# / vrf main ike ppk foo id bar
vsr running config#! / vrf main ike ppk foo secret 0sd0AgKts8ZnIs5QAo+TiMPUPwu/iXmuIxZjXg6WzECV0=

vsr> show config / vrf main ike ppk
ppk foo
    id bar
    secret 0sd0AgKts8ZnIs5QAo+TiMPUPwu/iXmuIxZjXg6WzECV0=
    ..

PPK identities may alternatively be configured in hexadecimal form using id-hex. For example: id-hex 626172 is equivalent to id bar. This allows for the configuration of binary identities. For example: id-hex 070078f342ee0a.

Note

Each entry within ppk must use a different PPK identity, regardless of the format used. For example: a PPK with id bar must not exist alongside another PPK with id bar or id-hex 626172.

When initiating a connection attempt, a VPN will attempt to use a PPK only if one is specified through the ppk parameter:

vsr running config# / vrf main ike vpn vpn0 ppk foo

vsr> show config / vrf main ike vpn vpn0
vpn vpn0
    enabled true
    ike-policy
        template ikepol0
        ..
    ipsec-policy
        template ipsecpol0
        ..
    version 2
    local-address 10.125.0.1
    remote-address 10.125.0.2
    ppk foo
    security-policy vpn0sp0
        local-ts subnet 10.100.0.0/24
        remote-ts subnet 10.200.0.0/24
        action esp
        mode tunnel
        priority 0
        ..
    ..

If the IKE peer declines to use the PPK, key generation will proceed without using a PPK.

Note

This also forbids another PPK from being accepted when responding to connection attempts. If any other PPK is requested (or none at all), key generation will proceed without using a PPK.

PPK usage can be mandatory instead of optional, meaning that connection attempts will fail instead of proceeding without using a PPK.

This is configured through the require-ppk parameter within ike-policy-template and on a per VPN basis within ike-policy:

vsr running config# / vrf main ike ike-policy-template ikepol0 require-ppk true

vsr> show config nodefault / vrf main ike ike-policy-template ikepol0
ike-policy-template ikepol0
    ike-proposal 1
        aead-alg aes256-gcm-128
        prf-alg hmac-sha384
        dh-group ecp256
        ..
    require-ppk true
    ..

vsr running config# / vrf main ike vpn vpn0 ike-policy require-ppk false

vsr> show config / vrf main ike vpn vpn0 ike-policy
ike-policy
    template ikepol0
    require-ppk false
    ..

Whether an IKE SA was established using a PPK or not can be confirmed through ppk-used field in the ike-sa state:

vsr> show state / vrf main ike ike-sa
ike-sa unique-id 1
    name vpn0
    version 2
    state established
    local-address 10.125.0.1
    remote-address 10.125.0.2
    local-port 4500
    remote-port 4500
    local-id 10.125.0.1
    remote-id 10.125.0.2
    initiator-spi 8801bfe14fd6890d
    responder-spi 66ced33cfc78f360
    aead-alg aes256-gcm-128
    prf-alg hmac-sha384
    dh-group ecp256
    established-time 1
    rekey-time 14029
    udp-encap false
    mobike false
    ppk-used true
    child-sa unique-id 5
        name vpn0sp0
        state installed
        reqid 1
        protocol esp
        udp-encap false
        mobike false
        spi-in cc4e9765
        spi-out c5d793c6
        aead-alg aes256-gcm-128
        esn false
        bytes-in 0
        packets-in 0
        bytes-out 0
        packets-out 0
        installed-time 1
        rekey-time 3244
        life-time 3960
        local-ts subnet 10.100.0.0/24
        remote-ts subnet 10.200.0.0/24
        traffic-selectors
            local-ts 1 subnet 10.100.0.0/24
            remote-ts 1 subnet 10.200.0.0/24
            ..
        mode tunnel
        ..
    ..

Alternatively, show ike ike-sa details will append /PPK to the list of algorithms for an IKE SA only if a PPK was used:

vsr> show ike ike-sa details
vpn0: #1, ESTABLISHED, IKEv2, 8801bfe14fd6890d_i 66ced33cfc78f360_r
  local  '10.125.0.1' @ 10.125.0.1[4500]
  remote '10.125.0.2' @ 10.125.0.2[4500]
  aes256-gcm-128/prf:hmac-sha384/ecp256/PPK
  established 1s ago, rekeying in 14029s
  vpn0sp0: #5, reqid 1, INSTALLED, TUNNEL, esp:aes256-gcm-128
    installed 1s ago, rekeying in 3244s, expires in 3960s
    in  cc4e9765, 0 bytes, 0 packets
    out c5d793c6, 0 bytes, 0 packets
    local  10.100.0.0/24
    remote 10.200.0.0/24

IKE Command reference ¶

See also

For more details about advanced configuration, see the command reference.