http://msdn.microsoft.com/en-us/library/aa767914%28VS.85%29.aspx

Voici un exemple pour que le protocole SSH soit associé a SecureCRT (a mettre dans un .reg):

Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\SSH]
@="URL:SSH Protocol"
"EditFlags"=dword:00000002
"URL Protocol"=""
"FriendlyTypeName"="@C:\\Windows\\System32\\ieframe.dll,-907"
[HKEY_CLASSES_ROOT\SSH\DefaultIcon]
@="C:\\Windows\\System32\\url.dll,0"
[HKEY_CLASSES_ROOT\SSH\shell]
[HKEY_CLASSES_ROOT\SSH\shell\open]
[HKEY_CLASSES_ROOT\SSH\shell\open\command]
@="C:\Program Files\VanDyke Software\SecureCRT\SecureCRT.exe" "%1""

Introduction

Comme d’hab, voici la 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

Tout d’abord, il faut savoir qu’il y a l’option « simple », c’est à dire installer sa CA sous windows 2003 en tant que « Autorité de Certification d’Entreprise » (quelque chose comme ça), et dans ce cas, cela va marcher avec active directory, et on peut générer des certificats automatiquement pour les machines et utilisateurs du domaine. Je ne voulais pas utiliser cette option car les équipement que j’ai chez moi ne sont pas forcément dans le domaine, aussi même s’il est possible, peut être, de créer des utilisateurs AD et d’exporter leur certificats, ce n’est pas la solution la plus simple.

Installation de la CA

Commençons donc par installer la CA Microsoft.
Note: Installez IIS avant, sinon le web enrollment ne sera pas disponible. Si vous installez IIS après, tapez « certutil -vroot » dans l’invité de commande pour créer le site pour l’enrollment via la page web, sinon il est créé automatiquement lors de l’installation.

Pour installer la CA, il suffit d’aller dans panneau de configuration, « ajout/suppression de programmes », puis de cliquer sur « ajouter ou supprimer des composants windows ».

Choisissez ici « autorité racine autonome de certification » (quelque chose comme ça, désolé, mais maintenant que ça marche je vais pas tout réinstaller au risque de tout casser )

Pour la suite du setup, utilisez les paramètres par défauts.

Configuration ACS

Maintenant que l’autorité de certification est crée, il faut faire plusieurs choses:

• Configurer ACS pour « truster » le certificat de la CA
• Configurer un certificat pour ACS
• Créer des certificat utilisateurs et les installer

On vas donc commencer par faire en sorte qu’ACS fasse confiance à notre CA. Si comme moi votre ACS est sur le même serveur que la CA, le certificat est déjà présent, sinon il faut exporter le certificat de la CA qui est par défaut dans C:\ et l’ajouter dans les « certificate store » « trusted root CA » (désolé je mix un peu les termes windows en anglais et en Français ).
Pour rappel, EAP-TLS utilise les certificats, c’est à dire que les 2 partie distante qui s’authentifient doivent se faire confiance, et pour cela, soit chacune à un certificat autosigné qui est trusté par la partie distante, soit chacune à un certificat d’une même CA qu’elles trustent toutes les deux.

Il faut donc aller dans « system configuration/ACS Certificate Setup / Edit Certificate Trust List », et on coche notre CA (chez moi c’est W2K3, j’en ai plusieurs car j’ai réinstallé ma CA, mais normalement il n’y en a qu’une).

une fois que c’est fait, on vas configurer un certificat pour ACS. Pour cela, on va aller dans « system configuration/ACS Certificate Setup /Generate Certificate Signing Request ». Remplir les champs comme demandé (voir example): Il faut spécifier le chemin de la clé privée avec un mot de passe, ainsi que la taille de la clé (au dessus de 2048 bits vous risquez d’avoir des problème car le supplicant windows ne le supportera peut être pas).

Suite cela, on aura dans le menu de droite d’ACS du texte en base64 qui correspondras à la requête de certificat ACS.

