DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding

J’avoue que quand je lis mon titre, je me dit que le profane doit se demander si je parle Français :D.
Bref, ici on va voir plusieurs choses:
-Redondance GDOI (GETVPN), aussi appelé mode COOP (Co-Operation)
-DMVPN over GETVPN : Quel est l’intérêt, toussa toussa…
-Comment forcer un KS à forward du traffic sur du GETVPN (la on va voir un petit trick car normalement ça n’est pas son but).

Introduction

Comme d’hab, voici la topologie:

DMVPN over GETVPN - Topologie

R1 etR3 seront les key servers, R4 le HUB DMVPN (le NHS quoi).
Notez que dans cet article on ne verra pas de policy isakmp car par défaut IOS (cela dépend des versions), à un jeu de policy isakmp pré définies utilisant « rsa-sig » pour l’authentification, j’ai donc ici monter une IOS CA rapidement. Pour plus d’info je vous renverrai à mes autres posts traitant de l’IOS CA (dont un avec du GETVPN en prime).
Je ne m’attarderais pas sur la config des interfaces fastEthernet et du routage de base, si vous voulez plus d’info, téléchargez les configs finales à la fin de l’article.

Concernant le pourquoi, c’est à dire pourquoi faire du DMVPN over GETVPN, c’est assez simple:
-Ça permets de bosser à la fois GETVPN et DMVPN pour sa CCIE
-Dans la réalité ça permets surtout si on a un réseau DMVPN assez large d’utiliser les mécanismes de keying/rekeying via GDOI et d’accélérer les tunnels entre SPOKES, car les spokes n’auront pas besoin de négocier les clés lors de l’établissement des tunnels.

Configuration du COOP GDOI

Ce qu’il faut savoir pour le COOP GDOI, c’est que nos 2 routeurs doivent partager la privée qui sert à authentifier les mises à jours de rekeying & policy.
Pour ce faire, on va donc créer une clé rsa exportable, que l’on va exporter via le terminal et importer sur notre autre routeur:

R1(config)#crypto key gen rsa exportable label GDOI_KEY modulus 1024 
The name for the keys will be: GDOI_KEY

% The key modulus size is 1024 bits
% Generating 1024 bit RSA keys, keys will be exportable...[OK]
R1(config)#cryp key export rsa GDOI_KEY pem terminal des cisco1234
% Key name: GDOI_KEY
 Usage: General Purpose Key
 Key data:
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVpDv53+I3ksDR7W+fPsqf60CB
qv2CMdtvR037eJbmuO2DB+bT9OltCnP2D/jLs+h8uPuV8Or0m8Xk40zKahL6vZJB
xZOeKOHWxUkiKWTLHGtg/1Sz9VA7xil7kBpOUJZZxW0hImp2eF/gjy28Ww0xTqIZ
LltGBBifAETWX8CYbwIDAQAB
-----END PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,D8117E8FC67B992E

fy216jblWbPt0Dg73J0QreRnSbPdd/N7mjWDlJdWIo8+Fj+/p3cQWaulDtD5glDJ
M1AwB1d8DCDH0sMvbhJEnEwksWI1dHvxNvbmAww5Op/En0bV5gSHFEOP8Tg6GXCI
hIUzy/aTZesbyB9lnFvsbi9IuJIP2IQIOdjFPkKy65Be2/OhogRuiUO2U6Y3vwpY
WPTJX89Qc8DjmQMGob1Vm2YIuvCksraA8oW3u+ZO1HCL4m33JFkovLAVIKghw3DD
q/loE9YxqKmO6OGFoUrY5kgZe5nQQxdZ+i7vZDP+zL8KF9vNxtVzanLZsVqA4Ky/
rQeycYf4zy/AaQts8zaF362t3tkN3mLzcwraeZ6YoAg5EDt1iAtGsIijP26ZznSv
t8lB1nVsBt8f3R6x17HNyiUWTaJllE7WtrwpzeIbEsTGCkbhf5TJ9nhljVgOu/Lr
bzD59K/nAOUr5CtffSlV9A3/bZZiGI62WkStMzA8MR+xqpSguzfbnSlZ0wK3YPQd
scwe8pFBYnAfyhyiFqTSxm8+EHYbiQRPXivwDmJsiNVsSj6TUK9jlbGvqnlwlBJB
GsNtRJfpdpHe29K7zXvIErn040uOLWVJMz2lvAIlkoRDeTOHIWCWE0MDD5MY7CX9
virETRUd+Qu6VM/5W++yTyn+g3rxgBMpPcC3FX8rhiEHDtYv6xZF+q+MY2j3ABMV
YwIrhbPy1DFGMzKjbautSrPakgQTM2rLQBEBBI0UlP7ZOCGmFwBHUUq962tofhHk
xkcY+r6Yfp3H7ICTwOu6wN4B3aGqxnRWfIIpOvcuE5hOj7p4i9Sn8A==
-----END RSA PRIVATE KEY-----

