HA for site-to-site VPN using HSRP

High-Availability for site-to-site VPN using HSRP

HSRP is used to track router's interface status to achieve failover between routers. However, no correlation exists between IPSec and HSRP, and so HSRP cannot track IPSec's SA state and IPSec requires schemes in order to synchronize HSRP failover when it occurs. Here, the HA for site-to-site VPN using HSRP is illustrated which is a scheme that provides a correlation between HSRP and IPSec.

Network topology:

The Remote site R4 router negotiates an IPSec tunnel at the Headend site to access the internal network behind R3 router. But, redundancy is configured using HSRP on R1 and R2 routers. So, R4 router initiates IPSec negotiation with the Virtual IP address 10.1.1.1/24. In case of link-failure or device-failure, the standby HSRP router takes over the role of active router.

The initial configuration of all routers is as follows-

Initial configuration on R1

interface fastethernet 0/0
 ip address 172.16.1.1 255.255.255.0
!
interface fastethernet 0/1
 ip address 10.1.1.2 255.255.255.0
 standby 1 ip 10.1.1.1
 standby 1 preempt
 standby 1 priority 105
 standby 1 timers 1 3
 standby 1 track fastethernet 0/0 10
!

Initial configuration on R2

interface fastethernet 0/0
 ip address 172.16.1.2 255.255.255.0
!
interface fastethernet 0/1
 ip address 10.1.1.3 255.255.255.0
 standby 1 ip 10.1.1.1
 standby 1 preempt
 standby 1 timers 1 3
 standby 1 track fastethernet 0/0 10
!

Initial configuration on R3

interface fastethernet 0/0
 ip address 172.16.1.3 255.255.255.0
!
interface Loopback 0
 ip address 192.168.1.1 255.255.255.0
!

Initial configuration on R4

interface fastethernet 0/0
 ip address 172.16.2.2 255.255.255.0
!
interface Loopback 0
 ip address 192.168.2.1 255.255.255.0
!

Dynamic crypto-map and RRI:

Dynamic crypto-map is configured on R1 and R2 routers. It accepts IPSec sessions dynamically from an arbitrary source without specifying the peer address manually. The dynamic crypto-maps is always assigned to a static crypto-map. Here, a Reverse-route injection (RRI) is configured under crypto-map configuration. RRI is the ability for the static routes to be automatically inserted into the routing process for those networks and hosts that are protected by the remote tunnel endpoint. These protected hosts and networks are called remote proxy identities.

Each route is created based on the remote proxy network and mask, with next-hop to this network being the remote tunnel endpoint. By using the remote tunnel endpoint as the next-hop, traffic is forced through the crypto process to be encrypted.

Dynamic crypto-map configuration on R1

crypto isakmp policy 10
 encryption des
 authentication pre-share
 hash md5
 group 2
!
crypto isakmp key 0 MY_K3Y address 0.0.0.0
!
crypto ipsec transform-set TS esp-des esp-md5-hmac
!
crypto dynamic-map DM 10
 set transform-set TS
 match address Traffic_to_remote
 reverse-route
!
! The wildcard address 0.0.0.0 is used which is not a good practice. Instead, RSA signature authentication method is recommended.
!
ip access-list extended Traffic_to_remote
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
crypto map CRYPTO 10 ipsec-isakmp dynamic DM
!
! The dynamic crypto-map DM is assigned to a static crypto-map CRYPTO.

Dynamic crypto-map configuration on R2

crypto isakmp policy 20
 encryption des
 authentication pre-share
 hash md5
 group 2
!
crypto isakmp key 0 MY_K3Y address 0.0.0.0
!
crypto ipsec transform-set TS esp-des esp-md5-hmac
!
crypto dynamic-map DM 10
 set transform-set TS
 match address Traffic_to_remote
 reverse-route
!
ip access-list extended Traffic_to_remote
 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
!
!
crypto map CRYPTO 10 ipsec-isakmp dynamic DM
!

Static crypto map configuration on R4

crypto isakmp policy 10
 encryption des
 authentication pre-share
 hash md5
 group 2
!
crypto isakmp key 0 MY_K3Y address 10.1.1.1
!
crypto ipsec transform-set TS esp-des esp-md5-hmac
!
crypto map CRYPTO
 set peer 10.1.1.1
 set transform-set TS
 match address Traffic_to_headend
!
! The peer address 10.1.1.1 is set to the Virtual IP address of the HSRP group.
!
ip access-list extended Traffic_to_headend
 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255
!
interface fastethernet 0/0
 crypto map CRYPTO
!

Now, these static crypto-maps are assigned to HSRP. However, an additional information is required- HSRP name. HSRP name is configured using standby <group-number> name <name> command under interface configuration mode. It assigns a unique name for HSRP group which will be used to assign along with the crypto-map.

This HSRP name when assigned to the crypto-map, forces the crypto-map to source IKE Phase 1 and IKE Phase 2 packets off the HSRP Virtual IP address 10.1.1.1. This can be done using crypto map <map-name> redundancy <group-name> command from interface configuration mode.

R1 router:
interface fastethernet 0/1
 standby 1 name INTERNAL
 crypto map CRYPTO redundancy INTERNAL
!
R2 router:
interface fastethernet 0/1
 standby 1 name INTERNAL
 crypto map CRYPTO redundancy INTERNAL
!
!HSRP group names should match on both routers.

