IPSEC High Availability Stateful Failover avec VTI

Un petit article sur le failover stateful IPSEC en utilisant des interface VTI. Pourquoi ? parce que c’est cool les VTIs !!! Plus que les crypto maps 🙂

Ah oui pour le fun j’ai mis du nat aussi (CCIE approchant, j’éssaie toujours de rajouter une petite touche de techno qui peut faire tout foirer histoire de troubleshooter).

R4 est le routeur qui fait du NAT. Il faut Imaginer que la liaison entre R4 et R5 est une connexion internet (d’où l’adressage en IP publique, les malins l’auront remarqué). Soit R1-R4 = Site1 et R5 = Site2

Ici, R2 et R3 vont avoir une IP Virtuelle HSRP qui va être nattée et servir de point de terminaison pour la connexion VPN.

Topologie

Topologie

Configurations initiales (routage & co)

R1

!
hostname R1
!
interface FastEthernet1/0
 ip address 192.168.2.2 255.255.255.0
 duplex auto
 speed auto
 !
!
interface FastEthernet1/1
 ip address 192.168.1.2 255.255.255.0
 duplex auto
 speed auto
 !
!
!
router eigrp 65000
 network 192.168.0.0 0.0.255.255
!

R2

!
hostname R2
!
interface FastEthernet1/0
 ip address 192.168.0.1 255.255.255.0
 duplex auto
 speed auto
 standby 1 ip 192.168.0.254
 standby 1 priority 120
 standby 1 preempt
 standby 1 name ha ! Le name est important ici
 !                 ! Il sera référencé par la suite
!
interface FastEthernet1/1
 ip address 192.168.1.1 255.255.255.0
 duplex auto
 speed auto
 !
!
!
router eigrp 65000
 network 192.168.0.0 0.0.255.255
!

R3

!
hostname R3
!
interface FastEthernet1/0
 ip address 192.168.0.2 255.255.255.0
 duplex auto
 speed auto
 standby 1 ip 192.168.0.254
 standby 1 preempt!
 standby 1 name ha ! Le name est important ici
 !                 ! Il sera référencé par la suite
!
interface FastEthernet1/1
 ip address 192.168.2.1 255.255.255.0
 duplex auto
 speed auto
 !
!
!
router eigrp 65000
 network 192.168.0.0 0.0.255.255
!

R4

!
hostname R4
!
interface FastEthernet1/0
 ip address 192.168.0.3 255.255.255.0
 ip nat inside
 ip virtual-reassembly
 duplex auto
 speed auto
 !
!
interface FastEthernet1/1
 ip address 80.0.0.1 255.255.255.0
 ip nat outside
 ip virtual-reassembly
 duplex auto
 speed auto
 !
!
!
router eigrp 65000
 network 192.168.0.0 0.0.255.255
 redistribute static metric 20000 2 255 10 1500
!
ip nat inside source static udp 192.168.0.254 500 80.0.0.1 500 extendable !UDP500 = ISAKMP
ip nat inside source static udp 192.168.0.254 4500 80.0.0.1 4500 extendable !UDP 4500 = IPSEC Nat Traversal
ip route 0.0.0.0 0.0.0.0 80.0.0.2
!
!

R5

!
hostname R5
!
interface FastEthernet1/0
 ip address 80.0.0.2 255.255.255.0
 duplex auto
 speed auto
 !
!
router eigrp 65000
 network 192.168.0.0 0.0.255.255
!

Configuration IPSEC sur R2/R3/R5

Ici, on configure une policy isakmp et un profile IPSEC que l’ont va appliquer sur le tunnel. Les deux choses importantes sont que l’on va mapper le groupe HSRP dans le profile IPSEC ce qui permettras à IPSEC de savoir quand initier le failover, et en tunnel source, nous utiliseront l’IP virtuelle HSRP (sinon ça marchera pas).

Il est important que les 2 tunnels aient des IP différente, car ici nous n’utilisons pas de reverse route comme avec une crypto map. Ce qu’il va se passer, c’est que lors du failover, le router standby HSRP va prendre le relai, il aura déjà toute les SA car elles sont synchronisée, et le premier voisin EIGRP va être down, et le second va devenir UP, ce qui va remplacer les routes au niveau de R5. C’est ce processus qui va mettre un peu de délai dans le failover et qui pourrais être accéléré via routes statiques, modification des timers eigrp, …

