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
..
..
..
Encrypting the synchronization messages¶
The HA synchronization data exchanged between ha1 and ha2 contains sensitive information such as cryptographic keys. Now the network path used to convey this information (eth3 in the HA cluster figure) is not necessarily a trusted network.
It is possible to use IPsec to encrypt this traffic. In order to isolate the IKE and IPsec traffic used for securing the HA synchronization exchanges from the other IKE and IPsec traffic, the underlying interface (here eth3) is moved to a separate VRF hasync, and an IPsec-protected cross-VRF logical interface is created over this link. The HA synchronization is performed via the logical interface instead of the eth3 interface.
The logical interface may be for example an SVTI interface (that does a direct IPsec encapsulation of the HA exchanges) or a GRE interface (that first does a GRE encapsulation of the HA exchanges, then the GRE packets are IPsec encrypted).
Using a cross-vrf svti interface¶
A cross-vrf SVTI logical interface is used to convey the HA synchronization messages.
The SVTI interface is in the same VRF as the IKE service (here main) and its link-VRF is hasync. Then IKE is configured in VRF hasync to encrypt the data sent over the SVTI interface in tunnel mode.
The endpoints of the HA synchronization traffic (ha1 10.160.0.1, ha2 10.160.0.2) are configured on the SVTI interface. All data sent over the SVTI interface is encrypted in tunnel mode between the adresses of the underlying physical interface (ha1 10.150.0.1, ha2 10.150.0.2).
ha1 cli configuration¶
ha1 running config# show config nodefault
vrf main
(...)
interface
svti svti-hasync
ipv4
address 10.160.0.1/24
..
svti-id 888
link-vrf hasync
..
..
(...)
ike
ha
listen-ha-group g
node-id 1
interface svti-hasync
local-address 10.160.0.1
remote-address 10.160.0.2
seqnum-sync
sync-period-time 1s
sync-period-packets 64
..
..
..
(...)
vrf hasync
ike
pre-shared-key psk-hasync
id primary@ha
id secondary@ha
secret 0xf0043c9a1e4c22177c4e01dd909a96b2
..
ike-policy-template ikepol-hasync
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
prf-alg hmac-sha1
dh-group modp1024
..
keying-tries 0
unique-sa replace
..
ipsec-policy-template ipsecpol-hasync
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
esn true
..
..
vpn vpn-hasync
ike-policy
template ikepol-hasync
..
ipsec-policy
template ipsecpol-hasync
..
local-address 10.150.0.1
remote-address 10.150.0.2
local-id primary@ha
remote-id secondary@ha
security-policy svti-hasync
local-ts subnet 0.0.0.0/0
remote-ts subnet 0.0.0.0/0
svti-id-in 888
svti-id-out 888
..
..
..
interface
physical ntfp3
ipv4
address 10.150.0.1/24
..
port pci-b0s6
..
..
..
ha2 cli configuration¶
ha2 running config# show config nodefault
vrf main
(...)
interface
svti svti-hasync
ipv4
address 10.160.0.2/24
..
svti-id 888
link-vrf hasync
..
..
(...)
ike
ha
listen-ha-group g
node-id 2
interface svti-hasync
local-address 10.160.0.2
remote-address 10.160.0.1
seqnum-sync
sync-period-time 1s
sync-period-packets 64
..
..
..
(...)
vrf hasync
ike
pre-shared-key psk-hasync
id primary@ha
id secondary@ha
secret 0xf0043c9a1e4c22177c4e01dd909a96b2
..
ike-policy-template ikepol-hasync
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
prf-alg hmac-sha1
dh-group modp1024
..
keying-tries 0
unique-sa replace
..
ipsec-policy-template ipsecpol-hasync
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
esn true
..
..
vpn vpn-hasync
ike-policy
template ikepol-hasync
..
ipsec-policy
template ipsecpol-hasync
..
local-address 10.150.0.2
remote-address 10.150.0.1
local-id secondary@ha
remote-id primary@ha
security-policy svti-hasync
local-ts subnet 0.0.0.0/0
remote-ts subnet 0.0.0.0/0
svti-id-in 888
svti-id-out 888
..
..
..
interface
physical ntfp3
ipv4
address 10.150.0.2/24
..
port pci-b0s6
..
..
..
Using a cross-vrf gre interface¶
A cross-vrf GRE logical interface is used to convey the HA synchronization messages.
The GRE interface is in the same VRF as the IKE service (here main) and its link-VRF is hasync. Then IKE is configured in VRF hasync to encrypt the GRE traffic in transport mode.
The endpoints of the HA synchronization traffic (ha1 10.160.0.1, ha2 10.160.0.2) are configured on the GRE interface. Its encapsulation addresses are those of the underlying physical interface (ha1 10.150.0.1, ha2 10.150.0.2). The GRE-encapsulated packets are encrypted in transport mode.
ha1 cli configuration¶
ha1 running config# show config nodefault
vrf main
(...)
interface
gre gre-hasync
local 10.150.0.1
remote 10.150.0.2
ipv4
address 10.160.0.1/24
..
link-vrf hasync
..
..
(...)
ike
ha
listen-ha-group g
node-id 1
interface gre-hasync
local-address 10.160.0.1
remote-address 10.160.0.2
seqnum-sync
sync-period-time 1s
sync-period-packets 64
..
..
..
(...)
vrf hasync
ike
pre-shared-key psk-hasync
id primary@ha
id secondary@ha
secret 0xf0043c9a1e4c22177c4e01dd909a96b2
..
ike-policy-template ikepol-hasync
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
prf-alg hmac-sha1
dh-group modp1024
..
keying-tries 0
unique-sa replace
..
ipsec-policy-template ipsecpol-hasync
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
esn true
..
..
vpn vpn-hasync
ike-policy
template ikepol-hasync
..
ipsec-policy
template ipsecpol-hasync
..
local-address 10.150.0.1
remote-address 10.150.0.2
local-id primary@ha
remote-id secondary@ha
security-policy gre-hasync
local-ts protocol 47
remote-ts protocol 47
mode transport
..
..
..
interface
physical ntfp3
ipv4
address 10.150.0.1/24
..
port pci-b0s6
..
..
..
ha2 cli configuration¶
ha2 running config# show config nodefault
vrf main
(...)
interface
gre gre-hasync
local 10.150.0.2
remote 10.150.0.1
ipv4
address 10.160.0.2/24
..
link-vrf hasync
..
..
(...)
ike
ha
listen-ha-group g
node-id 2
interface gre-hasync
local-address 10.160.0.2
remote-address 10.160.0.1
seqnum-sync
sync-period-time 1s
sync-period-packets 64
..
..
..
(...)
vrf hasync
ike
pre-shared-key psk-hasync
id primary@ha
id secondary@ha
secret 0xf0043c9a1e4c22177c4e01dd909a96b2
..
ike-policy-template ikepol-hasync
ike-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
prf-alg hmac-sha1
dh-group modp1024
..
keying-tries 0
unique-sa replace
..
ipsec-policy-template ipsecpol-hasync
esp-proposal 1
enc-alg aes128-cbc
auth-alg hmac-sha1
dh-group modp1024
esn true
..
..
vpn vpn-hasync
ike-policy
template ikepol-hasync
..
ipsec-policy
template ipsecpol-hasync
..
local-address 10.150.0.2
remote-address 10.150.0.1
local-id secondary@ha
remote-id primary@ha
security-policy gre-hasync
local-ts protocol 47
remote-ts protocol 47
mode transport
..
..
..
interface
physical ntfp3
ipv4
address 10.150.0.2/24
..
port pci-b0s6
..
..
..
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¶
IKE enables to assign a virtual IP and optional attributes 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.
Virtual IPs and attributes are exchanged using an IKEv2 Configuration Payload (or an IKEv1 Config Mode) exchange.
Additional parameters may be assigned during this exchange, such as a DNS server address, a NetBIOS server address or a DHCP server 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.
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. The address specification is mandatory, other attributes are
optional:
ha1 running vrf main# ike
ha1 running ike# ha
ha1 running ha# pool my-ha-pool
ha1 running pool my-ha-pool#! address 192.168.0.0/24
ha1 running pool my-ha-pool# dns 192.168.3.99
ha1 running pool my-ha-pool# ..
ha1 running ha#
addressis the set of addresses that can be assigned (IPv4 or IPv6 subnet).dnsis an optional list of DNS server addresses (IPv4 or IPv6).nbnsis an optional list of NetBIOS server addresses (IPv4 or IPv6).dhcpis an optional list of DHCP server addresses (IPv4 or IPv6).subnetis an optional list of subnets protected by the responder (IPv4 or IPv6). (attributes INTERNAL_IP4_SUBNET/INTERNAL_IP6_SUBNET in RFC 7296)netmaskis an optional value for the internal network’s netmask (IPv4). (attribute INTERNAL_IP4_NETMASK in RFC 7296)
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
dns 192.168.3.99
..
(...)
(...)
Troubleshooting¶
“(unknown)” SAs after failover¶
If a failover occurs while an SA is being created or rekeyed it may result in an extra SA named “(unknown)” being permanently listed:
ha1# show ike vrf main ike-sa
VPN Local-Addr Local-ID Remote-Addr Remote-ID State Child-SAs
(unknown) 10.175.0.1 secgw.6wind.net 10.225.0.1 enodeb1.6wind.net connecting 0
Such SAs do not affect the system in any way other than cluttering the list and
can be cleared manually using the flush command
(see IKE Manually clearing SAs).
See also
The IKE command reference for details.