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?

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://www.ipflow.utc.fr/index.php/GET-VPN_Introduction

Donc le GET VPN C’est quoi ? GET = Group Encrypted Transport, donc pour faire simple on vas chiffrer au niveau de la couche 4 par groupes, c’est à dire qu’on vas utiliser un protocole (GDOI, qui se base sur ISAKMP) et un Key Server qui aura pour rôle d’envoyer les configuration aux équipements distants (group members). Les group members vont établir une SA vers le KS qui vas leur envoyer les paramètres de chiffrement de manière sécurisée. Ensuite, chaque group members, lorsqu’il voudra communiquer avec un autre, vas chiffrer uniquement à partir de la couche 4, c’est à dire que l’en tête IP n’est jamais modifiée. En gros, immaginons que l’on a un réseau non sécurisé avec du routage entre nos différents sites. J’ajoute les fonctionnalités GETVPN à mon réseau, et les échanges seront maintenant sécurisés sans l’utilisations de tunnels. Cela prend donc tout son intérêt dans le cadre du MPLS, le transport paquets du client étant gérés par le FAI.

Le principe est que le FAI doit acheminer des paquets de l’adressage privé du client entre les différents site, sans quoi le client devrait utiliser des tunnels. Le client est ensuite libre d’implémenter une solution GET VPN pour sécuriser son traffic transitant par son fournisseur d’accès.

Il faut bien comprendre que l’adressage privé/publique n’a rien à voir avec GETVPN, on pourrait très bien utilisé des connexions WAN dédiée, et implémenter GETVPN sur les routeurs des différents sites, mais il faudrait utiliser un protocole de tunneling pour que les paquets d’un réseau local soient transportable sur internet.

Le gros avantage de cette solution est de permettre du chiffrement any to any (tous les sites vers tous les sites), sans avoir d’interface tunnel, ce qui est couteux en terme de performance (encapsulation/décapsulation), et qui obligerait à avoir autant de tunnel vers les différents site (imaginons que l’on ait 10 sites, chaque site devrait avoir 10 tunnels…) , ou dans le cas d’une topologie hub and spoke, avoir un routeur qui fait tout le routage…

Topologie

Topologie dynagen:

hostios = True
sparsemem = True

[localhost]

	[[2621XM]]
		image = ../images/C2600-AD.BIN
		ram = 96
		idlepc = 0x81691494

	[[ROUTER R1]]
		model = 2621XM

	[[ROUTER R2]]
		model = 2621XM
		F0/1 = R1 F0/0
		F0/0 = R3 F0/1

	[[ROUTER R3]]
		model = 2621XM

On prendra R2 comme étant le routeur Firewall.

Introduction

Sur l’ancien modèle de firewall (CBAC – IP INSPECT), il fallait définir des ACLs, et surtout autant d’ACL que l’on avait d’interface utilisées pour le firewall. De plus, on ne pouvait spécifier très précisément l’inspection protocolaire. Avec le nouveau modèle de firewall, le principe est de regrouper les interfaces sous forme de zones, et de spécifier quel type de trafic peut passer d’une zone à une autre. Cela utilise des service-policy et class map (cisco MQF).

Principes:

Ce qui est nouveau:

• Application des politiques de sécurité entre les zones, pas par interfaces (une zone peut être constituée d’une ou plusieurs interfaces)
• Il y a une politiques deny all par défaut (donc pas besoin d’ACL).
• On peut, via l’utilisation de classmap, spécifier des politiques différentes par host et par subnet, ou par protocoles

Note: On peut utiliser conjointement l’IOS firewall classic, et le zone based, sur des interfaces différentes (une interface qui fait partie d’une zone ne pourra faire d’inspection).

Il faut configurer les zones avant d’y ajouter des interfaces. et une interface ne peut faire partie que d’une seule zone à la fois. Les commandes pour créer une zone et y affecter des interfaces sont:

Router(config)#zone security zone_securisee
Router(config-sec-zone)#description zone securise!
Router(config-sec-zone)#exit
Router(config)#interface fastEthernet 0/1
Router(config-if)#zone-member security zone_securisee

Par défaut, le trafic sera supprimé entre:

