Advanced configuration, performance and scalability¶

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

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 running ike# show config 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:

vsr running 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 ike# logging
vsr running logging# authpriv
vsr running authpriv# default 1
vsr running authpriv# ike 2
vsr running authpriv# ..
vsr running logging# ..
vsr running ike#
vsr running ike# show config logging
logging
    daemon
        default 0
        ..
    authpriv
        default 1
        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 ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1# esn true
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        (...)
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            dh-group modp2048
            esn true
            ..
        ..
    ..

vsr running ike# show config
ike
    (...)
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            aead-alg aes128-gcm-128
            esn true
            ..
        ..
    ..

Refuse the use of ESN (default behavior):

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1# esn false
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            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 ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1# esn true
vsr running esp-proposal 1# esn false
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# ..

vsr running ike# show config
ike
    (...)
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            esn true
            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 ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# replay-window 4096
vsr running ipsec-policy-template ipsectemp1# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    ipsec-policy-template ipsectemp1
        esp-proposal 1
            enc-alg aes128-cbc
            auth-alg hmac-sha256
            ..
        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 Virtual Service Router supports sending and replying to Configuration Payload requests.

Requesting a virtual IP ¶

The Virtual Service Router 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 ike# vpn vpn-to-hq
vsr running vpn vpn-to-hq# vip-request 0.0.0.0
vsr running vpn vpn-to-hq# vip-request ::
vsr running vpn vpn-to-hq# ..
vsr running ike# commit

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 ike# global-options
vsr running global-options# install-vip-on loopback0
vsr running global-options# ..
vsr running ike# commit

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

The Virtual Service Router 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 Virtual Service Router 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 vrf main# ike
vsr running ike# pool my-pool
vsr running pool my-pool#! address 192.168.1.1-192.168.2.127
vsr running pool my-pool# dns 192.168.3.99
vsr running pool my-pool# nbns 192.168.3.99
vsr running pool my-pool# dhcp 192.168.3.100
vsr running pool my-pool# subnet 172.16.0.0/12
vsr running pool my-pool# subnet fc00:1234::/64
vsr running pool my-pool# netmask 255.240.0.0
vsr running pool my-pool# ..
vsr running ike#

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 ike# vpn vpn-secgw
vsr running vpn vpn-secgw# vip-pool my-pool
vsr running vpn vpn-secgw# ..
vsr running ike#

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 ike# vpn vpn-secgw
vsr running vpn vpn-secgw# security-policy dynamic-vip
vsr running security-policy dynamic-vip# local-ts subnet 10.100.0.64/26
vsr running security-policy dynamic-vip# remote-ts protocol 6
vsr running security-policy dynamic-vip# ..
vsr running vpn vpn-secgw# ..
vsr running ike#

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 ike# vpn vpn-secgw
vsr running vpn vpn-secgw# ike-policy remote-auth-method eap-radius
vsr running vpn vpn-secgw# vip-pool radius
vsr running vpn vpn-secgw# ..
vsr running ike#

Note

The radius keyword does not refer to an actual VIP pool. Instead, each IKE SA will have it’s 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, 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 negotiation.

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

vsr running ike# global-options
vsr running global-options# retransmit-tries 3
vsr running global-options# retransmit-timeout 3.0
vsr running global-options# retransmit-base 1.0
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    global-options
        (...)
        retransmit-tries 3
        retransmit-timeout 3.0
        retransmit-base 1.0
        ..
    ..

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).

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	Absolute timeout
1	4 × 1.8⁰	4s	4s
2	4 × 1.8¹	7s	11s
3	4 × 1.8²	13s	24s
4	4 × 1.8³	23s	47s
5	4 × 1.8⁴	42s	89s
giving up	4 × 1.8⁵	76s	165s

The total timeout can be calculated as follows:

total-timeout = retransmit-timeout × (retransmit-base^{retransmit-tries + 1} - 1) / (retransmit-base - 1)

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 ike# ike-policy-template iketemp1
vsr running ike-policy-template iketemp1# ike-proposal 1
vsr running ike-proposal 1#! enc-alg aes128-cbc
vsr running ike-proposal 1#! auth-alg hmac-sha512
vsr running ike-proposal 1#! dh-group modp2048
vsr running ike-proposal 1# ..
vsr running ike-policy-template iketemp1# dpd-delay 10s
vsr running ike-policy-template iketemp1# ..

vsr running ike# ipsec-policy-template ipsectemp1
vsr running ipsec-policy-template ipsectemp1# esp-proposal 1
vsr running esp-proposal 1#! enc-alg aes128-cbc
vsr running esp-proposal 1#! auth-alg hmac-sha256
vsr running esp-proposal 1# ..
vsr running ipsec-policy-template ipsectemp1# start-action none
vsr running ipsec-policy-template ipsectemp1# close-action none
vsr running ipsec-policy-template ipsectemp1# dpd-action clear
vsr running ipsec-policy-template ipsectemp1# ..

