Failover ACTIVE/ACTIVE Stateful IPSEC VPNs avec routeurs IOS

Voici un nouvel article expliquant la mise en place d’une solution de redondance avec réplication des connexions pour du remote VPN IPSEC (rien que ça vous me direz), et le tout en utilisant des routeurs IOS (je ferai sans doute un article sur les VPNs cluster sur les firewall asa). Les techniques utilisées sont SLB (server farm load balancing) qui permets de load balancer tout type de trafic et SSP/SSO pour la réplication des SA ISAKMP/IPSEC.

Topologie étudiéeTopologie étudiée

Topologie étudiéeTopologie étudiée

Configuration générale

Voici la configuration des IPs et du routage pour chaque équipements (cette partie étant hors du sujet)

Note: Il faut utiliser une versions d’IOS 12.2S (j’ai testé 12.2SB16, la 12.2SX18 fonctionne aussi, les autres je ne sais pas) sur le 7200 pour avoir les probes, autrement le SLB est configurable quand même, mais je n’ai pas testé le fonctionnement.
Pour les IAR, j’ai utilisé une 12.4-25b
VPNgw:

!
hostname VPNgw
!
interface FastEthernet0/0
 ip address 10.254.1.1 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet0/1
 ip address 10.254.2.1 255.255.255.0
 speed auto
 duplex auto
!
interface FastEthernet1/0
 ip address 200.0.0.1 255.255.255.0
 speed auto
 duplex auto
!
router eigrp 65000
 network 10.0.0.0
 network 200.0.0.0
 auto-summary
!

IAR1:

no service password-encryption
!
hostname IAR1
!
interface Loopback0
 ip address 200.0.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.254.1.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.254.3.1 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 65000
 network 10.0.0.0
 redistribute static !pour les connexions VPN
 auto-summary
!

IAR2:

!
hostname IAR2
!
interface Loopback0
 ip address 200.0.0.1 255.255.255.255
!
interface FastEthernet0/0
 ip address 10.254.2.2 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 ip address 10.254.3.2 255.255.255.0
 duplex auto
 speed auto
!
router eigrp 65000
 network 10.0.0.0
 redistribute static !pour les connexions VPN
 auto-summary
!

et le router RTRLan (il ne sert qu’a tester le ping via le VPN):

!
hostname RTRLan
!
interface Loopback0
 ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/0
 ip address 10.254.3.3 255.255.255.0
 duplex auto
 speed auto
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
router eigrp 65000
 network 10.0.0.0
 auto-summary
!

A partir d’ici vous devez avoir un réseau fonctionnel (tous les routeurs peuvent se pinger).

Configuration du load-balancing

Le principe de SLB est de créer une « ferme de serveur » server farm, à laquelle on va associer des serveurs réels. A cette server farm, l’on va pouvoir créer des IPs virtuelles pour un service donné. On peut avoir la même IP pour plusieurs services, ou des IP différentes. Il est possible de monitorer les serveurs de la server farm afin de détecter lorsqu’un devient inactif.