Voilà, ici on a créé une clé GDOI_KEY que l’on a définit comme étant exportable (bah oui sinon ça marche pas), puis on l’a exportée vers le terminal (la CLI quoi), chiffrée en DES avec le pass cisco1234. On va mintenant l’importer sur R3:

R3(config)#crypto key import rsa GDOI_KEY pem terminal cisco1234
% Enter PEM-formatted public General Purpose key or certificate.
% End with a blank line or "quit" on a line by itself.
-----BEGIN PUBLIC KEY----- !!On copie/colle la clé publique
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVpDv53+I3ksDR7W+fPsqf60CB
qv2CMdtvR037eJbmuO2DB+bT9OltCnP2D/jLs+h8uPuV8Or0m8Xk40zKahL6vZJB
xZOeKOHWxUkiKWTLHGtg/1Sz9VA7xil7kBpOUJZZxW0hImp2eF/gjy28Ww0xTqIZ
LltGBBifAETWX8CYbwIDAQAB
-----END PUBLIC KEY-----

% Enter PEM-formatted encrypted private General Purpose key.
% End with "quit" on a line by itself.
-----BEGIN RSA PRIVATE KEY-----!!puis la clé privée
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-CBC,D8117E8FC67B992E

fy216jblWbPt0Dg73J0QreRnSbPdd/N7mjWDlJdWIo8+Fj+/p3cQWaulDtD5glDJ
M1AwB1d8DCDH0sMvbhJEnEwksWI1dHvxNvbmAww5Op/En0bV5gSHFEOP8Tg6GXCI
hIUzy/aTZesbyB9lnFvsbi9IuJIP2IQIOdjFPkKy65Be2/OhogRuiUO2U6Y3vwpY
WPTJX89Qc8DjmQMGob1Vm2YIuvCksraA8oW3u+ZO1HCL4m33JFkovLAVIKghw3DD
q/loE9YxqKmO6OGFoUrY5kgZe5nQQxdZ+i7vZDP+zL8KF9vNxtVzanLZsVqA4Ky/
rQeycYf4zy/AaQts8zaF362t3tkN3mLzcwraeZ6YoAg5EDt1iAtGsIijP26ZznSv
t8lB1nVsBt8f3R6x17HNyiUWTaJllE7WtrwpzeIbEsTGCkbhf5TJ9nhljVgOu/Lr
bzD59K/nAOUr5CtffSlV9A3/bZZiGI62WkStMzA8MR+xqpSguzfbnSlZ0wK3YPQd
scwe8pFBYnAfyhyiFqTSxm8+EHYbiQRPXivwDmJsiNVsSj6TUK9jlbGvqnlwlBJB
GsNtRJfpdpHe29K7zXvIErn040uOLWVJMz2lvAIlkoRDeTOHIWCWE0MDD5MY7CX9
virETRUd+Qu6VM/5W++yTyn+g3rxgBMpPcC3FX8rhiEHDtYv6xZF+q+MY2j3ABMV
YwIrhbPy1DFGMzKjbautSrPakgQTM2rLQBEBBI0UlP7ZOCGmFwBHUUq962tofhHk
xkcY+r6Yfp3H7ICTwOu6wN4B3aGqxnRWfIIpOvcuE5hOj7p4i9Sn8A==
-----END RSA PRIVATE KEY-----
quit !! et on quitte !
% Key pair import succeeded.

R3(config)#

Voilà, ça c’est fait, maintenant attaquons GDOI:
Voici la config sur les deux routeurs (changez les IP biensur):

!
hostname R1
!Transform set et profile IPSEC
!Envoyés au GMs et utilisés pour le chiffrement
crypto ipsec transform-set TS1 esp-aes 
!         
crypto ipsec profile pf1
 set transform-set TS1 
