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
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
- DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding
- EAP-TLS avec Autorité de certification autonome (Standalone CA) sous Windows 2003
- Static subnet NAT avec VRF pour monter des ‘PODs’ (LAB)
- Capture WiFi en mode monitor sous windows, et capture par process
- Comment taper un point d’interrogation ‘?’ dans un mot de passe ?
- IPSEC High Availability Stateful Failover avec VTI
- Exemple GETVPN avec utilisation du CA server IOS
- Vente de matériel cisco : ip phone 7960, 3550 PoE, AP 1131Ag
- Prise en main d’un IDS 4215 et utilisation IDM sous Windows 7
- Vidéo de configuration 802.1X + PEAP sous ACS pour un AP Wifi aironet
mars 30th, 2011 at 15:04
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
avril 5th, 2011 at 18:14
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/
avril 5th, 2011 at 18:15
Apres relecture de mon article, ceci est le SSO, et il s’agissais du SSP qui n’est que sur les 7200
avril 16th, 2011 at 12:59
ok je vois le truc
merci de l’info et des liens :p ca sera de la culture pour moi ^^
juillet 4th, 2011 at 21:44
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.
juillet 13th, 2011 at 20:52
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 = 0×0
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…
août 1st, 2011 at 16:01
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.