Configuration du server farm:

  • Creation d’une « probe » ping pour monitorer les serveurs (de nombreuses options sont disponibles, comme DNS, HTTP,… voir ici:
    https://www.cisco.com/en/US/docs/ios/ipapp/configuration/guide/ipapp_slb_ps6350_TSD_Products_Configuration_Guide_Chapter.html#wp1056543).
    le faildetect 3 indique qu’au bout de 3 éssais non réeussi, le serveur est considéré comme down.
  • Creation du server farm avec les paramètres dont l’algorithme de partage ou predictor (une connexion sur 2 = round robin, ou le serveur ayant le moins de connexions=leastconns)
  • Affectation des IPs réelles des serveurs, en l’occurence ce sont les IPs des routeurs qui vont recevoir les demandes de connexions IPSEC. On définit aussi un poid (on aurait pu privilégier un serveur par rapport à un autre), la limite de connexion par serveur, et enfin on active ces serveurs via la commande inservice.
!
ip slb probe PINGPROBE ping
 faildetect 3
!
ip slb serverfarm VPNCLUSTER
 predictor leastconns
 probe PINGPROBE
 !
 real 10.254.1.2
 weight 1
 maxconns 500
 inservice
 !
 real 10.254.2.2
 weight 1
 maxconns 500
 inservice
!vous devez voir ceci après le inservice, si le probe fonctionne.
*Oct 13 17:13:54.591: %SLB-6-REAL: Real 10.254.2.2 (VPNCLUSTER) has changed state to OPERATIONAL

Maintenant, on va configurer les services IPSEC, ISAKMP, et NAT-Transversal (pour rappel, le NAT-T encapsules les paquets IPSEC dans un segment UDP port 4500 afin que le nat ne cause pas d’erreur d’intégrité, AH et ESP vérifiant les headers).
Ici l’on va créer donc 3 virtuals servers, un pour ESP, un pour ISAKMP, et un pour le NAT-T (il aurait fallu en creer un supplémentaire si on utilisais AH).
Le but recherché (en tous cas le miens) est que chaque client soit dirigé vers un serveur, et que si ce serveur tombe, l’autre prenne la relève, mais pas que ISAKMP soit gérer par un serveur, ESP par un autre… C’est le principe du sticky. Le sticky 3650 indique de garder la même décision pour le serveur pendant 3650 secondes. Il faut bien entendu que ce nombre soit supérieur au SA lifetime d’isakmp (3600 secondes par défaut), sans quoi lors du rekeying, un client pourrait être associé à un autre serveur, car ISAKMP ne sera plus utilisé pendant cette période. Le paramètre group1 de la commande sticky permets d’associer deux protocole pour la décision de partage de charge (pour chaque client, les protocoles ESP et ISAKMP seront envoyé au même serveur).
De la même manière, le idle time doit être supérieur au rekey interval sans quoi cela pourrait poser les mêmes soucis.
Enfin, la commande inservice permets d’activer le serveur virtuel.
Note: J’ai utilisé la même IP que mon interface reliée à internet pour les virtuals servers, mais cela n’est pas obligatoire, tant que le routage est bon.

!
ip slb vserver ESP
 virtual 200.0.0.1 esp
 serverfarm VPNCLUSTER
 sticky 3650 group 1
 idle 3660
 inservice
!
ip slb vserver ISAKMP
 virtual 200.0.0.1 udp isakmp
 serverfarm VPNCLUSTER
 sticky 3650 group 1
 idle 3660
 inservice
!
ip slb vserver NATT
 virtual 200.0.0.1 udp 4500
 serverfarm VPNCLUSTER
 sticky 3650 group 1
 idle 3660
 inservice
!*Oct 13 17:18:04.547: %LINEPROTO-5-UPDOWN: Line protocol on Interface CASA-redirect, changed state to up

Voilà, votre routeur est configuré pour le load balancing, il reste à configurer le VPN. La configuration VPN doit être identique sur IAR1 et IAR2 (logique non ?).
J’ai utilisé des interfaces virtual-template dont l’ip source à été bindée sur une loopback afin d’utiliser cette adresse pour le tunnel IPSEC, car l’utilisateur distant va utilser cette adresse pour créer une SA, des paquets provenant d’une autre IP serait tout simplement droppés.

Voici la configuration nécessaire:

  • creation d’une policy AES256/pre share/DH Group2
  • Creation du groupe de clients (définition du mot de passe, du pool d’adresse et du domaine)
  • creation d’un profile ISAKMP pour les clients se connectant. Le profile contient le gourp client, sa methode d’authentification (ici on utilise la methode locale, le groupe et sa clé étant spécifiés dans la configuration).
    On indique aussi que le routeur doit répondre à la requête client, et utiliser l’interface virtual-template 1
  • Creation d’un transform set IPSEC et assignation de celui-ci à un profile
  • Creation de l’interface virtual-template1 en mode tunnel et application du profile IPSEC précédemment créé.
aaa authorization network authlocal local
!
crypto isakmp policy 666
 encr aes 256
 authentication pre-share
 group 2
!
crypto isakmp client configuration group VPNUSERS
 key cisco 
 domain network.lan
 pool vpnpool
crypto isakmp profile RVPN
   match identity group VPNUSERS
   isakmp authorization list authlocal
   client configuration address respond
   virtual-template 1
!
ip local pool vpnpool 10.0.1.1 10.0.1.127 !j'ai mis 128 254 sur l'autre routeur
!
crypto ipsec transform-set VPN esp-aes esp-sha-hmac
!
crypto ipsec profile VPNVTI
 set transform-set VPN
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback0
 tunnel source Loopback0
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VPNVTI
!

Ici, il ne reste plus qu’a configuré le client (voir capture ci dessous) et cela doit fonctionner :)

Configuration du client

Configuration du client

A partir d’ici, voici ce que l’on peut observer après la connexion d’un client:

VPNgw#sh ip slb vservers 

slb vserver      prot  virtual                  state         conns
----------------------------------------------------------------------
ESP              ESP   200.0.0.1/32:0           OPERATIONAL   1
ISAKMP           UDP   200.0.0.1/32:500         OPERATIONAL   1
NATT             UDP   200.0.0.1/32:4500        OPERATIONAL   0
VPNgw#sh ip slb real     

real                  farm name        weight  state          conns
-------------------------------------------------------------------
10.254.1.2            VPNCLUSTER       1       OPERATIONAL    0
10.254.2.2            VPNCLUSTER       1       OPERATIONAL    2
VPNgw#sh ip slb conne
VPNgw#sh ip slb connections 

vserver         prot client                real                  state     nat
-------------------------------------------------------------------------------
ESP             ESP  200.0.0.3:0           10.254.2.2            ESTAB     none
ISAKMP          UDP  200.0.0.3:1129        10.254.2.2            ESTAB     none

