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

Page updated

Google Sites

Report abuse