R2

!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 ! la flemme
!
!
crypto ipsec transform-set TS1 esp-aes
 mode transport
!
crypto ipsec profile pf1
 set transform-set TS1 
 redundancy ha stateful
!
interface Tunnel0
 ip address 192.168.10.1 255.255.255.0
 tunnel source 192.168.0.254 ! IP HSRP
 tunnel mode ipsec ipv4
 tunnel destination 80.0.0.2 ! IP R5
 tunnel protection ipsec profile pf1
 !
!

R3

!
crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0 ! la flemme
!
!
crypto ipsec transform-set TS1 esp-aes
 mode transport
!
crypto ipsec profile pf1
 set transform-set TS1 
 redundancy ha stateful
!
interface Tunnel0
 ip address 192.168.10.2 255.255.255.0
 tunnel source 192.168.0.254 ! IP HSRP
 tunnel mode ipsec ipv4
 tunnel destination 80.0.0.2 ! IP R5
 tunnel protection ipsec profile pf1
 !
!

R5

crypto isakmp policy 1
 authentication pre-share
crypto isakmp key cisco address 0.0.0.0 0.0.0.0
!
!
crypto ipsec transform-set TS1 esp-aes
 mode transport
!
crypto ipsec profile pf1
 set transform-set TS1 
!
!
!
!
!
!
!
interface Tunnel0
 ip address 192.168.10.3 255.255.255.0
 tunnel source FastEthernet1/0
 tunnel mode ipsec ipv4
 tunnel destination 80.0.0.1 !IP Public R4
 tunnel protection ipsec profile pf1
 !
!

Configuration pour le stateful failover

On va ici utiliser ipc (inter process communication).
Je vais pas trop détailler les commandes car cela me parait assez évident en gros on active le failover inter équipement, puis on créé une association entre nos deux routeurs, ou l’on définit IP Locale/Distante, ainsi que le port.
On mappe aussi ce failover au groupe HSRP. C’est HSRP qui sera le « trigger » pour initier le failover (quand le routeur active passe standby et vice versa les routeurs seront que l’état à changé).

Notez que l’on peut sécuriser l’échange IPC via IPSEC, ce qui n’est pas une mauvaise chose. Il est aussi intelligent d’utiliser une interface dédiée pour la transmission IPC (juste un lien entre les deux routeurs avec un subnet dédié, et on ajuste les local/remote ip dans la conf IPC).

NOTE: Il faut redémarrer les routeurs après avoir défini le stateful failover via IPC

R2

!
ipc zone default
 association 1
 no shutdown
 protocol sctp
 local-port 5000
 local-ip 192.168.0.1
 retransmit-timeout 300 10000
 path-retransmit 10
 assoc-retransmit 10
 remote-port 5000
 remote-ip 192.168.0.2 !IP R3
!
redundancy inter-device
 scheme standby ha
!

R3

!
ipc zone default
 association 1
 no shutdown
 protocol sctp
 local-port 5000
 local-ip 192.168.0.2
 retransmit-timeout 300 10000
 path-retransmit 10
 assoc-retransmit 10
 remote-port 5000
 remote-ip 192.168.0.1
!
redundancy inter-device
 scheme standby ha
!

Petite démo live & debugs/show

R2#sh redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
 Scheme: Standby
 Groupname: ha Group State: Active
 Peer present: RF_INTERDEV_PEER_COMM
 Security: Not configured

R3#sh redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_STDBY
 Scheme: Standby
 Groupname: ha Group State: Standby
 Peer present: RF_INTERDEV_PEER_COMM
 Security: Not configured

R5#ping 192.168.1.2 repeat 1000

Type escape sequence to abort.
Sending 1000, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!!!!!.. !//Ici je fait un shut sur F1/0 de R2 pour tout casser
*Mar 15 21:52:57.095: %DUAL-5-NBRCHANGE: EIGRP-IPv4 65000: Neighbor 192.168.10.2 (Tunnel0) is up: new adjacency !un voisin tombe
....
*Mar 15 21:53:04.227: %DUAL-5-NBRCHANGE: EIGRP-IPv4 65000: Neighbor 192.168.10.1 (Tunnel0) is down: holding time expired !l'autre passe up
..!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !//et le ping repart !
!!!!!