• Une interface membre d’une zone vers une interface membre d’une autre zone
• Une interface membre d’une zone vers une interface non membre d’aucune zone: Ce traffic ne pourra être autorisé, même avec des ACL ou des service-policy, une interface faisant partie d’une zone ne peux communiquer qu’avec des interfaces dans une zone selon la configuration

Et le trafic sera autorisé entre:

• Deux interface d’une même zone
• Deux interface ne faisant partie d’aucune zone (comportement normal, sauf ACL)
• D’une interface membre d’une zone vers le routeur (= zone « self« , correspond aux paquets destinés aux interfaces du routeur : on peut utilisée cette zone spéciale pour modifier le comportement du routeur)

Note: On peut configurer des interfaces dans différentes VRFs dans une même zone, sous peu que le routage soit correct.

D’une zone à l’autre, trois actions peuvent être prises:

• Pass: Le trafic est autorisé à transiter d’une zone à l’autre
• Inspect: Autoriser le trafic et inspecter le trafic retour (= ip inspect)
• Drop: Supprimer le trafic

Ces actions peuvent bien sur être appliquée différemment selon le type de trafic (à régler par les class-map).

Pour réguler le trafic entre deux zones, il faut créer une zone-pair, que l’on va créer entre deux zone. Une zone pair est unidirectionnelle, il faudra donc créer deux zone-pair pour autoriser le trafic dans les deux sens. Pour autoriser le trafic, on utilisera des service policy, qui utiliseront des class-maps.

Création d’une zone-pair (après création d’une seconde zone):

Router(config)#zone security zone_non_securisee
Router(config-sec-zone)#exit
Router(config)#int f0/0
Router(config-if)#zone-member security zone_non_securisee
Router(config-if)#exit
Router(config)#zone-pair security secure_vers_unsecure source zone_securisee destination zone_non_securisee
Router(config-sec-zone-pair)#service-policy type inspect XXX
Router(config-sec-zone-pair)#exit

On distinguera deux types de class-map, et donc de service-policy, les type protocole (couche 7), et les autres (couche 3 et 4). Les class-map et service policy de couche 7 contiennent des options spécifique au protocole, mais ne peuvent être appliquée directement, il faudra passer par une policy classique. Voici un exemple:

Router(config)#class-map type inspect http l7_http_class
Router(config-cmap)#match ?
  flow      Flow based QoS parameters
  req-resp  HTTP request or response
  request   HTTP request
  response  HTTP response

Router(config-cmap)#match request ?
  arg          HTTP arguments
  body         HTTP body
  header       HTTP Request or Response header
  method       HTTP method
  port-misuse  Violation of HTTP port
  uri          HTTP uri
Router(config-cmap)#match request uri length gt 500
Router(config-cmap)#exit
!Creation de la policy
Router(config)#policy-map type inspect http l7_http_policy
Router(config-pmap)#class l7_http_class
Router(config-pmap-c)#?
Policy-map class configuration commands:
  allow  Allow the packet
  exit   Exit from class action configuration mode
  log    Generate log message
  no     Negate or set default values of a command
  reset  Reset the connection
  <cr>

Router(config-pmap-c)#reset
Router(config-pmap-c)#exit
Router(config-pmap)#exit

le mot clé http correspond au protocole, non au nom de la map.

Création maintenant d’une classe map applicable à une zone-pair

Router(config)#class-map type inspect ALL_HTTP_TRAFFIC
Router(config-cmap)#match protocol http
Router(config-cmap)#exit
Router(config)#policy-map type inspect My_Policy
Router(config-pmap)#class ALL_HTTP_TRAFFIC
Router(config-pmap-c)#service-policy http l7_http_policy
%Please configure inspect action first

Router(config-pmap-c)#inspect
Router(config-pmap-c)#service-policy http l7_http_policy
Router(config-pmap-c)#exit
Router(config-pmap)#exit

Si j’appliques la policy My_Policy sur une zone-pair (ou sur une interface d’ailleurs), cela aura pour effet d’inspecter tout le traffic HTTP et de supprimer les requête HTTP d’on l’URI fait plus de 500 caractères.

Voici l’erreur que j’aurai eu si j’avais tenté d’attacher la policy l7:

