Exemple GETVPN avec utilisation du CA server IOS
Bon après une longue période d’inactivité, du moins du coté de mon blog, car à coté de cela beaucoup de choses à faire (sinon j’aurai évidemment faire plus d’articles
), eh bien j’ai décidé de faire un petit article sur le GETVPN car je vais sauter les 2 dernières certifs CCSP et attaquer directement le CCIE comme un grand.
Topologie
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:
le fichier wireshark pour les curieux:
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.
voici la capture wireshark et les configs finales:
Recent Entries
- DMVPN over GETVPN avec KS COOP (redondance) et KS Forwarding
- EAP-TLS avec Autorité de certification autonome (Standalone CA) sous Windows 2003
- Static subnet NAT avec VRF pour monter des ‘PODs’ (LAB)
- Capture WiFi en mode monitor sous windows, et capture par process
- Comment taper un point d’interrogation ‘?’ dans un mot de passe ?
- IPSEC High Availability Stateful Failover avec VTI
- Exemple GETVPN avec utilisation du CA server IOS
- Vente de matériel cisco : ip phone 7960, 3550 PoE, AP 1131Ag
- Prise en main d’un IDS 4215 et utilisation IDM sous Windows 7
- Vidéo de configuration 802.1X + PEAP sous ACS pour un AP Wifi aironet



janvier 21st, 2011 at 12:34
Salut,
je suis de pres ton blog, j’ai tente le CCIE au mois de spetembre x) saloperie de core knowledge questions …. bref, a mon sens le GETVPN ne permet pas au KS de forward du trafic. Par contre je sais que getvpn est compatible VRF mkais apaprement sa conf n’est pas du PER-VRF =/
http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6635/ps7180/prod_white_paper0900aecd80617171.html
Meme si il sait faire ca je ne crois pas que tu puisses faire quoi que ce soit pour le faire marcher. Dans les recommandations de design ils disent de prendre un router rien que pour ca car, suivant le nombre de peer ca peut charger assez fortement le router
Alex
janvier 24th, 2011 at 18:54
Merci pour ton commentaire. Effectivement le KS ne peut router du traffic…
Bref, dommage pour ton lab, effectivement les OEQ m’éffraient un petit peu… 2 questions de loupées sur les 4 et c’est mort, d’ailleurs sur R&S ils les ont enlevé… Je vais essayer de me monter un lab CCIE sous peu, j’ai passé l’écrit, je voudrais passer le lab en mars