R3#sh redundancy inter-device
Redundancy inter-device state: RF_INTERDEV_STATE_ACT
 Scheme: Standby
 Groupname: ha Group State: Active
 Peer present: RF_INTERDEV_PEER_NO_COMM ! No comm car R2 est dead
 Security: Not configured
R3#

Rallumons R2

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!.......!! !//ça tombe, et ça repart !
*Mar 15 21:57:09.435: %DUAL-5-NBRCHANGE: EIGRP-IPv4 65000: Neighbor 192.168.10.1 (Tunnel0) is up: new adjacency!!!!!!!!!!!!!!!

Conclusion

Voici un article sur la haute disponibilité IPSEC avec du stateful failover.

On noteras qu’ici le plus la durée de failover est due aux timers HSRP. La partie routage pourrais donc être améliorée pour accélérer la transition.

Topologie GNS et config finales: ipsec_ha.zip

Recent Entries

7 Responses to “IPSEC High Availability Stateful Failover avec VTI”

  1. Alexandre Says:

    Tiens bizarre, dans les derniers cours Cisco (SECURE) ils disent que ce n’est pas possible O_o
    A un moment donne j’ai pense a faire ça, mais je révisais et je n’avais pas le temps. voila une bonne chose !
    merci de l’info 🙂

  2. Bastien Migette Says:

    Oui c’est assez spécifique, je crois que ça ne marche qu’avec les 7200… Il y a aussi une autre méthode appelée SSO comme j’en parlais ici:
    http://bmigette.fr/2009/10/13/failover-activeactive-stateful-ipsec-vpns-avec-routeurs-ios/

  3. Bastien Migette Says:

    Apres relecture de mon article, ceci est le SSO, et il s’agissais du SSP qui n’est que sur les 7200 🙂

  4. Alexandre Says:

    ok je vois le truc 🙂 merci de l’info et des liens :p ca sera de la culture pour moi ^^

  5. Sylvain Says:

    Could you show a ‘show crypto ha’ and ‘show crypto sess active’ / ‘show crypto sess standby’ ?

    I’ve tried this setup but couldn’t get it to work. The stateful failover doesn’t work. I mean the tunnel eventually comes up again but it’s a renegotiation, not a failover (and the same effect works without the SSO and stuff).

    For eg, with a crypto map failover, when you do a ‘reload’ of one of the router (instead of a shut or hard power down), the transition is almost lossless (no delay at all), and the other side of the tunnel doesn’t go down then up.

  6. Bastien Migette Says:

    Hello Sylvain. I just reloaded my setup back (you can do it on 2mn with GNS 😉 ), and it appears that even if I made everything as described here:
    http://www.cisco.com/en/US/docs/ios/sec_secure_connectivity/configuration/guide/sec_failover_ipsec_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1121665

    the stateful HA is not working (sh cryp sess active is empty). First I was thinking the gap between ping was caused by routing, not by IPSEC, but it seems it’s both.
    Checking the output of
    R2#sh redundancy states
    my state = 13 -ACTIVE
    peer state = 8 -STANDBY HOT
    Mode = Duplex
    Unit ID = 0

    Maintenance Mode = Disabled
    Manual Swact = disabled (peer unit not yet in terminal standby state)
    Communications = Up

    client count = 13
    client_notification_TMR = 30000 milliseconds
    RF debug mask = 0x0

    On the above doc we can see:
    Manual Swact = Enabled
    so I suspect that something is wrong with inter dev HA, maybe due to emulation software…

  7. Sylvain Says:

    Not sure it’s the emulation the problem because using GNS to do a crypto map failover works just fine, no packet loss if you do a router (and minimal if you hard shutdown one).

    In the end, I used crypto maps with GRE instead of VTI because I needed to tunnel both IPv4 and IPv6 over the same IPv4 link.

Leave a Reply

Le temps imparti est dépassé. Merci de recharger le CAPTCHA.