Router(config-sec-zone-pair)#service-policy type inspect l7_http_policy
Inspect service-policy attachment failed

Etude de cas:

En reprenant la topologie ci dessus (on considéreras que le routage est déjà fait), je vais créer une politique permettant d’autoriser ICMP a travers le firewall et d’autoriser le trafic HTTP et HTTPS a travers le routeur depuis la zone sécurisée vers la zone non sécurisée.
Note: pour les protocoles de routages, ils sont à destination de la zone self, et sont donc autorisés par défaut.

Création des politiques de sécurité

R2(config)#class-map type inspect match-any HTTP_TRAFFIC
R2(config-cmap)#match protocol http
R2(config-cmap)#match protocol https
R2(config-cmap)#exit
R2(config)#class-map type inspect ICMP_TRAFFIC
R2(config-cmap)#match protocol icmp
R2(config-cmap)#exit
R2(config)#policy-map type inspect http_icmp_policy
R2(config-pmap)#class HTTP_TRAFFIC
R2(config-pmap-c)#inspect
R2(config-pmap-c)#class ICMP_TRAFFIC
R2(config-pmap-c)#pass
R2(config-pmap-c)#exit
R2(config-pmap)#exit
R2(config)#policy-map type inspect icmp_policy
R2(config-pmap)#class ICMP_TRAFFIC
R2(config-pmap-c)#pass
R2(config-pmap-c)#exit
R2(config-pmap)#exit

créations des zones de sécurité et affectation aux interfaces

R2(config)#zone security SECURE
R2(config-sec-zone)#exit
R2(config)#zone security UNSECURE
R2(config-sec-zone)#exit
R2(config)#interface f0/1
R2(config-if)#zone-member security SECURE
R2(config-if)#interface f0/0
R2(config-if)#zone-member security UNSECURE
R2(config-if)#exit
R2(config)#

Et affectation des politiques de sécurité aux zone-pair.

R2(config)#zone-pair security SECURE_TO_UNSECURE source SECURE dest UNSECURE
R2(config-sec-zone-pair)#service-policy type inspect http_icmp_policy
R2(config-sec-zone-pair)#exit
R2(config)#zone-pair security UNSECURE_TO_SECURE source UNSECURE dest SECURE
R2(config-sec-zone-pair)#service-policy type inspect icmp_policy
R2(config-sec-zone-pair)#exit
R2(config)#

Et on teste, sur R1:

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 = 8/27/68 ms
R1#telnet 192.168.1.2 80 !test HTTP
Trying 192.168.1.2, 80 ... Open
zz
HTTP/1.1 400 Bad Request
Date: Fri, 01 Mar 2002 02:00:22 GMT
Server: cisco-IOS
Accept-Ranges: none

400 Bad Request

[Connection to 192.168.1.2 closed by foreign host]
R1#telnet 192.168.1.2 443 !test HTTPS
Trying 192.168.1.2, 443 ... Open
s
[Connection to 192.168.1.2 closed by foreign host]

sur R2:

R3#ping 192.168.0.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/11/16 ms
R3#telnet 192.168.0.1 80 !test HTTP
Trying 192.168.0.1, 80 ...
% Connection timed out; remote host not responding

R3#telnet 192.168.0.1 443 !test HTTPS
Trying 192.168.0.1, 443 ...
% Connection timed out; remote host not responding

R3#

Et voila!

Topologie

Fichier dynagen:

ghostios   = True
sparsemem  = True
#workingdir = c:temp

[localhost]
	[[3660]]
	        image = ../images/C3660-JK.BIN
	        ram = 128
		idlepc = 0x604eb02c
	[[2621XM]]
		image = ../images/C2600-AD.BIN
		ram = 96
		idlepc = 0x81691494
    [[ROUTER IAR]]
        model = 3660
        F0/0=NIO_gen_eth:vmnet1 #serveur CA
	F1/0=HUB F0/0
	F2/0=SPOKE2 F0/0
	F3/0=SPOKE3 F0/0
    [[ROUTER HUB]]
        model = 2621XM
    [[ROUTER SPOKE2]]
      model = 2621XM
    [[ROUTER SPOKE3]]
        model = 2621XM