Sur les routeurs IAR

IAR2#sh crypto isakmp sa
dst             src             state          conn-id slot status
200.0.0.1       200.0.0.3       QM_IDLE              1    0 ACTIVE

IAR1#sh crypto ipsec sa 

IAR1#

La connexion est bien redirigée sur un des routeurs ! Connectons maintenant un second client:

VPNgw#sh ip slb real        

real                  farm name        weight  state          conns
-------------------------------------------------------------------
10.254.1.2            VPNCLUSTER       1       OPERATIONAL    2
10.254.2.2            VPNCLUSTER       1       OPERATIONAL    2
VPNgw#sh ip slb connections 

vserver         prot client                real                  state     nat
-------------------------------------------------------------------------------
ESP             ESP  200.0.0.4:0           10.254.1.2            ESTAB     none
ESP             ESP  200.0.0.3:0           10.254.2.2            ESTAB     none
ISAKMP          UDP  200.0.0.3:1129        10.254.2.2            ESTAB     none
ISAKMP          UDP  200.0.0.4:1057        10.254.1.2            ESTAB     none
VPNgw#sh ip slb vservers    

slb vserver      prot  virtual                  state         conns
----------------------------------------------------------------------
ESP              ESP   200.0.0.1/32:0           OPERATIONAL   2
ISAKMP           UDP   200.0.0.1/32:500         OPERATIONAL   2
NATT             UDP   200.0.0.1/32:4500        OPERATIONAL   0

Et sur les routeurs IAR:

IAR1#sh crypto isakmp sa
dst             src             state          conn-id slot status
200.0.0.1       200.0.0.4       QM_IDLE              1    0 ACTIVE

IAR2#sh crypto isakmp sa
dst             src             state          conn-id slot status
200.0.0.1       200.0.0.3       QM_IDLE              1    0 ACTIVE

Et voilà ! La déjà si tout marche on est content, mais nous n’allons pas nous contenter d’un « vulgaire » load-balancing, stateful failover sinon rien :p

Stateful failover

Methode 1 : SSP

Le SSP (State synchronisation protocol n’est disponible que sur les routeurs 7200).
http://www.cisco.com/en/US/docs/ios/12_2/12_2y/12_2yx11/feature/guide/ft_vpnha.html#wp1092416

Je regarde si je peux trouver l’image qui va bien et je test ça et je mets à jour ;)

Methode 2 : SSO

J’ai suivi la méthode décrite ici:
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gt_topht.html#wp1049370

mais cela ne semble pas fonctionner, j’ai donc posté un message sur les forums cisco netpro

On vera bien.

Quelques liens

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps6659/prod_white_paper0900aecd8045b552.html

http://www.cisco.com/en/US/docs/ios/12_2/12_2z/12_2za/feature/guide/slbza4.html

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t11/feature/guide/gt_topht.html

!
crypto keyring default_key
pre-shared-key address 0.0.0.0 0.0.0.0 key cisco
!
crypto isakmp policy 666
encr aes 256
authentication pre-share
group 2
!
crypto isakmp client configuration group VPNUSERS
key cisco
domain network.lan
pool vpnpool
crypto isakmp profile RVPN
keyring default_key
match identity group VPNUSERS
isakmp authorization list authlocal
client configuration address respond
virtual-template 1
!
!
crypto ipsec transform-set VPN esp-aes esp-sha-hmac
!
crypto ipsec profile VPNVTI
set transform-set VPN
!
!
!
!
!
interface Loopback0
ip address 200.0.0.1 255.255.255.255
!
interface FastEthernet0/0
ip address 10.254.1.2 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 10.254.3.1 255.255.255.0
duplex auto
speed auto
!
interface Virtual-Template1 type tunnel
ip unnumbered Loopback0
tunnel source Loopback0
tunnel mode ipsec ipv4
tunnel protection ipsec profile VPNVTI
!
router eigrp 65000
network 10.0.0.0
auto-summary
!
ip local pool vpnpool 10.0.1.1 10.0.1.127

Recent Entries

« Contest #1 : IPSEC Troubleshooting – 1
Remote VPN IPSEC sur ASA »

This entry was posted on Mardi, octobre 13th, 2009 at 20:22 and is filed under Sécurité réseau. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

2 Responses to “Failover ACTIVE/ACTIVE Stateful IPSEC VPNs avec routeurs IOS”

  1. nemorelax Says:
    mars 24th, 2010 at 8:31

    Je dois t’avouer qu’etant debutant dans le domaine des configurations d’IOS, j’admire ton blog qui est riche en enseignements…
    J’espere un jour etre au meme niveau…

    Cordialement :)

  2. Bastien Migette Says:
    mars 24th, 2010 at 14:02

    Merci :)
    Après, tout est question de temps et de motivation, sans tomber dans le stéréotype du geek qui est h24 devant son PC et ne sort jamais de chez lui, il faut prendre le temps de bosser, ça paieras par la suite ;)

Leave a Reply