Routing Protocol configuration:

Both, headend and remote, sites use RIP internally. Both sites connect to the ISP using EIGRP. Now, upon successful establishment of IPSec SA for remote proxies, static routes are created due to RRI. The next hop for those remote proxies is via the remote VPN router whose address is learned and applied during the creation of dynamic crypto-map template. The routes are deleted after the SAs are deleted.

The idea is to redistribute this static route created by RRI internally on the headend site so that internal routers like R3 can forward the packets through the active HSRP router. In order to do this, the static routes are redistributed with better metric into RIP by R1 and R2 routers using offset-list <ACL-number> <in | out> <offset-value> command under router configuration mode. This command matches the ACL and adds the offset-value to the metric to the prefix. Of course, this can also be done using redistribute static metric <metric-value> router configuration command.

R2 router redistributes static routes with default value.

RIP & EIGRP configuration on R1

router rip
 version 2
 no auto-summary
 network 172.16.1.0
 redistribute eigrp 10 metric 10
 redistribute static
 offset-list 10 out 2
!
router eigrp 10
 no auto-summary
 network 10.1.1.0
 redistribute rip metric 100000 0 255 1 1500
!
access-list 10 permit 192.168.2.0 0.0.0.255
!

RIP configuration on R3

router rip
 version 2
 no auto-summary
 network 172.16.1.0
 network 192.168.1.0
!

RIP and EIGRP configuration on R4

router rip
 version 2
 no auto-summary
 network 192.168.2.0
 redistribute eigrp 10 metric 10
!
router eigrp 10
 no auto-summary
 network 172.16.2.0
 redistribute rip metric 100000 0 255 1 1500
!

Before any SAs are created, the routing protocols exchange prefixes with each router. However, when R4 router attempts to ping the network 192.168.1.0/24 sourcing from its Loopback 0 interface 192.168.2.1, it classifies as the interesting traffic and R4 negotiates IKE Phase 1 & 2 with the peer 10.1.1.1. Here, 10.1.1.1 is the Virtual IP address of the HSRP group and since R1 router is the active HSRP router, it will respond to R4 router's negotiations and form the IPSec SA. Since RRI is configured on R1, it will create a static route to 192.168.2.0/24 network with next-hop as R4's tunnel endpoint 172.16.2.2.

Before failover: R1 & R3

R1# show ip route | begin Gateway
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
D       172.16.2.0 [90/307200] via 10.1.1.4, 00:16:59, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/1
R    192.168.1.0/24 [120/1] via 172.16.1.3, 00:00:16, FastEthernet0/0
S    192.168.2.0/24 [1/0] via 172.16.2.2
R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.1.1.1        172.16.2.2      QM_IDLE           1001    0 ACTIVE
IPv6 Crypto ISAKMP SA
R3# show ip route | begin Gateway
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
R       172.16.2.0 [120/10] via 172.16.1.1, 00:00:05, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
R       10.1.1.0 [120/10] via 172.16.1.1, 00:00:05, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Loopback0
R    192.168.2.0/24 [120/3] via 172.16.1.1, 00:00:05, FastEthernet0/0

Now, Fastethernet 0/0 of R1 fails, HSRP fails over to R2 router and changes the HSRP state from "standby" to "active". R4 deletes the SA since R1 relinquishes the "active" state and R2 becomes the "active" router. This causes R2 router to respond to R4 router for virtual IP address 10.1.1.1. R1 deletes the static route while R2 creates the same static route and redistributes to R3 router.

After failover: R1, R2 & R3

R1# show ip route | begin Gateway
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
D EX    172.16.1.0 [170/281600] via 10.1.1.3, 00:01:54, FastEthernet0/1
D       172.16.2.0 [90/307200] via 10.1.1.4, 00:40:51, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/1
D EX 192.168.1.0/24 [170/281600] via 10.1.1.3, 00:01:54, FastEthernet0/1
D EX 192.168.2.0/24 [170/307200] via 10.1.1.4, 00:00:48, FastEthernet0/1
R2# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.1.1.1        172.16.2.2      QM_IDLE           1004    0 ACTIVE
IPv6 Crypto ISAKMP SA
R2# show ip route | begin Gateway
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
D       172.16.2.0 [90/307200] via 10.1.1.4, 00:40:22, FastEthernet0/1
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/1
R    192.168.1.0/24 [120/1] via 172.16.1.3, 00:00:14, FastEthernet0/0
S    192.168.2.0/24 [1/0] via 172.16.2.2
R3# show ip route | begin Gateway
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 2 subnets
C       172.16.1.0 is directly connected, FastEthernet0/0
R       172.16.2.0 [120/10] via 172.16.1.1, 00:02:01, FastEthernet0/0
     10.0.0.0/24 is subnetted, 1 subnets
R       10.1.1.0 [120/10] via 172.16.1.1, 00:02:01, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Loopback0
R    192.168.2.0/24 [120/1] via 172.16.1.2, 00:00:20, FastEthernet0/0

Although HSRP timers are tuned, it takes a lot longer for IPSec tunnel to recreate again after failover. This method is not recommended for high-availability in IPSec VPN.

Ping result from R4

R4# ping 192.168.1.1 source loopback 0 repeat 720
Type escape sequence to abort.
Sending 2000, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!..........................
........!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!
Success rate is 95 percent (684/720), round-trip min/avg/max = 80/171/300 ms