Note
High Availability IKE requires an IPsec Application License.
High Availability IKE¶
High Availability Internet Key Exchange (HA IKE) is an IKE extension that enables to perform stateful synchronization of IKE between two HA nodes in active/backup mode.
HA IKE may be configured between two nodes forming an HA cluster: the IKE internal states (IKE SAs and CHILD SAs) and IPsec SAs sequence numbers are synchronized from the active node to the backup node.
If the HA state is switched between the two nodes, the new master node will be able to take over the IKE negotiations and IPsec dataplane traffic.
Overview¶
The HA state of a node can be statically configured using CLI/netconf or dynamically using the VRRP service.
HA IKE parameters are configured in the ha sub-context of ike.
Enter the ha sub-context on ha1:
ha1 running config# vrf main
ha1 running vrf main# ike
ha1 running ike# ha
ha1 running ha#!
Configure HA IKE parameters:
ha1 running ha#! node-id 1
ha1 running ha#! interface eth3
ha1 running ha#! local-address 10.150.0.1
ha1 running ha#! remote-address 10.150.0.2
ha1 running ha#! listen-ha-group ha-group1
ha1 running ha#
node-idis a unique identifier for this node in the HA cluster. It ranges from 1 to 15.interfaceis the network interface on which synchronization packets are exchangedlocal-addressandremote-addressare the IPv4 or IPv6 addresses of the two HA nodes.listen-ha-groupis the high-availability group that controls the activity state of this HA node. See High-availability Groups for more information.
Display HA IKE parameters:
ha1 running ha# show config
ha
enabled true
listen-ha-group my-ha-group
node-id 1
interface eth3
local-address 10.150.0.1
remote-address 10.150.0.2
seqnum-sync
oseq-shift 65536
sync-period-time 10s
sync-period-packets 2
..
..
On ha2, the node-id and interface must be adjusted and the local-address
and remote-address swapped:
ha2 running config# vrf main ike ha
ha2 running ha#! node-id 2
ha2 running ha#! interface eth3
ha2 running ha#! local-address 10.150.0.2
ha2 running ha#! remote-address 10.150.0.1
ha2 running ha#! listen-ha-group ha-group1
Use case: HA IKE cluster with VRRP¶
In this use case, two devices ha1 and ha2 are configured as a redundant security gateway, performing IKE negotiations with a remote security gateway SecGW.
The activity of each HA node is determined by the VRRP protocol (see VRRP command reference for details about VRRP).
The two HA devices must be configured exactly the same, except for HA parameters (VRRP and HA IKE).
ha1 CLI configuration¶
Configure device hostname:
vsr running config# system hostname ha1
vsr running config# commit
Configuration committed.
Configure the HA group:
vsr running config# ha group ha-group1
ha1 running group ha-group1#! ..
ha1 running ha#! ..
Note
The ha-group maintains the node high-availability state. It is controlled by
the VRRP protocol (via the notify-ha-group command) and monitored by HA IKE
(via the listen-ha-group command). Only one controller can be defined for
an ha-group.
Move to vrf main configuration:
ha1 running config#! vrf main
ha1 running vrf main#!
Configure the network interfaces (adapt port ids to your hardware):
ha1 running vrf main#! interface physical eth1
ha1 running physical eth1#! port pci-b0s3
ha1 running physical eth1#! ipv4 address 10.22.0.1/24
ha1 running physical eth1#! ..
ha1 running interface#! physical eth2
ha1 running physical eth2#! port pci-b0s4
ha1 running physical eth2#! ipv4 address 10.23.0.1/24
ha1 running physical eth2#! ..
ha1 running interface#! physical eth3
ha1 running physical eth3#! port pci-b0s5
ha1 running physical eth3#! ipv4 address 10.150.0.1/24
ha1 running physical eth3#! ..
ha1 running interface#! loopback loopback0
ha1 running loopback loopback0#! ipv4 address 10.175.0.1/32
ha1 running loopback loopback0#! ..
ha1 running interface#! ..
Configure routes:
ha1 running vrf main#! routing
ha1 running routing#! static
ha1 running static#! ipv4-route 10.250.0.0/24 next-hop 10.200.0.1
ha1 running static#! ipv4-route 10.225.0.0/24 next-hop 10.200.0.1
ha1 running static#! ..
ha1 running routing#! ..
Configure VRRP:
ha1 running vrf main#! interface vrrp vrrp51
ha1 running vrrp vrrp52#! vrid 1
ha1 running vrrp vrrp51#! link-interface eth1
ha1 running vrrp vrrp51#! priority 100
ha1 running vrrp vrrp51#! advertisement-interval 1000
ha1 running vrrp vrrp51#! virtual-address 10.100.0.2/24
ha1 running vrrp vrrp51#! ..
ha1 running interface#! vrrp vrrp52
ha1 running vrrp vrrp52#! vrid 1
ha1 running vrrp vrrp52#! link-interface eth2
ha1 running vrrp vrrp52#! priority 100
ha1 running vrrp vrrp52#! advertisement-interval 1000
ha1 running vrrp vrrp52#! virtual-address 10.200.0.2/24
ha1 running vrrp vrrp52#! ..
ha1 running interface#! ..
ha1 running vrf main#! vrrp group group1
ha1 running group group1#! instance vrrp51
ha1 running group group1#! instance vrrp52
ha1 running group group1#! notify-ha-group ha-group1
ha1 running group group1# ..
ha1 running vrrp# ..
Show the configuration:
ha1 running vrf main# show config nodefault
vrf main
interface
vrrp vrrp51
link-interface eth1
vrid 1
virtual-address 10.100.0.2/24
..
vrrp vrrp52
link-interface eth2
vrid 1
virtual-address 10.200.0.2/24
..
..
vrrp
group group1
instance vrrp51
instance vrrp52
notify-ha-group ha-group1
..
..
..
Configure IKE:
ha1 running vrf main# ike
ha1 running ike# ike-policy-template ike1
ha1 running ike-policy-template ike1# ike-proposal 1 enc-alg aes128-cbc auth-alg hmac-sha1 dh-group modp1024
ha1 running ike-policy-template ike1# rekey-time 2h
ha1 running ike-policy-template ike1# ..
ha1 running ike# ipsec-policy-template ipsec1
ha1 running ipsec-policy-template ipsec1# esp-proposal 1 enc-alg aes128-cbc auth-alg hmac-sha1 esn true
ha1 running ipsec-policy-template ipsec1# rekey-time 1h
ha1 running ipsec-policy-template ipsec1# replay-window 1024
ha1 running ipsec-policy-template ipsec1# ..
ha1 running ike# vpn vpn-secgw
ha1 running vpn vpn-secgw#! ike-policy template ike1
ha1 running vpn vpn-secgw#! ipsec-policy template ipsec1
ha1 running vpn vpn-secgw# local-address 10.175.0.1
ha1 running vpn vpn-secgw# remote-address 10.225.0.1
ha1 running vpn vpn-secgw# security-policy site-to-secgw-site
ha1 running security-policy site-to-secgw-site# local-ts subnet 10.100.0.64/26
ha1 running security-policy site-to-secgw-site# remote-ts subnet 10.250.0.192/26
ha1 running security-policy site-to-secgw-site# ..
ha1 running vpn vpn-secgw# ..
ha1 running ike# pre-shared-key secgw
ha1 running pre-shared-key secgw#! id 10.225.0.1
ha1 running pre-shared-key secgw#! secret 0sBzAyaM5PTcnTHi/yRA1lARpAoRetSzP8
ha1 running pre-shared-key secgw# ..
ha1 running ike#
Show IKE configuration:
ha1 running ike# show config nodefault
ike
pre-shared-key secgw
id 10.225.0.1
secret 0sBzAyaM5PTcnTHi/yRA1lARpAoRetSzP8
..
global-options
dos-protection
..
sp-hash-ipv4
sp-hash-ipv6
..
ike-policy-template ike1
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
..
rekey-time 2h
..
ipsec-policy-template ipsec1
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
esn true
..
replay-window 1024
..
vpn vpn-secgw
ike-policy
template ike1
..
ipsec-policy
template ipsec1
..
local-address 10.175.0.1
remote-address 10.225.0.1
security-policy site-to-secgw-site
local-ts subnet 10.100.0.64/26
remote-ts subnet 10.250.0.192/26
..
..
..
Configure HA IKE:
ha1 running ike# ha
ha1 running ha#! node-id 1
ha1 running ha#! interface eth3
ha1 running ha#! local-address 10.150.0.1
ha1 running ha#! remote-address 10.150.0.2
ha1 running ha#! listen-ha-group ha-group1
ha1 running ha# ..
ha1 running ike# commit
Configuration committed.
ha1 running ike#
Show HA IKE configuration:
ha1 running ike# show config nodefault ha
ha
listen-ha-group ha-group1
node-id 1
interface eth3
local-address 10.150.0.1
remote-address 10.150.0.2
seqnum-sync
..
..
ha2 CLI configuration¶
A similar configuration is used for ha2. The differences are the hostname, the physical interfaces addresses, VRRP parameters and IKE HA parameters.
The IKE parameters (except HA ones) must be strictly identical.
ha2 running config# show config nodefault
config
vrf main
interface
physical eth1
ipv4
address 10.22.0.2/24
..
..
physical eth2
ipv4
address 10.23.0.2/24
..
..
physical eth3
ipv4
address 10.150.0.2/24
..
..
loopback loopback0
ipv4
address 10.175.0.1/32
..
..
vrrp vrrp51
link-interface eth1
vrid 1
virtual-address 10.100.0.2/24
..
vrrp vrrp52
link-interface eth2
vrid 1
virtual-address 10.200.0.2/24
..
..
routing
static
ipv4-route 10.250.0.0/24
next-hop 10.200.0.1
..
ipv4-route 10.225.0.0/24
next-hop 10.200.0.1
..
..
..
vrrp
group group1
instance vrrp51
instance vrrp52
notify-ha-group ha-group1
..
..
ike
pre-shared-key secgw
id 10.225.0.1
secret 0sBzAyaM5PTcnTHi/yRA1lARpAoRetSzP8
..
global-options
dos-protection
..
sp-hash-ipv4
sp-hash-ipv6
..
ha
listen-ha-group ha-group1
node-id 2
interface eth3
local-address 10.150.0.2
remote-address 10.150.0.1
seqnum-sync
..
..
ike-policy-template ike1
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
..
rekey-time 2h
..
ipsec-policy-template ipsec1
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
esn true
..
replay-window 1024
..
vpn vpn-secgw
ike-policy
template ike1
..
ipsec-policy
template ipsec1
..
local-address 10.175.0.1
remote-address 10.225.0.1
security-policy site-to-secgw-site
local-ts subnet 10.100.0.64/26
remote-ts subnet 10.250.0.192/26
..
..
..
..
system
hostname ha2
..
ha
group ha-group1
..
..
..
Advanced options¶
Sequence number synchronization parameters¶
IPsec SAs sequence numbers are regularly synchronized from the active node to the backup node. In case of switch over, this enables the new master node to take over the IPsec dataplane processing with proper sequence numbers:
For an output SA, the output sequence number 1 on the backup node should be greater or equal to the last sequence number used by this SA on the master node. Otherwise, the remote IPsec peer is likely to drop some IPsec packets sent by the new master until the sequence numbers comply to its replay window state.
For an input SA, the input sequence number 2 on the backup node should be close to the highest sequence number received on the master node. Otherwise the new master node is vulnerable to accepting replayed packets sent by an attacker, because its replay window is too late.
- 1
i.e. the record of the highest SA sequence number of a sent packet protected with this SA
- 2
i.e. the record of the highest SA sequence number of a received packet protected with this SA
The pace at which sequence number synchronization is performed is configurable
in the ha seqnum-sync sub-context:
ha1 running vrf main# ike ha seqnum-sync
ha1 running seqnum-sync# sync-period-time 10s
ha1 running seqnum-sync# sync-period-packets 2
ha1 running seqnum-sync# oseq-shift 65536
ha1 running seqnum-sync# / vrf main
sync-period-timeis the minimum time between two sequence number updates. An update is sent to the backup node only if the sequence number changed since last update (default 10s, 0 disables the time-based periodic update).sync-period-packetsis the number of packets between two sequence number updates: if the input or output sequence number of an IPsec SA changes of at least that number since last synchronization, then an update is sent to the backup node (default 2, 0 disables the packet-based periodic update).oseq-shiftis the optional IPsec SA output sequence number advance on the backup node: since sequence number cannot be synchronized in real time, the output sequence numbers on the inactive node are always late compared to the active mode. This value is added to the current output sequence number, in order to reduce or eliminate the gap between the active and the inactive node. Ideally, it should be greater or equal to the number of packets processed between two sequence number updates (default 65536).
HA-compatible virtual IP pools¶
IKEv1 and IKEv2 enable to assign a virtual IP during an IKE negotiation, i.e. an IKE initiator may request an additional IP address from the responder to use as inner IPsec tunnel address.
To proceed, the responder maintains a pool of virtual IPs (see IKE virtual IP pools).
If the IKE configuration makes use of virtual IP pools and HA IKE is enabled, then virtual IP leases must be synchronized between the master and the backup node.
This requires using specific HA-synchronized virtual IP pools. These pools are less flexible than standard virtual IP pools:
address pools can only be defined as subnets, not ranges of addresses.
no other parameters can be provided (such as a DNS, NetBIOS or DHCP server address).
there is no state information about these pools
When enabling HA IKE, be careful of using a virtual pool defined in the ha
context, because virtual pools defined directly in the ike context are not
synchronized between the master and backup node.
Define the pool:
ha1 running vrf main# ike
ha1 running ike# ha
ha1 running ha# pool my-ha-pool address 192.168.0.0/24
ha1 running ha# ..
Use it in a vpn:
ha1 running ike# vpn vpn-secgw
ha1 running vpn vpn-secgw# vip
ha1 running vpn vpn-secgw# vip-pool my-ha-pool
ha1 running vpn vpn-secgw# ..
ha1 running ike#
Display the IKE configuration:
ha1 running ike# show config nodefault
ike
vpn vpn-secgw
vip-pool my-ha-pool
(...)
ha
pool my-ha-pool
address 192.168.0.0/24
(...)
(...)
See also
The IKE command reference for details.