! Création du group GDOI
crypto gdoi group GDOI1
 identity number 1 !Identifiant obligatoire, doit être le même partout
 server local !Je suis le KS
 rekey authentication mypubkey rsa GDOI_KEY !utiliser la clé définie pour le rekeying
 rekey transport unicast !Si votre réseau public supporte pas le multicast
 sa ipsec 1 !Définition des paramètres IPSEC
 profile pf1
 match address ipv4 GDOIACL
 address ipv4 80.1.0.2
 redundancy ! Les paramètres COOP
   local priority 10
   peer address ipv4 80.3.0.2
!
ip access-list extended GDOIACL
 permit gre any any
!

On fait donc la même chopse sur R3 en remplaçant bien sur l’addresse du server et du peer (elles seront inversées dans le cas présent).

Configuration de R4 et R5:

!Création du group  GDOI
crypto gdoi group GDOI1
 identity number 1 !Identifiant obligatoire, doit être le même partout
 server address ipv4 80.1.0.2 !R1
 server address ipv4 80.3.0.2 !R3
!
! Création de la crypto map GDOI et application à l'interface 
crypto map GETMAP 10 gdoi 
 set group GDOI1
!
interface FastEthernet1/0
 crypto map GETMAP
 !
!

Voilà, ici on peut copier/coller entre nos 2 routeurs.

Ici, on doit donc avoir nos routeurs qui s’enregistrent sur un des 2 serveurs:

R4#sh crypto gdoi gm
Group Member Information For Group GDOI1:
 IPSec SA Direction       : Both
 ACL Received From KS     : gdoi_group_GDOI1_temp_acl

 Group member             : 80.4.0.2         vrf: None
 Registration status   : Registered
 Registered with       : 80.3.0.2
 Re-registers in       : 308 sec
 Succeeded registration: 5
 Attempted registration: 10
 Last rekey from       : 80.3.0.2
 Last rekey seq num    : 0
 Unicast rekey received: 1
 Rekey ACKs sent       : 1
 Rekey Rcvd(hh:mm:ss)  : 00:52:26

R4#sh crypto gdoi gm acl 
Group Name: GDOI1
 ACL Downloaded From KS 80.3.0.2:
 access-list  permit gre any any
 ACL Configured Locally: 


R4#

Toutefois, le trafic ne sera pas encore chiffré puisque l’on va chiffrer uniquement le DMVPN (GRE), et pour l’instant, ça n’est pas configuré. On passe donc à l’étape suivante:

Configuration DMVPN

Bon, j’ai pas trop envie de m’attarder sur le DMVPN. Une petite note à propos des commandes IP NHRP redirect et shortcut: Cela permets d’avoir du DMVPN phase3. Rapidement, en phase 3, on n’a plus de « CEF Trick » comme en phase 2, mais le hub va envoyer des NHRP redirect aux spoke pour les destinations de ces SPOKE, et sur les SPOKE, on aura le shortcut qui permettras que NHRP force le next hop vers le bon SPOKE. Cela permets donc d’avoir des tunnels SPOKE to SPOKE avec plus d’avantages.
Le HUB enverra des NHRP Redirect quand il recevras un paquet depuis une SPOKE vers une autre SPOKE, à ce moment la il indiquera au routeur d’origine de chercher un meilleur chemin vers cette SPOKE (ce qui se fera via une résolution NHRP)
En gros les routeurs n’ont plus besoin de modifier leur table de routage, au lieu de ça, NHRP va réécrire les paquets sortants avec la bonne destination (l’IP publique de la SPOKE).
Voir: http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6660/ps6808/prod_white_paper0900aecd8055c34e_ps6658_Products_White_Paper.html

HUB (R4):

!
router eigrp 65000
 network 10.0.0.0
!
interface Tunnel0
 ip address 10.100.0.4 255.255.255.0
 no ip redirects
 ip nhrp map multicast dynamic
 ip nhrp network-id 1
 ip nhrp shortcut !Phase 3
 ip nhrp redirect
 no ip split-horizon eigrp 65000
 tunnel source FastEthernet1/0
 tunnel mode gre multipoint
 tunnel key 1
 !        
!

Et R5, la SPOKE:

!
router eigrp 65000
 network 10.0.0.0