Ensuite, connectez vous sur la page web de votre CA (http://CA/certsrv), et soumettez la demande de certificat (voir captures). Note: il existe d’autres moyens de soumettre les demandes de certificats… Note: Vous aurez besoin de IE car le site utilise des control active X. Si vous voyez un message « télécharger le controle ActiveX… » qui semble bloqué, éssayez de baisser les options de sécurité de IE, ça a marché avec moi…

Allez ensuite dans vote autorité de certifications (certsrv.msc) et délivrez le certificat:

Retournez ensuite sur le site pour obtenir votre certificat. Ici, je vais le sauvegarder en tant que « c:\certs\acs.cer »:

Retournez ensuite dans ACS pour installer le certificat. Pour ce faire, aller dans « system configuration/ACS Certificate Setup /Install ACS Certificate » puis cliquez sur « Install ACS Certificate » et remplissez les champs (avec les chemins du certificat tout juste créé, de la clé privée qui est normalement pré remplie, et le mot de passe définie pour la clé privée).

La dernière chose à faire avec ACS est d’activer le support de EAP-TLS dans « System Configuration / Gobal Authentication Setup » (il suffit de cocher les cases appropriées) puis de redémarrer les services (« System Configuration / Service control »)

Création des certificats clients

Maintenant que notre ACS est OK, il faut créer des certificat clients. Pour ce faire, on retourne sur le site, mais ce coup ci, on sélectionneras la première option lors de la création du certificat. la chose importante ici est de dire que l’on veux exporter la clé privée !

Une fois ce cela est fait, il vous reste à émettre le certificat depuis la CA comme vu précédemment, puis de le télécharger toujours depuis la page WEB. On doit donc avoir maintenant un certificat .cer, et une clé privée .pvk. Le soucis est que pour faire de l’authentification EAP-TLS, il faut que notre client ait les deux partie du certificat, on va donc utiliser l’outil pvkimprt.exe (http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=6563) pour faire un fichier .pxf (qui contiendras et la partie privée et la partie publique).

La syntaxe est très simple:

pvkimprt -pfx certificat.cer certificat.pvk

Une fenêtre vas s’ouvrir pour demander le password de clé privée que vous avez défini avant, puis vas vous demander ou sauvegarder ce fichier. Sauvegardez le donc, puis copiez le sur l’ordinateur de l’équipement qui doit s’authentifier. A partir de la, ouvrez le fichier .pfx sur votre PC, et installez le certificat dans le « personnal store ». Il faut aussi que le certificat de la CA soit installé dans le « trusted root CA » (pour cela, récupérez le .crt dans c:, et installez le dans le trusted root CA store.

Maintenant, tout est OK, il suffit de créer un profil Wireless manuel pour votre SSID, puis d’indiquer le certificat serveur à qui vous faites confiances, et windows devrait automatiquement utiliser votre certificat:

Concernant l’AP, voici la config que j’ai. Je ne la détaillerai pas, car c’est assez simple je penses:

!
aaa new-model
!
!
aaa group server radius rad_eap
 server 10.0.0.5 auth-port 1645 acct-port 1646
!
aaa group server radius rad_mac
!
aaa group server radius rad_acct
 server 10.0.0.5 auth-port 1645 acct-port 1646
!
aaa group server radius rad_admin
!
aaa group server tacacs+ tac_admin
!
aaa group server radius rad_pmip
!
aaa group server radius dummy
!
aaa authentication login localauth local
aaa authentication login eap_methods group rad_eap
aaa authentication login mac_methods local
aaa authorization exec default local
aaa authorization commands 15 default local
aaa accounting network acct_methods start-stop group rad_acct
!
!
dot11 mbssid
dot11 vlan-name inside vlan 2
!
dot11 ssid bastien_inside
 vlan 2
 authentication open eap eap_methods
 authentication network-eap eap_methods
 authentication key-management wpa version 2
 accounting acct_methods
 mbssid guest-mode
!
interface Dot11Radio0
 no ip address
 no ip route-cache
 !
 encryption vlan 2 mode ciphers aes-ccm
 !
 broadcast-key vlan 2 change 600
 !
 ssid bastien_inside
 !
 station-role root
!
interface Dot11Radio0.2
 encapsulation dot1Q 2
 no ip route-cache
 bridge-group 2
 bridge-group 2 subscriber-loop-control
 bridge-group 2 block-unknown-source
 no bridge-group 2 source-learning
 no bridge-group 2 unicast-flooding
 bridge-group 2 spanning-disabled
!
interface FastEthernet0.2
 encapsulation dot1Q 2
 no ip route-cache
 bridge-group 2
 no bridge-group 2 source-learning
 bridge-group 2 spanning-disabled
!
radius-server host 10.0.0.5 auth-port 1645 acct-port 1646 key 0 cisco
radius-server vsa send accounting
!
end

Il ne faut bien sur pas oublier de déclarer son AP dans ACS.

Conclusion

J’ai essayer de détailler au maximum les étapes pour la mise en place de cette solution, mais je dois avouer que j’ai eu un peu la flemme de prendre certains screenshots, donc si vous avez des questions, postez un commentaires

On va utiliser cette topologie pour l’exemple:

Topologies PODs

On va donc ici utiliser des VRFs pour chacuns des PODs, et on va ajouter du NAT statique pour tout le réseau du POD. Cela veut dire que 2 PODs peuvent avoir le même réseau, mais seront vu depuis l’extérieur comme des réseau différent. Cela permets de copier/déplacer des machines depuis un POD vers l’autre.

On commence par la configuration IP et VRF sur R2:

!
hostname R2
!
ip vrf pod1
rd 65000:1
!
ip vrf pod2
rd 65000:2
!
interface FastEthernet1/0
ip address 192.168.10.2 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet1/1
ip vrf forwarding pod1
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet2/0
ip vrf forwarding pod2
ip address 192.168.0.1 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!

On ajoute ensuite la config du NAT et du routage:

!
ip nat inside source static network 192.168.0.0 192.168.1.0 /24 vrf pod1
ip nat inside source static network 192.168.0.0 192.168.2.0 /24 vrf pod2
ip route vrf pod1 0.0.0.0 0.0.0.0 192.168.10.1 global
ip route vrf pod2 0.0.0.0 0.0.0.0 192.168.10.1 global
!

Voilà, le plus gros du travail est fait. Si on regarde la syntaxe des commandes nat, on voit que l’ont traduit le réseau 192.168.0.0 de la VRF pod1 vers le réseau 192.168.1.0, avec un masque de 24bits (on auraient pu mettre netmask 255.255.255.0). On fait la même chose avec le réseau 192.168.0.0 de la VRF pod2 que l’ont traduit en 192.168.2.0. L’astuce ici est d’utiliser le « source static network » qui indique que l’on va translater un réseau et non pas une IP.

Ensuite, on ajoute des routes dans les VRF vers la table globale afin que le traffic puisse joindre le réseau extérieur.

La configuration des autres routeurs est assez simple ici :

R1:

!
interface FastEthernet1/0
ip address 192.168.10.1 255.255.255.0
duplex auto
speed auto
!
ip route 192.168.0.0 255.255.0.0 192.168.10.2
!

R3/R4:

!
interface FastEthernet1/0
ip address 192.168.0.2 255.255.255.0
duplex auto
speed auto
!
ip route 0.0.0.0 0.0.0.0 192.168.0.1
!

Ici, si je ping 192.168.1.2 depuis R1, je ping R3, et si je ping 192.168.2.2 je ping R4:

R1#ping 192.168.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/159/176 ms
R1#ping 192.168.2.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 152/167/188 m

R3#
*Jun 14 14:08:51.187: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:51.335: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:51.491: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:51.667: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:51.819: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0

R4#
*Jun 14 14:08:54.023: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:54.183: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:54.323: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:54.531: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0
*Jun 14 14:08:54.667: ICMP: echo reply sent, src 192.168.0.2, dst 192.168.10.1, topology BASE, dscp 0 topoid 0

On peut voir sur R2 que le traffic est bien natté:

R2#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.1.2:7     192.168.0.2:7      192.168.10.1:7     192.168.10.1:7
--- 192.168.1.2        192.168.0.2        ---                ---
--- 192.168.1.0        192.168.0.0        ---                ---
icmp 192.168.2.2:6     192.168.0.2:6      192.168.10.1:6     192.168.10.1:6
--- 192.168.2.2        192.168.0.2        ---                ---
--- 192.168.2.0        192.168.0.0        ---                ---

https://supportforums.cisco.com/docs/DOC-16398

qui parle de l’outil Network Monitor de Microsoft:
http://www.microsoft.com/downloads/details.aspx?familyid=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

Vous allez me dire, quel intérêt, puisqu’il y a déjà wireshark ? Et bien quatre gros points positifs (je n’ai pas testé de fond en comble l’outil, alors il y a peut être d’autres features sympa)

-Possibilité de capturer en mode monitor avec sa carte WiFi
-Possibilité de filtrer le trafic par processus
-Possibilité de capturer sur plusieurs interfaces en même temps
-Export des fichiers de capture en .cap, pour les lire avec wireshark par exemple

Comment faire donc si je veux créer un utilisateur salut avec le mot de passe « cava? » ?
Voici ce qu’il se passe:

R1(config)#username salut password cava?
LINE    <cr>

R1(config)#username salut password cava

Autrement dit, ça ne parche pas.

Pareil sur l’asa:

ASA1(config)# username salut password cava?

configure mode commands/options:
 WORD
ASA1(config)# username salut password cava

Donc petite astuce, il faut taper Ctrl+V avant. Pourquoi ? je ne sais pas, mais il en est ainsi.

R1(config)#username salut password cava? !ici j'ai tapé ctrl+v avant le '?'
R1(config)#do sh run | i salut
username salut password 0 cava?

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

Topologie

topologie .net gns3

Introduction

J’avais un peu parlé, très très rapidement, du GETVPN dans un article précédent. Ici, on vas voir un peu plus en détail le fonctionnement et la configuration.

Le GET VPN ça sert à quoi déjà ? Vous avez peut être un super VPN MPLS au bureau qui marche super mais ça vous embête un petit peu d’avoir votre trafic qui se balade en clair. On peut donc mettre du DMVPN, mais on parleras de VPN Overlay dans la mesure ou on réencapsule les paquets et donc on rajoute une surcouche IP, donc on perd l’intérêt du VPN MPLS. Avec le GET VPN, on laisse le backbone MPLS s’occuper du VPN, et nous (le client) on s’occupe du chiffrement du traffic entre les équipement client (le provider n’a pas a gérer la configuration).

Pour fonctionner, le GETVPN utilise une variante de isakmp qui s’appelle GDOI qui permets la synchronisation des clés de sessions IPSec entre les différents clients, le principe du GET VPN étant d’être multicast, tous les clients auront la même clé de chiffrement à l’instant T (TEK – Traffic encryption key) et un rekeying global de cette TEK s’éffectura de temps en temps via la KEK (Key Encryption Key)

Config initiale

Bon je penses que ceux qui suivent un peu mon blog doivent être familier avec les VPNMPLS donc on va passer les détails de la config (les autres lisez mes autres articles).
Voici les configs: GETVPN_init_configs

On va commencer par faire une petite capture de ping entre C1 et C2 et faire un capture au niveau de F2/0 de core 1 pour voir ce qu’il ressort:

C1#ping 10.1.2.2 data DEAD repeat 20

Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 10.1.2.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!!!!!!!!!!!
Success rate is 100 percent (20/20), round-trip min/avg/max = 52/106/192 ms

ce qui nous donne:

Frame uncrypted

le fichier wireshark pour les curieux:

trace_uncrypted

Mise en place du serveur de certificats IOS

Alors vu que j’ai pas envie de démarrer une VM en CA, et qu’on a pas vu comment faire un CA sous IOS, et bien on va le faire ici.

Le procédure est dispo ici:
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080210cdc.shtml
En gros on génère des clés exportables, on les exportes sous forme de certificats, on active le serveur sur un des routeurs (ici core 1) et on va enroller les autres sur ce serveur CA.

c1(config)#crypto key generate rsa general-keys label carsa exportable modulus 512
% They will be replaced.

% The key modulus size is 512 bits
% Generating 512 bit RSA keys, keys will be exportable...[OK]

c1(config)#
*Oct  4 17:24:40.303: %SSH-5-DISABLED: SSH 1.5 has been disabled
*Oct  4 17:24:41.227:  RSA key size needs to be atleast 768 bits for ssh version 2
c1(config)#
*Oct  4 17:24:41.243: %SSH-5-ENABLED: SSH 1.5 has been enabled
!export format PEM, encryption clé privée DES, pass cisco 123
!Je suis pas sur que ça soit obligatoire, je penses que c'est plutot
!pour archiver les clés si on les perds mais j'ai pas testé sans
c1(config)#crypto key export rsa carsa pem url nvram: 3des cisco123
% Key name: carsa
 Usage: General Purpose Key
Exporting public key...
Destination filename [carsa.pub]?
Writing file to nvram:carsa.pub
Exporting private key...
Destination filename [carsa.prv]?
Writing file to nvram:carsa.prv
c1(config)#ip http server !activation HTTP pour SCEP
c1(config)#crypto pki server carsa
c1(cs-server)#database url nvram:
c1(cs-server)#database level names !on stock en plus le nom de chaque certificat
! par défaut minimum = juste le contenu crypto
core1(cs-server)#issuer-name CN=c1 L=MYDESK C=BE
! L = location, C = country
c1(cs-server)#no shut
%Some server settings cannot be changed after CA certificate generation.
% Please enter a passphrase to protect the private key
% or type Return to exit
Password: cisco123 
Re-enter password: cisco123
% Generating 1024 bit RSA keys, keys will be non-exportable...[OK]
% Exporting Certificate Server signing certificate and keys...

% Certificate Server enabled.
c1(cs-server)#
*Oct  4 17:36:57.087: %PKI-6-CS_ENABLED: Certificate server now enabled.
c1(cs-server)#do write
Building configuration...
[OK]
c1(cs-server)#exi
c1(config)#

Voilà normalement on est bon ici.

On va maintenant « enroller » nous routeurs afin qu’ils puissent s’authentifier les uns et les autres.
Je rappelle la procédure, on fait un trustpoint afin d’obtenir le certificat du CA (via la commande crypto ca authenticate), et ensuite on s’enroll (on demande notre certificat).

c2(config)#crypto ca trustpoint carsa
! vu que j'ai pas mis de CRL dans mon CA ça pourrait déconner
c2(ca-trustpoint)#revocation-check none
c2(ca-trustpoint)#enrollment url http://10.1.1.2:80
c2(ca-trustpoint)#exi
c2(config)#crypto ca authenticate carsa
Certificate has the following attributes:
 Fingerprint MD5: F9060FED EFDD437B 0971B86E 2CC79D65
 Fingerprint SHA1: 9261C779 35420504 12F77C07 B0EF5938 66F3DC48 

% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
c2(config)#crypto ca enroll carsa
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
 password to the CA Administrator in order to revoke your certificate.
 For security reasons your password will not be saved in the configuration.
 Please make a note of it.
!password défini lors du no sh du CA
Password: cisco123
Re-enter password: cisco123 

% The subject name in the certificate will include: c2
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose carsa' commandwill show the fingerprint.

c2(config)# ! voilà la requête de certificat, il faut maintenant l'approuver
*Oct  4 17:46:27.135: CRYPTO_PKI:  Certificate Request Fingerprint MD5: 4D9971C8 F02B5822 B4062ABE E4FD370A
*Oct  4 17:46:27.147: CRYPTO_PKI:  Certificate Request Fingerprint SHA1: 1CD7E7FA B4A4016E 5A7D4F9E FEDD64BD D3234946
c2(config)#

on va donc sur C1:

C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      pending    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2

C1#crypto pki server carsa grant 1
C1#sh crypto pki server carsa requests
Enrollment Request Database:

Subordinate CA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

RA certificate requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------

Router certificates requests:
ReqID  State      Fingerprint                      SubjectName
--------------------------------------------------------------
1      granted    B50C87B6E5AD25927EFDB485EF0003ED hostname=C2

on doit voir sur C2:

*Oct  4 18:17:32.151: %PKI-6-CERTRET: Certificate received from Certificate Authority

Maintenant on fait pareil sur C3 ET C1 (les certificats sur C1 servent pour le serveur, pas pour que notre routeur s’authentifie !).

Configuration du GET VPN

Donc le chiffrement va se faire au niveau des clients (C#). Au niveau du process, on a une isakmp (1ère phase uniquement) qui va permettre d’établir une connexion sécurisée entre les différents routeurs, puis GDOI (port UDP 848, ISAKMP=500) va gérer les clés IPSec (au lieu de la phase 2 isakmp).

On a un routeur qui fera office de keyserver (KS) et qui distribuera les TEK ainsi que les message de rekeying, et aura aussi la fonction d’indiquer aux autres routeurs (Group member) le traffic à sécuriser (via une ACL).

Note: on peut redonder les KS.

Note2 (edit): Le KS ne peut, à ma connaissance forwarder du trafic, il est uniquement la pour synchroniser les différents routeurs afin qu’ils puissent communiquer de manière sécurisée, mais ne communique pas. Si quelqu’un toutefois à réussi à faire en sorte que le KS puisse forwarder du trafic, je suis preneur !

Il faut donc que tous nos routeurs aient une policy isakmp identique:

C1(config)#crypto isakmp policy 666
C1(config-isakmp)#auth rsa-sig
C1(config-isakmp)#hash sha
C1(config-isakmp)#group 5
C1(config-isakmp)#exi

Ensuite, coté KS, on créé un transform set et un profile ipsec qui utilise ce transform set, puis une ACL pour le traffic à chiffrer, et enfin la config GDOI.

C1(config)#crypto ipsec transform-set TSET1 esp-aes
C1(cfg-crypto-trans)#mode transport
C1(cfg-crypto-trans)#exi
C1(config)#crypto ipsec profile P1
C1(ipsec-profile)#set transform-set TSET1
C1(ipsec-profile)#exi
C1(config)#ip access-list extended private-traffic
C1(config-ext-nacl)#deny udp any eq 848 any eq 848 ! on chiffre pas GDOI
C1(config-ext-nacl)#permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
C1(config-ext-nacl)#exi
C1(config)#crypto gdoi group GETVPN1
C1(config-gdoi-group)#identity number 1234 ! doit matcher sur les GM
C1(config-gdoi-group)#server local
C1(gdoi-local-server)#rekey ? ! ici je laisse tout par défaut
 address         Define the rekey packet format
 algorithm       Set the rekey encryption algorithm
 authentication  Identify the rekey authentication keypair
 lifetime        Define the rekey lifetime
 retransmit      Define the rekey retransmission parameters
 transport       Specify the rekey distribution method

C1(gdoi-local-server)#sa ipsec 1
C1(gdoi-sa-ipsec)#profile P1
C1(gdoi-sa-ipsec)#match address ipv4 private-traffic
C1(gdoi-sa-ipsec)#exi
C1(gdoi-local-server)#address ipv4 10.1.1.2 !interface d'écoute
C1(gdoi-local-server)#exi
C1(config-gdoi-group)#exi

Coté client on va voir que c’est beaucoup plus simple, tout est géré par le KS quasiment:

C2(config)#crypto gdoi group GETVPN1
C2(config-gdoi-group)#identity number 1234
C2(config-gdoi-group)#server address ipv4 10.1.1.2
C2(config-gdoi-group)#exi
C2(config)#crypto map GETMAP 10 gdoi
% NOTE: This new crypto map will remain disabled until a valid
 group has been configured.
C2(config-crypto-map)#set group GETVPN1
C2(config-crypto-map)#exi
C2(config)#int F1/0
C2(config-if)#crypto map GETMAP

Et la normalement, tout est bon.
J’ai eu quelques messages sur C2 et C3:

*Oct  4 18:47:43.275: %CRYPTO-5-GM_REGSTER: Start registration to KS 10.1.1.2 for group GETVPN1 using address 10.1.3.2
C3(config-if)#dow
*Oct  4 18:47:43.307: %CRYPTO-6-IKMP_NO_PRESHARED_KEY: Pre-shared key for remote peer at 10.1.1.2 is missing
*Oct  4 18:47:43.319: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
C3(config-if)#do
*Oct  4 18:47:45.743: %GDOI-5-GM_REGS_COMPL: Registration to KS 10.1.1.2 complete for group GETVPN1 using address 10.1.3.2

Ce qui je penses est du au fait que les policy isakmp par défaut sous IOS 15.0 utilise les PSK, et vu que j’ai fait une policy démoniaque (#666) ce n’était peut être pas la première testée, en conséquence de quoi les routeurs veulent s’auth via PSK, ils trouvent pas de PSK, ils passent en rsa-sig

quelques vérifs:

C1#sh crypto gdoi
GROUP INFORMATION

 Group Name               : GETVPN1 (Multicast)
 Group Identity           : 1234
 Group Members            : 2
 IPSec SA Direction       : Both
 Group Rekey Lifetime     : 86400 secs
 Rekey Retransmit Period  : 10 secs
 Rekey Retransmit Attempts: 2

 IPSec SA Number        : 1
 IPSec SA Rekey Lifetime: 3600 secs
 Profile Name           : P1
 Replay method          : Count Based
 Replay Window Size     : 64
 SA Rekey
 Remaining Lifetime  : 3300 secs
 ACL Configured         : access-list private-traffic

 Group Server list       : Local

C1#sh crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
10.1.1.2        10.1.2.2        GDOI_IDLE         1005 ACTIVE
10.1.1.2        10.1.3.2        GDOI_IDLE         1006 ACTIVE

IPv6 Crypto ISAKMP SA
!!!!!!!!!!!!
C2#sh crypto gdoi ipsec sa

SA created for group GETVPN1:
 FastEthernet1/0:
 protocol = ip
 local ident  = 10.1.0.0/16, port = 0
 remote ident = 10.1.0.0/16, port = 0
 direction: Both, replay: Disabled

C2#sh crypto gdoi gm
Group Member Information For Group GETVPN1:
 IPSec SA Direction       : Both
 ACL Received From KS     : gdoi_group_GETVPN1_temp_acl

 Group member             : 10.1.2.2         vrf: None
 Registration status   : Registered
 Registered with       : 10.1.1.2
 Re-registers in       : 3001 sec
 Succeeded registration: 1
 Attempted registration: 5
 Last rekey from       : 0.0.0.0
 Last rekey seq num    : 0
 Multicast rekey rcvd  : 0

Notez que le KS ne peut faire partie du VPN, ce que je n’avais prévu, sinon j’aurai rajouté un routeur. Pour le KS, il doit soit avoir une connexion dédiée accessible depuis tous les GM, soit être connecté derrière un GM (le GM ne doit pas passer par le KS pour avoir accès au VPN).

Bon pour que vous soyez pas trop déçu, je vous redonne quelques commandes show coté KS:

C1#sh crypto gdoi ks members 

Group Member Information : 

Number of rekeys sent for group GETVPN1 : 0

Group Member ID    : 10.1.2.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

Group Member ID    : 10.1.3.2
 Group ID          : 1234
 Group Name        : GETVPN1
 Key Server ID     : 10.1.1.2

C1#sh crypto gdoi ks po
C1#sh crypto gdoi ks policy
Key Server Policy:
For group GETVPN1 (handle: 2147483650) server 10.1.1.2 (handle: 2147483650):

 # of teks : 1  Seq num : 0
 kek policy : FALSE 

 TEK POLICY (encaps : ENCAPS_TRANSPORT)
 spi                : 0xFA94E73B
 access-list        : private-traffic
 transform          : esp-aes
 alg key size       : 16            sig key size          : 0
 orig life(sec)     : 3600          remaining life(sec)   : 411
 tek life(sec)      : 3600          elapsed time(sec)     : 3189
 override life (sec): 0             antireplay window size: 64        

C1#sh cry
C1#sh crypto se
C1#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.2.2 port 848
 IKE SA: local 10.1.1.2/848 remote 10.1.2.2/848 Active 

Interface: FastEthernet1/0
Session status: UP-IDLE
Peer: 10.1.3.2 port 848 
 IKE SA: local 10.1.1.2/848 remote 10.1.3.2/848 Active 

C1#

et coté GM

C2#sh crypto ipse sa

interface: FastEthernet1/0
 Crypto map tag: GETMAP, local addr 10.1.2.2

 protected vrf: (none)
 local  ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 remote ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
 current_peer 0.0.0.0 port 848
 PERMIT, flags={origin_is_acl,}
 #pkts encaps: 10, #pkts encrypt: 10, #pkts digest: 10
 #pkts decaps: 10, #pkts decrypt: 10, #pkts verify: 10
 #pkts compressed: 0, #pkts decompressed: 0
 #pkts not compressed: 0, #pkts compr. failed: 0
 #pkts not decompressed: 0, #pkts decompress failed: 0
 #send errors 0, #recv errors 0

 local crypto endpt.: 10.1.2.2, remote crypto endpt.: 0.0.0.0
 path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet1/0
 current outbound spi: 0xFA94E73B(4204062523)
 PFS (Y/N): N, DH group: none

 inbound esp sas:
 spi: 0xFA94E73B(4204062523)
 transform: esp-aes ,
 in use settings ={Transport, }
 conn id: 1, flow_id: SW:1, sibling_flags 80000000, crypto map: GETMAP
 sa timing: remaining key lifetime (sec): (303)
 Kilobyte Volume Rekey has been disabled
 IV size: 16 bytes
 replay detection support: N
 Status: ACTIVE
!!!!...!!!!!
C2#sh crypto session
Crypto session current status

Interface: FastEthernet1/0
Session status: UP-ACTIVE
Peer: 0.0.0.0 port 848 
 IKE SA: local 10.1.2.2/848 remote 10.1.1.2/848 Active
 IPSEC FLOW: permit ip 10.1.0.0/255.255.0.0 10.1.0.0/255.255.0.0
 Active SAs: 2, origin: crypto map
C2#sh crypto gdoi gm acl
Group Name: GETVPN1
 ACL Downloaded From KS 10.1.1.2:
 access-list  permit ip 10.1.0.0 0.0.255.255 10.1.0.0 0.0.255.255
 ACL Configured Locally:

bon il y en a d’autres, mais maintenant on va conclure par un petit ping voir la différence ! Ce coup ci je vais pinger entre C2 et C3 et sniffer sur Core3 F2/0.

Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.3.2, timeout is 2 seconds:
Packet has data pattern 0xDEAD
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 248/274/304 ms

et la pas de suprise, on voit plus de traffic en clair, mais bien du traffic sécurisé via ESP.

Frame crypted

voici la capture wireshark et les configs finales:

trace crypted

GETVPN configs final

http://shop.ebay.fr/remus-95/m.html?_nkw=&_armrs=1&_from=&_ipg=&_trksid=p4340

Pour rappel, les IDS-4215 sont upgradable vers la version 6.0 de l’OS IPS (IPS Manager Express fonctionne à partir de la 6.1, mais il fonctionne, tout comme asdm, en mode démo), ce qui leur permets de fonctionner en mode IPS (en gros IDS = detection, IPS = prevention, l’IPS se mettras donc en inline sur le réseau et pourras bloquer directement le trafic malveillant).

Je branche donc mon 4215 tout content, je vois une version 5.0, et je me dis, je vais upgrade vers la 6.0. Première déception, je n’avais que 256M de ram, or il en faut 512. Je trouve donc un module IDS-4210-MEM-U et je passe à 512M. Je flashe, cela semble fonctionner, l’IPS reboot, j’ai la CLI, sauf qu’à chaques fois au bout de quelques temps j’ai mon analysis engine qui plante… voir ici:

https://supportforums.cisco.com/message/3034805;jsessionid=F5B112DB22543E85D0511FA4AAF0B7B5.node0#3034805

Finalement, je me rend compte que les IDS 4215 ont besoin d’un disque dur pour fonctionner (il y a une flashcard qui contient l’OS et le disque dur qui contient logs et signatures). J’ai donc trouvé un disque dur en spare sur ebay pour 15€, un toshiba, qui remplace très bien le cisco si ce n’est qui’il n’y a pas le support pour maintenir le disque (j’ai mis un bout de carton).

Donc je redémarres, je flashe bien en version 6.04, l’IPS compile ses signatures, le CPU redevient normal, mon analysis engine est running, je me dis cela va être la fin de mes souffrance… Eh bien non… Vous me direz, dans le métier d’informaticien la déception est le pain quotidien, que celui qui fait tout fonctionner du premier coup laisse un commentaire…

Je commences donc par une petite config de base:

sensor(config)# service host
sensor(config-hos)# network-settings
sensor(config-hos-net)# host-ip 192.168.0.3/24,192.168.0.1
sensor(config-hos-net)# host-name IDS4215
sensor(config-hos-net)# access-list 0.0.0.0/0
sensor(config-hos-net)# exit
sensor(config-hos)# exit
Apply Changes?[yes]:

La syntaxe pour l’IP est assez bizarre, derrière il y a la gateway…

Et je lance donc mon IDM. Et la, je lance l’applet java, utilise mon compte cisco avec le mot de passe, et PAN! java error, il faut que le heap size soit au minimum à 256M. Je cliques donc sur help, ce qui me renvoit vers une page sur le site de cisco m’expliquant qu’il faut mettre le paramètre -Xmx256m dans le panneau de configuration/java, sauf qu’avec le JRE 1.6 ça ne marche pas. Je suis donc aller sur le site de SUN, ai téléchargé la version 1.5 du JRE (jre-1_5_0_21-windows-i586-p.exe), j’installe, et la petite astuce maintenant est de désactiver le 1.6 pour utiliser IDM, et le réactiver par la suite (ne pas désinstaller la version 1.6, installer la 1.5 par dessus).

Voir le screen:

Screenshot de la mort

Et tout çà… Pour ça:

IDM

Et comme je suis un fou, je vais essayer de trouver une carte PCI ethernet compatible avec mon IPS pour rajouter une interface et faire du inline…

Bref, à ceux qui veulent investir dans un IPS, prenez en un avec le module 4FE, le disque dur, et 512M de ram si vous ne voulez pas vous embêter…