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
orauthpriv
),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 facilityauthpriv
,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 |
---|---|---|---|
|
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 |
INTERNAL_IP6_ADDRESS |
8 |
||
|
INTERNAL_IP4_DNS |
3 |
Optional list of DNS server addresses |
INTERNAL_IP6_DNS |
10 |
||
|
INTERNAL_IP4_NBNS |
4 |
Optional list of NBNS server addresses |
INTERNAL_IP6_NBNS |
11 |
||
|
INTERNAL_IP4_DHCP |
6 |
Optional list of DHCP server addresses |
INTERNAL_IP6_DHCP |
12 |
||
|
INTERNAL_IP4_SUBNET |
13 |
Optional list of subnets protected by the responder |
INTERNAL_IP6_SUBNET |
15 |
||
|
INTERNAL_IP4_NETMASK |
2 |
Optional value for the internal network’s netmask |
INTERNAL_IP6_NETMASK |
9 |
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:
timeouttry = retransmit-timeout × retransmit-basetry
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.80 |
4s |
4s |
2 |
4 × 1.81 |
7s |
11s |
3 |
4 × 1.82 |
13s |
24s |
4 |
4 × 1.83 |
23s |
47s |
5 |
4 × 1.84 |
42s |
89s |
giving up |
4 × 1.85 |
76s |
165s |
The total timeout can be calculated as follows:
total-timeout = retransmit-timeout × (retransmit-baseretransmit-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
(...)
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 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# init-limit-job-load 1
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
init-limit-job-load 1
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 keywordalways
(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 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
andremote
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
andremote
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. Optionstable
andl3vrf
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
See also
The command reference.