!
interface Tunnel0
 ip address 10.100.0.5 255.255.255.0
 no ip redirects
 ip nhrp map 10.100.0.4 80.4.0.2
 ip nhrp map multicast 80.4.0.2
 ip nhrp network-id 1
 ip nhrp nhs 10.100.0.4
 ip nhrp shortcut
 no ip split-horizon eigrp 65000
 tunnel source FastEthernet1/0
 tunnel mode gre multipoint
 tunnel key 1
 !        
!

Voilà, à partir d’ici, R4 et R5 doivent se voir en tant que neighbor EIGRP et se pinguer:

R4#ping 10.5.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.5.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 192/292/460 ms
R4#

Aller, on va maintenant ajouter R1 et R3 à notre réseau DMVPN 🙂

Configuration des KS pour forward le traffic

Alors, en GETVPN, le KS ne forward normalement pas de trafic, il est déjà assez occupé avec le rekeying. Néanmoins, si on estime que notre routeur est assez costaud pour faire les deux, voici comment l’on peut activer le forwarding sur le KS:
Quelques limitations:
-Un KS ne peut s’enregistrer sur lui même (en tous cas chez moi ça ne marche pas, même avec une IP différente)
-Un KS ne peut s’enregistrer sur un peer avec la même IP que celle qu’il utilise pour se synchroniser.

Voici donc mon astuce:
On utilise une IP Publique alternative (ici j’ai pris une Loopback, mais une autre interface physique fera l’affaire), et on enregistre chaque KS vers l’autre dans une group GDOI distinct.
Note: si l’un des KS tombe, l’autre KS n’aura plus de SA GDOI, et donc plus de DMVPN. Aussi, bien faire attention à ce que cela implique si vous voulez déployer ça…

Bref, voici la config:

!
crypto gdoi group GDOI2
 identity number 1 !doit être le même, toujours
 server address ipv4 80.3.0.2 !Un seul serveur, le distant
 client registration interface Loopback1 !Notre interface alternative
!         
!
crypto map GETMAP 10 gdoi 
 set group GDOI2
!
!
interface Loopback0
 ip address 10.1.0.1 255.255.255.0
 !
!
interface Loopback1
 ip address 80.1.1.1 255.255.255.0
 !
!
interface Tunnel0
 ip address 10.100.0.1 255.255.255.0
 no ip redirects
 ip nhrp map multicast 80.4.0.2
 ip nhrp map 10.100.0.4 80.4.0.2
 ip nhrp network-id 1
 ip nhrp nhs 10.100.0.4
 ip nhrp shortcut
 ip nhrp redirect
 no ip split-horizon eigrp 65000
 tunnel source FastEthernet1/0
 tunnel mode gre multipoint
 tunnel key 1
 !
!
interface FastEthernet1/0
 crypto map GETMAP
 !
!
router eigrp 65000
 network 10.0.0.0
!

Et voilà!

R1#sh ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(65000)
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
 (sec)         (ms)       Cnt Num
0   10.100.0.4              Tu0               10 01:09:55  576  3456  0  8
R1#ping 10.5.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.5.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 276/472/848 ms
R1#ping 10.3.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 308/450/716 ms
R1#ping 10.4.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.4.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 312/348/420 ms
R1#

R4#sh ip nhrp brief 
 Target             Via            NBMA           Mode   Intfc   Claimed 
10.3.0.1/32          10.100.0.3      80.3.0.2        dynamic  Tu0     <   >
10.5.0.1/32          10.100.0.5      80.5.0.2        dynamic  Tu0     <   >
10.5.5.1/32          10.5.5.1        80.5.0.2        dynamic  Tu0     <   >
10.100.0.1/32        10.100.0.1      80.1.0.2        dynamic  Tu0     <   >
10.100.0.3/32        10.100.0.3      80.3.0.2        dynamic  Tu0     <   >
10.100.0.5/32        10.100.0.5      80.5.0.2        dynamic  Tu0     <   >

Les configs finales:

Configs finales

Recent Entries

2 Responses to “DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding”

  1. Oliv Says:

    Bonjour,

    Pouvez vous m’expliquer le but de ce système ?

    Merci 🙂

  2. Bastien Migette Says:

    A part prouver que c’est possible et rajouter de la complexité, il n’y en a pas vraiment 🙂 Dans la réalité, si le Key Server ne forward pas de traffic c’est pour une bonne raison: Dans un déploiement classique avec beaucoup de Spoke GETVPN, le KS est pas mal sollicité pour le rekeying, et s’il devait FW du traffic, cela pourrait impacter le rekeying.

Leave a Reply

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