Pour l’installation SCEP sous windows, c’est par ici: http://micronetsolution.net/Microsoft_CA_Cisco_setup.pdf edit: Lien HS. Si quelqu’un à DL le fichier, qu’il me l’envoi par mail postmaster ar0base bmigette.Fr merci.

Introduction:

Dynamic multipoint VPN (DMVPN pour les intimes), qu’est-ce que c’est ? Les DMVPN utilisent mGRE (Multipoint GRE), et NHRP (Next Hop Resolution Protocol), pour former des tunnels à la volée, c’est à dire qu’on a pas besoin de connaitre les IP des peers distants, mais l’on va dynamiquement créer des liaisons point à point vers tous les routeurs dans le même groupe mGRE que nous. On pourrait comparer NHRP à l’ARP pour les tunnels multipoints, sauf que cela permet de passer d’une ip privée vers une ip publique. Cela à pour avantage de simplifier la configuration des routeurs, et permettre l’extensibilité, notemment en cas d’ajout d’un noeud. Du fait que les peers ne sont pas connu à l’avance, nous pouvons créer une clef isakmp par défaut (http://bmigette.fr/2009/02/01/isakmp-pre-shared-key-par-defaut/), ou, comme c’est le cas ici, utiliser une infrastucture PKI qui est plus sécurisée.

Il y a deux approches pour le DMVPN:

Hub and spoke, topologie dans laquelle le hub utilise une interface tunnel mGRE, et il n’y aura pas de tunnel direct entre les différents sites, le hub fera le routage entre les tunnels.
Spoke To Spoke, les différents noeud distant établissent des tunnels entre eux de manière dynamiques, de manière à formé un réseau full mesh. C’est ce que nous allons voir ici.

Note: La notion HUB ici désignera simplement le routeur qui servira pour la résolution du Next Hop (ce sera le Next Hop Server, NHS), mais les tunnels se feront bien entre tous les routeurs

Etape 1: Configuration du serveur SCEP:

Le protocole SCEP permets simplement à un équipement de demander un certificat auprès d’un CA. Nous allons installer le support SCEP sur un serveur Windows 2003 Server.

Dans le panneau de configuration, sélectionnez Add or remove windows component.Selectionnez ensuite Certificate services, et dans applications services cochez IIS. Téléchargez ensuite le support SCEP pour le service de certificat microsoft (cepsetup.exe):
http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=9f306763-d036-41d8-8860-1636411b2d01&displaylang=en

Installez l’outil en laissant les paramètres par défaut.
Allez dans le gestionnaire IIS (start/administrative tools/Internet Information Services (IIS) Manager), puis déroullez « Application pools », puis click droit sur SCEP,properties, et vérifiez que dans l’onglet properties, Predefined est coché, et que Local system est sélectionné.

Note: IIS est le serveur web microsoft, il est utilisé par SCEP. Attention à sa configuration (ne pas laisser de site par défaut…).

Etape 2: Configuration de l’adressage :

N’oubliez pas l’ip du serveur de certificat. Dans la réalité, le serveur de certificat serait relié par un adressage privé sur un des routeur et on utiliserait du nat, mais ce n’est pas le but ici.

Hub:

Router(config)#hostname IAR
IAR(config)#int f0/0
IAR(config-if)#ip add 80.0.0.1 255.255.255.0
IAR(config-if)#no shut
IAR(config-if)#int f1/0
IAR(config-if)#ip add 80.0.1.1 255.255.255.0
IAR(config-if)#no shut
IAR(config-if)#int f2/0
IAR(config-if)#ip address 80.0.2.1 255.255.255.0
IAR(config-if)#no shut
IAR(config-if)#int f3/0
IAR(config-if)#ip add 80.0.3.1 255.255.255.0
IAR(config-if)#no shut

Hub:

Router>en
Router#conf t
HUB(config)#int f0/0
HUB(config-if)#ip add 80.0.1.2 255.255.255.0
HUB(config-if)#no sh
HUB(config)#int loop1
HUB(config-if)#ip add 1.1.1.1 255.255.255.0

Spoke2:

Router>en
Router#conf t
SPOKE2(config)#int f0/0
SPOKE2(config-if)#ip add 80.0.2.2 255.255.255.0
SPOKE2(config-if)#no sh
SPOKE2(config)#int loop1
SPOKE2(config-if)#ip add 2.2.2.2 255.255.255.0

Spoke3:

Router>en
Router#conf t
SPOKE3(config)#int f0/0
SPOKE3(config-if)#ip add 80.0.3.2 255.255.255.0
SPOKE3(config-if)#no sh
SPOKE3(config)#int loop1
SPOKE3(config-if)#ip add 3.3.3.3 255.255.255.0

Sur chaque routeur (sauf IAR):

ip route 0.0.0.0 0.0.0.0 A.B.C.D

Etape 3: Enrollment des spoke et du hub sur le serveur de certificat.

Pour cela, il faut sur les Spoke (inutile sur le Hub, il n’utilisera pas de certificats), tapez les commande suivantes:
Note: Pensez aussi à vérifier la synchronisation de l’heure entre les équipements et le serveur, le meiux est d’utiliser un serveur NTP.

Dans l’ordre:

• Définir un nom d’hôtes
• Définir un nom de domaine
• Mapper le nom d’hôtes du serveur de certificat si le service DNS n’est pas utilisé
• Supprimer les anciennes clé RSA
• Générer des clés RSA 1024 Bits
• Définir un CA (Certificate authority) de confiance
• Ajouter le CA comme étant une Registration Authority (RA)
• Spécifier l’url du serveur (vous avez du l’avoir lors de l’installation)
• Obtenir la clé du serveur
• Obtenir un certificat

Pour la commnade crypto ca enroll, il faut le mot de passe SCEP du serveur. Ce mot de passe s’obtiens en se connecant ici:
http://ca-server/certsrv/mscep/ (si votre serveur s’appelle ca-server). Pour vous logguer, utilisez un compte local (vu que vous avez mis local system à l’étape 1). Ce mot de passe est utilisable qu’une seule fois, il suffit de rafraîchir la page pour en obtenir un nouveau.

hostname device_name
ip domain-name yourdomain.com
ip host CA-Server A.B.C.D
crypto key zeroize rsa
crypto key generate rsa general-keys modulus 1024
crypto ca trustpoint your_trustpoint_name
  enrollment mode ra
  enrollment url http://CA-Server/certsrv/mscep/mscep.dll
  exit
crypto ca authenticate your_trustpoint_name
crypto ca enroll your_trustpoint_name

Exemple pour SPOKE2:

SPOKE2(config)#ip domain-name mynetwork.lan
SPOKE2(config)#ip host CA-Server 80.0.0.10
SPOKE2(config)#crypto key zeroize rsa
% No Signature RSA Keys found in configuration.

SPOKE2(config)#crypto key generate rsa general-keys modulus 1024
The name for the keys will be: SPOKE2.mynetwork.lan

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

SPOKE2(config)#crypto ca trustpoint myCaServer
SPOKE2(ca-trustpoint)#  enrollment mode ra
SPOKE2(ca-trustpoint)#$enrollment url http://CA-Server/certsrv/mscep/mscep.dll
SPOKE2(ca-trustpoint)#  exit
SPOKE2(config)#crypto ca authenticate myCaServer
Feb   16:47:54.363: %SSH-5-ENABLED: SSH 1.99 has been enabled
Certificate has the following attributes:
       Fingerprint MD5: 591609E4 D5171FFF 1A068C5C F5E4A507
      Fingerprint SHA1: 387CAF66 99B55B8A 4719C3FB 5174B6E0 56768896 

% Do you accept this certificate? [yes/no]: y
Trustpoint CA certificate accepted.
SPOKE2(config)#crypto ca enroll myCaServer
%
% 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: <=Password from http://ca-server/certsrv/mscep/ 
Re-enter password: <=Password from http://ca-server/certsrv/mscep/ 

% The subject name in the certificate will include: SPOKE2.mynetwork.lan
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 00000000000
% 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 ca certificate myCaServer verbose' commandwill show the fingerprint.

SPOKE2(config)#
Feb  8 16:49:12.996: CRYPTO_PKI:  Certificate Request Fingerprint MD5: 17E8E0CC B33A4ED1 C5B2D917 3A1EBE6C
Feb  8 16:49:12.996: CRYPTO_PKI:  Certificate Request Fingerprint SHA1: 0BE3A8F3 6C28152D 38C8F0A5 B02C6FDF 8AED29A4
!Après avoir "issue" le certificate (voir la ligne en rouge  )
Feb  8 20:45:22.767: %PKI-6-CERTRET: Certificate received from Certificate Authority

Faire la même chose pour les autres routeurs.

Allez ensuite dans start/Administrative tools/Certification Authority, et sélectionnez pending request. Vous devriez avoir la liste des certificats de vos routers. Sélectionnez les, clique droit, all task, et cliquez sur issue !

Etape 3: Configuration ISAKMP avec Certificats et du profil IPSEC:

Voici les commandes pour configurer ISAKMP:

HUB(config)#crypto isakmp policy 1
HUB(config-isakmp)#hash sha
HUB(config-isakmp)#encryp aes
HUB(config-isakmp)#authen rsa-sig
HUB(config-isakmp)#group 5
HUB(config-isakmp)#exit

A faire sur tous les spoke.

Il faut aussi créer un profile IPSEC qui sera utilisé pour sécuriser le tunnel:

HUB(config)#crypto ipsec transform-set DMVPN_TSet esp-aes
HUB(cfg-crypto-trans)#exit
HUB(config)#crypto ipsec profile DMVPN_IPSEC_Profile
HUB(ipsec-profile)#set transform-set DMVPN_TSet
HUB(ipsec-profile)#exit

A faire sur tous les spoke.

Etape4: Configuration des interfaces mGRE:

Note: attention au MTU! Les entêtes GRE utilisent 4octets, mGRE, 4 autres supplémentaires, et l’entête IP du tunnel 20octets.
Pour le routage, il faut considérer que tous les routeurs vont être dans le même sous réseau. Au niveau des interfaces tunnel, cela va donner ceci:

HUB: 192.168.1.1/24
SPOKE2: 192.168.1.2/24
SPOKE3: 192.168.1.3/24

Ces adresses seront mappées à leur adresses publiques par le HUB qui utilisera NHRP. Il faudra donc dire à EIGRP (ou autre protocole de routage IGP), de ne pas avertir de routes pour le réseau du VPN avec son IP local (no ip next-hop-self eigrp {AS}), car sinon cela crééré des incohérences dans la table de routage. On désactivera aussi le split-horizon, sans quoi une mise à jour reçue par le tunnel ne serait pas réémise.

Configuration pour le hub:

• Création d’une interface tunnel
• Attribution de l’ip privée du tunnel
• Changement du MTU (mettre un MTU bas afin de s’assurer que les paquets ne seront pas fragmenter sur le chemin, mais qu’ils seront fragmentés avant d’êtres envoyés).
• Créer un mot de passe NHRP
• Indiquer que le mappage se fera de manière dynamique par NHRP
• Indiquer le réseau NHRP (doit être le même sur les spoke)
• Désactiver le split horizon (nous utiliseront EIGRP 65000 Plus tard)
• Tunnel source et tunnel key (la clé doit être la même sur les spoke, ceci est optionnel, et peut être vu comme une sécurité assez basique: on ne pourra pas établir de tunnel sans deviner la clé).
• Tunnel mGRE
• Application du profile IPSEC

HUB(config)#interface Tunnel 0
HUB(config-if)#ip address 192.168.1.1 255.255.255.0
HUB(config-if)#ip mtu 1416
HUB(config-if)#no ip next-hop-self eigrp 65000
HUB(config-if)#ip nhrp authentication cisco123
HUB(config-if)#ip nhrp map multicast dynamic
HUB(config-if)#ip nhrp network-id 99
HUB(config-if)#no ip split-horizon eigrp 65000
HUB(config-if)#tunnel source FastEthernet 0/0
HUB(config-if)#tunnel key 999
HUB(config-if)#tunnel mode gre multipoint
HUB(config-if)#tunnel protection ipsec profile DMVPN_IPSEC_Profile

Pour les spoke:

• Création d’une interface tunnel
• Attribution de l’ip privée du tunnel
• Changement du MTU (mettre un MTU bas afin de s’assurer que les paquets ne seront pas fragmenter sur le chemin, mais qu’ils seront fragmentés avant d’êtres envoyés).
• Créer un mot de passe NHRP
• Faire un mappage dynamique NHRP pointant sur l’adresse du HUB.
• Rediriger le multicast vers une adresse unicast (l’adresse publique du HUB). Cela permettras l’utilisation de protocole de routage dynamiques utilisant du multicast (EIGRP, OSPF…)
• Indiquer l’adresse du NHS (Next Hop Server), qui indique le serveur qui contient le mapping IP publique/IP Tunnel.
• Indiquer le réseau NHRP (doit être le même sur les spoke)
• Désactiver le split horizon (nous utiliseront EIGRP 65000 Plus tard)
• Tunnel source et tunnel key (la clé doit être la même sur les spoke, ceci est optionnel, et peut être vu comme une sécurité assez basique: on ne pourra pas établir de tunnel sans deviner la clé).
• Tunnel mGRE
• Application du profile IPSEC

SPOKE2(config)#interface Tunnel 0
SPOKE2(config-if)#ip address 192.168.1.2 255.255.255.0
SPOKE2(config-if)#ip mtu 1416
SPOKE2(config-if)#no ip next-hop-self eigrp 65000
SPOKE2(config-if)#ip nhrp authentication cisco123
SPOKE2(config-if)#ip nhrp map 192.168.1.1 80.0.1.2
SPOKE2(config-if)#ip nhrp map multicast 80.0.1.2
SPOKE2(config-if)#ip nhrp nhs 192.168.1.1
SPOKE2(config-if)#ip nhrp network-id 99
SPOKE2(config-if)#no ip split-horizon eigrp 65000
SPOKE2(config-if)#tunnel source FastEthernet 0/0
SPOKE2(config-if)#tunnel key 999
SPOKE2(config-if)#tunnel mode gre multipoint
SPOKE2(config-if)#tunnel protection ipsec profile DMVPN_IPSEC_Profile

Etape 5: Configuration du routage:

Sur le hub:

HUB(config)#router eigrp 65000
HUB(config-router)#net 1.1.1.0 0.0.0.255
HUB(config-router)#net 192.168.1.0 0.0.0.255
HUB(config-router)#no auto-summary
HUB(config-router)#exit

Sur les spoke:

SPOKE2(config)#router eigrp 65000
SPOKE2(config-router)#net 192.168.1.0 0.0.0.255
SPOKE2(config-router)#net 2.2.2.0 0.0.0.255
SPOKE2(config-router)#eigrp stub connected
SPOKE2(config-router)#exit

SPOKE3(config)#router eigrp 65000
SPOKE3(config-router)#net 192.168.1.0 0.0.0.255
SPOKE3(config-router)#net 3.3.3.3 0.0.0.255
SPOKE3(config-router)#eigrp stub connected
SPOKE3(config-router)#exit

La fonction stub permet à EIGRP de ne pas apprendre toutes les routes du réseau, étant donné qu’il n’aura qu’un seul chemin possible. Le mot clef stub connected lui permet toutefois d’avertir ses routes connectées.

Voila tout doit marcher !!! Quelques commandes de vérifications:

Sur le hub

HUB#sh crypto isakmp peers
Peer: 80.0.2.2 Port: 500 Local: 80.0.1.2
 Phase1 id: SPOKE2.mynetwork.lan
Peer: 80.0.3.2 Port: 500 Local: 80.0.1.2
 Phase1 id: SPOKE3.mynetwork.lan
HUB#sh ip nhrp dynamic
192.168.1.2/32 via 192.168.1.2, Tunnel0 created 00:06:47, expire 01:53:12
  Type: dynamic, Flags: unique nat registered
  NBMA address: 80.0.2.2
192.168.1.3/32 via 192.168.1.3, Tunnel0 created 00:06:44, expire 01:54:04
  Type: dynamic, Flags: unique nat registered
  NBMA address: 80.0.3.2

Sur tout les routeurs:

HUB#sh crypto ca certificates
Certificate ! votre certificat
  Status: Available
  Certificate Serial Number: 61DEC674000000000008
  Certificate Usage: General Purpose
  Issuer:
    cn=ca-server
  Subject:
    Name: HUB.mynetwork.lan
    Serial Number: 00000000000
    hostname=HUB.mynetwork.lan
    serialNumber=00000000000
  CRL Distribution Points:

http://ca-server/CertEnroll/ca-server.crl

  Validity Date:
    start date: 18:51:17 UTC Feb 8 2009
    end   date: 19:01:17 UTC Feb 8 2010
  Associated Trustpoints: myCaServer 

CA Certificate ! Certificat du server
  Status: Available
  Certificate Serial Number: 4ED821D7E08FC8B74BC4E55A9500A3EA
  Certificate Usage: Signature
  Issuer:
    cn=ca-server
  Subject:
    cn=ca-server
  CRL Distribution Points:

http://labo-cisco/CertEnroll/ca-server.crl

  Validity Date:
    start date: 14:17:08 UTC Feb 8 2009
    end   date: 14:17:08 UTC Feb 8 2014
  Associated Trustpoints: myCaServer

Les crypto map qui sont créées (une par peer distant, et ce automatiquement… C’est pas beau ?):

HUB#sh crypto map
Crypto Map "Tunnel0-head-0" 65536 ipsec-isakmp
	Profile name: DMVPN_IPSEC_Profile
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}