vsr running ike# vpn vpn-hq
vsr running vpn vpn-hq#! ike-policy template iketemp1
vsr running vpn vpn-hq#! ipsec-policy template ipsectemp1
(...)

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 ike# global-options
vsr running global-options# acquire-timeout 60
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
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 ike# global-options
vsr running global-options# dos-protection
vsr running dos-protection# cookie-threshold 12
vsr running dos-protection# block-threshold 6
vsr running dos-protection# init-limit-half-open 100
vsr running dos-protection# ike-sa-limit 2000
vsr running dos-protection# ..
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    global-options
        (...)
        dos-protection
            cookie-threshold 12
            block-threshold 6
            init-limit-half-open 100
            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 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 ike# global-options
vsr running global-options# show config
vsr running global-options# threads 20
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
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 ike# global-options
vsr running global-options# sa-table-size 128
vsr running global-options# sa-table-segments 16
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    global-options
        (...)
        sa-table-size 128
        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 ike# global-options
vsr running global-options# sp-hash-ipv4 local 16 remote 24
vsr running global-options# sp-hash-ipv6 local 56 remote 64
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    global-options
        (...)
        sp-hash-ipv4 local 16 remote 24
        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 ike# global-options
vsr running global-options# install-routes true
vsr running global-options# routing-table 230
vsr running global-options# routing-table-prio 230
vsr running global-options# ..
vsr running ike#

vsr running ike# show config nodefault
ike
    (...)
    global-options
        (...)
        install-routes true
        routing-table 230
        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
vsr running security-policy mytunnel# svti-id-out 100
vsr running security-policy mytunnel# svti-id-in 100
vsr running security-policy mytunnel# inject-routes
vsr running inject-routes#! next-hop svti100
vsr running inject-routes# vrf trusted
vsr running inject-routes# table 300
vsr running inject-routes# .. .. ..
vsr running ike#

vsr running ike# show config nodefault
    (...)
    vpn myvpn
        (...)
        security-policy mytunnel
            local-ts subnet 192.168.0.0/16
            remote-ts subnet 10.0.0.0/8
            svti-id-out 100
            svti-id-in 100
            inject-routes
                next-hop svti100
                vrf trusted
                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 main ike
vsr running ike# ike-policy-template my_policy_tmpl
vsr running ike-policy-template my_policy_tmpl# mobike true

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

vsr running config# / vrf main ike vpn my_vpn
vsr running vpn my_vpn#! ike-policy template my_policy_tmpl
vsr running vpn my_vpn#! ipsec-policy template my_ipsec_tmpl
vsr running vpn my_vpn# 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 ike# global-options
vsr running global-options# mobike-prefer-best-path true

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.

VPN names can be quickly gathered with the show command:

ha1# show ike vrf main ike-sa
VPN            Local-Addr Local-ID        Remote-Addr Remote-ID         State       Child-SAs
ike-dut-router 10.175.0.1 secgw.6wind.net 10.225.0.1  enodeb1.6wind.net established 1
ha1# flush ike ike-sa vrf main vpn ike-dut-router
deleting IKE_SA ike-dut-router[1] between 10.175.0.1[secgw.6wind.net]...10.225.0.1[enodeb1.6wind.net]

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

An SA’s unique ID can be found in the detailed output which is obtained by appending details to the flush command:

ha1# show ike vrf main ike-sa details
ike-dut-router: #7, ESTABLISHED, IKEv2, 83ff31f04e37d6e2_i b766b0b543471168_r
  local  'secgw.6wind.net' @ 10.175.0.1[500]
  remote 'enodeb1.6wind.net' @ 10.225.0.1[500]
  aes128-cbc/hmac-sha1/hmac-sha1/modp1024
  established 47s ago, rekeying in 13327s
  dut-router-win32: #42, reqid 4, INSTALLED, TUNNEL, esp:aes128-cbc/hmac-sha1
    installed 47s ago, rekeying in 3270s, expires in 3913s
    in  c5bbe2a3, svti-id 42, 0 bytes, 0 packets
    out cd6bba21, svti-id 42, 0 bytes, 0 packets
    local  10.100.1.0/24
    remote 10.200.0.1/32
ha1# flush ike child-sa vrf main unique-id 42
closing CHILD_SA dut-router-win32{42} with SPIs c5bbe2a3_i (0 bytes) cd6bba21_o (0 bytes) and TS 10.100.1.0/24 === 10.200.0.1/32
ha1# flush ike ike-sa vrf main unique-id 7
deleting IKE_SA ike-dut-router[7] between 10.175.0.1[secgw.6wind.net]...10.225.0.1[enodeb1.6wind.net]

The unique ID is the number prefixed with # right next to the SA’s name. In this example the unique ID of the IKE SA is 7 and that of the child SA is 42.

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