Crypto Map "Tunnel0-head-0" 65539 ipsec-isakmp
	Map is a PROFILE INSTANCE.
	Peer = 80.0.2.2
	Extended IP access list
	    access-list  permit gre host 80.0.1.2 host 80.0.2.2
	Current peer: 80.0.2.2
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}

Crypto Map "Tunnel0-head-0" 65540 ipsec-isakmp
	Map is a PROFILE INSTANCE.
	Peer = 80.0.3.2
        Extended IP access list
	    access-list  permit gre host 80.0.1.2 host 80.0.3.2
	Current peer: 80.0.3.2
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}
	Interfaces using crypto map Tunnel0-head-0:
		Tunnel0
HUB#sh crypto map
Crypto Map "Tunnel0-head-0" 65536 ipsec-isakmp
	Profile name: DMVPN_IPSEC_Profile
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}

Crypto Map "Tunnel0-head-0" 65539 ipsec-isakmp
	Map is a PROFILE INSTANCE.
	Peer = 80.0.2.2
	Extended IP access list
	    access-list  permit gre host 80.0.1.2 host 80.0.2.2
	Current peer: 80.0.2.2
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}

Crypto Map "Tunnel0-head-0" 65540 ipsec-isakmp
	Map is a PROFILE INSTANCE.
	Peer = 80.0.3.2
        Extended IP access list
	    access-list  permit gre host 80.0.1.2 host 80.0.3.2
	Current peer: 80.0.3.2
	Security association lifetime: 4608000 kilobytes/3600 seconds
	PFS (Y/N): N
	Transform sets={
		DMVPN_TSet,
	}
	Interfaces using crypto map Tunnel0-head-0:
		Tunnel0

Et la table de routage:

HUB#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is 80.0.1.1 to network 0.0.0.0

     1.0.0.0/24 is subnetted, 1 subnets
C       1.1.1.0 is directly connected, Loopback1
     2.0.0.0/24 is subnetted, 1 subnets
D       2.2.2.0 [90/297372416] via 192.168.1.2, 00:07:06, Tunnel0
     3.0.0.0/24 is subnetted, 1 subnets
D       3.3.3.0 [90/297372416] via 192.168.1.3, 00:07:25, Tunnel0
     80.0.0.0/24 is subnetted, 1 subnets
C       80.0.1.0 is directly connected, FastEthernet0/0
C    192.168.1.0/24 is directly connected, Tunnel0
S*   0.0.0.0/0 [1/0] via 80.0.1.1

Voila! Un petit lab qui m’a pris l’après midi (surotut l’histoire du issue certificate !!! Bref si vous avez des questions, direction les comments. Je vous mets les conf finales à télécharger: Configurations