Diapositive 1

Chapitre 1: Mise en œuvre

de VPN IPsec
Cours préparé et animé par A.MOHAMMEDI
Diapositive 2

1.0 Introduction
1.1 VPNs
1.2 Composants et
fonctionnement de VPN IPsec
1.3 Implémention de VPN Ipsec
Site-à-Site avec CLI
1.4 Résumé
Diapositive 3

• Les organisations utilisent des réseaux privés virtuels (VPN) pour

créer une connexion de réseau privé de bout en bout sur des
réseaux tiers, tels qu'Internet ou des extranets. Les VPN utilisent
un tunnel pour permettre aux utilisateurs distants d'accéder aux
ressources réseau du site central. Cependant, les VPN ne
peuvent pas garantir que les informations restent sécurisées lors
de la traversée du tunnel. Pour cette raison, des méthodes
cryptographiques modernes sont appliquées aux VPN pour établir
des connexions réseau privées sécurisées de bout en bout.
• Le protocole IP Security (IPsec) fournit un cadre pour la
configuration de VPN sécurisés. C'est un moyen fiable de
préserver la confidentialité des communications tout en
rationalisant les opérations, en réduisant les coûts et en
permettant une administration flexible du réseau. Des VPN
sécurisés de site à site, entre des sites centraux et distants,
peuvent être implémentés en utilisant IPsec.
Diapositive 4

À la fin de cette section, vous devriez être capable de:

• Décrire les VPNs et leurs avantages.

• Comparer les VPNs site à site et d'accès distant.

Diapositive 5
Diapositive 6

Avantages des VPNs:

• Économies de coûts

• Sécurité

• Évolutivité
(Scalability)
• Compatibilité

Un VPN est un réseau privé créé sur un réseau public, généralement Internet. Au lieu
d'utiliser une connexion physique dédiée, un VPN utilise des connexions virtuelles routées
via Internet depuis l'organisation vers le site distant. Les premiers VPN étaient strictement
des tunnels IP qui n'incluaient pas l'authentification ou le cryptage des données. Par
exemple, GRE (Generic Routing Encapsulation) est un protocole de tunnel développé par
Cisco qui peut encapsuler une grande variété de types de paquets de protocole de couche
réseau dans des tunnels IP. Cela crée une liaison virtuelle point à point avec les routeurs
Cisco aux points distants via un interréseau IP.
Les principaux avantages des VPN sont illustrés à la Figure. Un VPN est virtuel en ce qu'il
transporte des informations dans un réseau privé, mais ces informations sont en réalité
transportées sur un réseau public. Un VPN est privé en ce sens que le trafic est crypté pour
garder les données confidentielles pendant leur transport sur le réseau public.
Un VPN est un environnement de communication dans lequel l'accès est strictement
contrôlé pour permettre des connexions entre pairs dans une communauté d'intérêt
définie. La confidentialité est obtenue en chiffrant le trafic dans le VPN. Aujourd'hui, une
implémentation sécurisée du VPN avec cryptage est ce qui est généralement assimilé au
concept de réseau privé virtuel.
Diapositive 7

• Un VPN connecte deux points

de terminaison, tels que deux
bureaux distants, sur un réseau
public pour former une
connexion logique.
• Les connexions logiques
peuvent être faites au niveau de
la couche 2 ou de la couche 3.
• Des exemples courants de VPN
de couche 3 sont GRE, MPLS
(Multiprotocol Label Switching)
et IPsec.
• Les VPN de couche 3 peuvent
être des connexions de site point
à point, telles que GRE et IPsec,
ou ils peuvent établir une
connectivité universelle vers de Les services IPsec permettent
nombreux sites utilisant MPLS. l'authentification, l'intégrité, le contrôle
d'accès et la confidentialité.

Dans le sens le plus simple, un VPN connecte deux points de terminaison, tels que deux
bureaux distants, sur un réseau public pour former une connexion logique. Les connexions
logiques peuvent être faites au niveau de la couche 2 ou de la couche 3. Ce chapitre se
concentre sur la technologie VPN de couche 3. Des exemples courants de VPN de couche 3
sont GRE, MPLS (Multiprotocol Label Switching) et IPsec. Les VPN de couche 3 peuvent être
des connexions de site point à point, telles que GRE et IPsec, ou ils peuvent établir une
connectivité universelle vers de nombreux sites utilisant MPLS.
IPsec est une suite de protocoles développés avec le support de l'IETF pour obtenir des
services sécurisés sur des réseaux IP à commutation de paquets, comme le montre la
figure. Les services IPsec permettent l'authentification, l'intégrité, le contrôle d'accès et la
confidentialité. Avec IPsec, les informations échangées entre sites distants peuvent être
cryptées et vérifiées. Les VPN d'accès distant et de site à site peuvent être déployés à l'aide
d'IPsec.
Diapositive 8
Diapositive 9

• Un VPN d'accès distant est créé

lorsque les informations VPN ne
sont pas configurées de manière
statique, mais permet de modifier
dynamiquement les informations
de connexion, qui peuvent être
activées et désactivées en cas
de besoin.

• Un VPN site à site est créé

lorsque les périphériques des
deux côtés de la connexion VPN
sont préalablement informés de
la configuration VPN. Le VPN
reste statique et les hôtes
internes ne savent pas qu'un
VPN existe.
Diapositive 10

Avec l'avènement des VPN, un utilisateur mobile a simplement besoin

d'accéder à Internet pour communiquer avec le bureau central. Dans le cas des
télétravailleurs, leur connectivité Internet est généralement une connexion à
large bande. Le télétravailleur n'a pas nécessairement la connexion VPN
établie tout le temps. Le PC du télétravailleur est responsable de
l'établissement du VPN. Les informations requises pour établir la connexion
VPN, telles que l'adresse IP du télétravailleur, changent dynamiquement en
fonction de l'emplacement du télétravailleur au moment de la tentative de
connexion.
Diapositive 11

Dans un VPN site à site, les hôtes envoient et reçoivent du trafic TCP / IP normal
via une passerelle VPN, qui peut être un routeur, un pare-feu, un concentrateur
VPN Cisco ou un Cisco ASA. La passerelle VPN est chargée d'encapsuler et de
crypter le trafic sortant d'un site particulier et de l'envoyer via un tunnel VPN sur
Internet à une passerelle VPN homologue sur l'autre site. Lors de la réception, la
passerelle VPN homologue retire les en-têtes, déchiffre le contenu et relaie le
paquet vers l'hôte cible à l'intérieur de son réseau privé.

Les topologies VPN site à site continuent d'évoluer. Des exemples de topologies VPN plus
complexes incluent le VPN MPLS (Multiprotocol Label Switching), le VPN DMVPN (Dynamic
Multipoint VPN) et le GETVPN (Group Encrypted Transport VPN).
Un VPN MPLS consiste en un ensemble de sites qui sont interconnectés au moyen d'un
réseau central de fournisseur MPLS. Sur chaque site client, un ou plusieurs périphériques de
périphérie client (CE) se connectent à un ou plusieurs périphériques de périphérie (PE)
fournisseur. Les VPN MPLS sont plus faciles à gérer et à développer que les VPN
classiques. Lorsqu'un nouveau site est ajouté à un VPN MPLS, seul le périphérique de
périphérie du fournisseur de services qui fournit des services au site client doit être mis à
jour.
Diapositive 12

À la fin de cette section, vous devriez être capable de:

• Décrire le protocole IPsec et ses fonctions de base.

• Comparer les protocoles AH et ESP.

• Décrire le protocole IKE.

Diapositive 13
Diapositive 14

 IPsec est une norme IETF (RFC 2401-2412) qui définit comment un VPN
peut être sécurisé sur les réseaux IP. IPsec protège et authentifie les
paquets IP entre la source et la destination. IPsec peut protéger
virtuellement tout le trafic de la couche 4 à la couche 7. Le framework
IPsec fournit ces fonctions de sécurité essentielles:
 Confidentialité en utilisant le cryptage
 Intégrité à l'aide d'algorithmes de hachage
 Authentification à l'aide d'Internet Key Exchange (IKE)
 Échange de clés sécurisé à l'aide de l'algorithme Diffie-Hellman (DH)
 IPsec n'est pas lié à des règles spécifiques pour les communications
sécurisées. Cette flexibilité du framework permet à IPsec d'intégrer
facilement de nouvelles technologies de sécurité sans mettre à jour les
standards IPsec existants.
 La figure 2 montre des exemples d'associations de sécurité (SA) pour
deux implémentations différentes. Une SA est le bloc de construction de
base d'IPsec. Lors de l'établissement d'un lien VPN, les homologues
doivent partager le même SA pour négocier les paramètres d'échange de
clés, établir une clé partagée, s'authentifier mutuellement et négocier les
paramètres de chiffrement.

Les technologies actuellement disponibles, illustrées à la Figure 1, sont alignées sur leur
fonction de sécurité spécifique.
Diapositive 15

Exemples d'implémentation
Cadre IPsec (Framework) IPsec
Diapositive 16

• La confidentialité est
obtenue en chiffrant
les données. Le degré
de sécurité dépend de
la longueur de la clé
utilisée dans
l'algorithme de
chiffrement.
• Une clé de 64 bits
peut prendre environ
un an pour se briser
avec un ordinateur
relativement
sophistiqué. Une clé
de 128 bits avec la
même machine peut
prendre environ 10 ^
19 ans pour être
décryptée.

Si quelqu'un tente de pirater la clé à travers une attaque par force brute, le nombre de
possibilités à essayer dépend de la longueur de la clé. Le temps nécessaire pour traiter toutes
les possibilités dépend de la puissance informatique de l'appareil attaquant. Plus la clé est
courte, plus il est facile de la casser.
Diapositive 17

Les algorithmes de cryptage mis en évidence sur la figure sont tous des
cryptosystèmes à clé symétrique.
Diapositive 18

Le code HMAC (Hashed Message

Authentication Code) est un
algorithme d'intégrité des données
qui garantit l'intégrité du message à
l'aide d'une valeur de hachage
calculée par une fonction de
hachage.

L'intégrité des données signifie que les données reçues sont exactement les mêmes que
celles qui ont été envoyées. Potentiellement, les données pourraient être interceptées et
modifiées. Par exemple, dans la figure 1, supposons qu'un chèque de 100 $ soit écrit à
Alex. Le chèque est ensuite posté à Alex, mais intercepté par un attaquant. L'attaquant
change le nom sur le chèque à Jeremy et le montant du chèque à 1 000 $ et tente de
l'encaisser. Selon la qualité de la falsification dans le chèque modifié, l'attaquant pourrait
réussir.
Étant donné que les données VPN sont transportées sur l'Internet public, une méthode de
vérification de l'intégrité des données est requise pour garantir que le contenu n'a pas été
modifié. La figure 2 met en évidence les deux algorithmes HMAC les plus courants.
Remarque: Cisco classe désormais SHA-1 en tant qu'héritage et recommande au moins SHA-
256 pour l'intégrité.
Diapositive 19

Méthodes d'authentification des

pairs

PSK:
PreShare
d Key

Lorsque vous effectuez des affaires sur de longues distances, il est nécessaire de savoir qui se
trouve à l'autre bout du téléphone, par courriel ou par télécopieur. La même chose est vraie
pour les réseaux VPN. Le périphérique situé à l'autre extrémité du tunnel VPN doit être
authentifié avant que le chemin de communication ne soit considéré comme sécurisé. La
Figure 1 met en évidence les deux méthodes d'authentification par les pairs.
Un exemple d'authentification PSK est illustré à la Figure 2. Sur le périphérique local, la clé
d'authentification et les informations d'identité sont envoyées via un algorithme de hachage
pour former le hachage pour l'homologue local (Hash_L). L'authentification unidirectionnelle
est établie en envoyant Hash_L à l'appareil distant. Si le périphérique distant peut créer
indépendamment le même hachage, le périphérique local est authentifié. Une fois que le
périphérique distant a authentifié le périphérique local, le processus d'authentification
commence dans la direction opposée et toutes les étapes sont répétées depuis le
périphérique distant vers le périphérique local.
Diapositive 20

RSA

Un exemple d'authentification RSA. Sur le périphérique local, la clé d'authentification et les

informations d'identité sont envoyées via l'algorithme de hachage pour former le hachage
pour l'homologue local (Hash_L). Ensuite, le Hash_L est chiffré à l'aide de la clé de
chiffrement privée du périphérique local. Cela crée une signature numérique. La signature
numérique et un certificat numérique sont transmis à l'appareil distant. La clé publique de
chiffrement pour déchiffrer la signature est incluse dans le certificat numérique. Le
périphérique distant vérifie la signature numérique en la décryptant à l'aide de la clé de
chiffrement publique. Le résultat est Hash_L. Ensuite, le périphérique distant crée
indépendamment Hash_L à partir des informations stockées. Si le Hash_L calculé est égal au
Hash_L déchiffré, le périphérique local est authentifié. Une fois que le périphérique distant a
authentifié le périphérique local, le processus d'authentification commence dans la direction
opposée et toutes les étapes sont répétées depuis le périphérique distant vers le
périphérique local.
Diapositive 21

Echange de clé par Diffie-Hellman

RFC 4869 définit un ensemble
d'algorithmes cryptographiques
respectant les normes de la
National Security Agency (NSA)
pour les informations
classifiées. Appelé Suite B, il
comprend les algorithmes
spécifiés:
• Le cryptage doit utiliser des clés
AES 128 ou 256 bits
• Hachage devrait utiliser SHA-2
• Les signatures numériques
doivent utiliser l'algorithme de
signature numérique à courbe
elliptique (ECDSA) avec des
modules de 256 ou 384 bits
• L'échange de clés devrait
utiliser Elliptic Curve Diffie-
Hellman (ECDH).

Les algorithmes de chiffrement nécessitent une clé secrète symétrique et partagée pour
effectuer le chiffrement et le déchiffrement. Comment les périphériques de chiffrement et
de déchiffrement obtiennent-ils la clé secrète partagée? La méthode d'échange de clé la plus
simple consiste à utiliser une méthode d'échange de clé publique, telle que Diffie-Hellman
(DH).
DH est une méthode d'échange de clé publique permettant à deux homologues d'établir une
clé secrète partagée qu'ils sont les seuls à connaître, même s'ils communiquent sur un canal
non sécurisé. Les variations de l'échange de clé DH sont spécifiées en tant que groupes DH:
• Les groupes DH 1, 2 et 5 prennent en charge l'exponentiation sur un module avec une
taille de clé de 768 bits, 1024 bits et 1536 bits, respectivement. Ces groupes n'étaient pas
recommandés après 2012.
• Les groupes DH 14, 15 et 16 utilisent des tailles de clé plus grandes avec 2048 bits, 3072
bits et 4096 bits, respectivement, et leur utilisation est recommandée jusqu'en 2030.
• Les groupes DH 19, 20, 21 et 24 avec des tailles de clé respectives 256 bits, 384 bits, 521
bits et 2048 bits prennent en charge la cryptographie à courbe elliptique (ECC), ce qui
 réduit le temps nécessaire pour générer des clés. Le groupe DH 24 est le cryptage de
nouvelle génération préféré.

Le groupe DH choisi doit être assez fort ou avoir suffisamment de bits pour protéger les clés
IPsec pendant la négociation. Par exemple, le groupe DH 1 est suffisamment puissant pour
prendre en charge uniquement le cryptage DES et 3DES, mais pas AES. Si les algorithmes de
chiffrement ou d'authentification utilisent une clé de 128 bits, utilisez le groupe 14, 19, 20 ou
24. Si les algorithmes de chiffrement ou d'authentification utilisent une clé de 256 bits ou
plus, utilisez le groupe 21 ou 24. L'exemple de configuration dans le chapitre utilise le
cryptage 256 bits et le groupe DH 24. Pendant la configuration du tunnel, les homologues
VPN négocient quel groupe DH utiliser.
Diapositive 22
Diapositive 23

Les deux principaux protocoles IPsec sont Authentication Header (AH) et

Encapsulation Security Protocol (ESP). Le protocole IPsec est le premier
bloc de construction du framework. Le choix de AH ou ESP détermine
quels autres blocs de construction sont disponibles.
Diapositive 24

Protocoles AH
En-tête d'authentification (AH)
 Protocole approprié à utiliser
lorsque la confidentialité n'est
pas requise ou autorisée.
 Permet l'authentification et
l'intégrité des données des
paquets IP qui sont transmis
entre deux systèmes.
 Ne permet pas la confidentialité
des données (chiffrement) des
paquets.

AH vise l'authenticité en appliquant une fonction de hachage unidirectionnelle à clé au

paquet pour créer un condensé de hachage ou de message. Le hachage est combiné avec le
texte et est transmis en clair, comme le montre la figure 1. Le récepteur détecte les
changements dans une partie du paquet qui se produisent pendant le transit en effectuant la
même fonction de hachage unidirectionnelle sur le paquet reçu et en comparant le résultat à
la valeur du résumé du message que l'expéditeur a fourni. L'authenticité est assurée car le
hachage unidirectionnel utilise également une clé secrète partagée entre les deux systèmes.
La fonction AH est appliquée à l'ensemble du paquet, à l'exception de tous les champs d'en-
tête IP qui changent normalement en transit. Les champs qui changent normalement
pendant le transit sont appelés champs mutables. Par exemple, le champ Time to Live (TTL)
est considéré comme modifiable car les routeurs modifient ce champ.
Diapositive 25

Le routeur crée un hachage et le

transmet à un pair

Le routeur homologue compare le

hachage recalculé au hachage reçu

Le processus AH se produit dans cet ordre:

1. L'en-tête IP et la charge utile de données sont hachés à l'aide de la clé secrète partagée.
2. Le hachage construit un nouvel en-tête AH, qui est inséré dans le paquet d'origine.
3. Le nouveau paquet est transmis au routeur homologue IPsec.
4. Le routeur homologue hache l'en-tête IP et la charge utile de données à l'aide de la clé
secrète partagée, extrait le hachage transmis de l'en-tête AH et compare les deux hachages.
Les hachages doivent correspondre exactement. Si un bit est modifié dans le paquet
transmis, la sortie de hachage sur le paquet reçu change et l'en-tête AH ne correspond pas.
AH prend en charge les algorithmes MD5 et SHA. AH peut ne pas fonctionner si
l'environnement utilise NAT.
Diapositive 26

ESP assure la confidentialité

en chiffrant la charge utile,
comme indiqué sur la figure. Il
prend en charge une variété
d'algorithmes de chiffrement
symétrique. Si ESP est
sélectionné comme protocole
IPsec, un algorithme de
cryptage doit également être
sélectionné. L'algorithme par
défaut pour IPsec est DES à
56 bits. Les produits Cisco
prennent également en charge
l'utilisation de 3DES, AES et
SEAL pour un chiffrement
renforcé.

ESP peut également fournir l'intégrité et l'authentification. Premièrement, la charge utile est
cryptée. Ensuite, la charge utile chiffrée est envoyée via un algorithme de hachage, tel que
MD5 ou SHA. Le hachage fournit l'authentification et l'intégrité des données pour la charge
utile de données.
En option, l'ESP peut également appliquer une protection anti-rejeu. La protection anti-
relecture vérifie que chaque paquet est unique et n'est pas dupliqué. Cette protection
garantit qu'un pirate ne peut pas intercepter les paquets et insérer les paquets modifiés dans
le flux de données. Anti-replay fonctionne en gardant une trace des numéros de séquence de
paquets et en utilisant une fenêtre glissante sur la destination.
Lorsqu'une connexion est établie entre une source et une destination, leurs compteurs sont
initialisés à zéro. Chaque fois qu'un paquet est envoyé, un numéro de séquence est ajouté au
paquet par la source. La destination utilise la fenêtre glissante pour déterminer les numéros
de séquence attendus. La destination vérifie que le numéro de séquence du paquet n'est pas
dupliqué et qu'il est reçu dans le bon ordre.
Par exemple, si la fenêtre glissante sur la destination est définie sur un, la destination
s'attend à recevoir le paquet avec le numéro de séquence un. Après réception, la fenêtre
glissante passe à deux. Lorsque la détection d'un paquet relu se produit, par exemple lorsque
la destination reçoit un second paquet avec le numéro de séquence de un, un message
d'erreur est envoyé, le paquet relu est ignoré et l'événement est consigné.
L'anti-replay est généralement utilisé dans ESP, mais il est également pris en charge dans AH.
Diapositive 27

ESP offre la possibilité de protéger les données d'origine car le datagramme IP

entier et la bande-annonce ESP sont cryptés. Avec l'authentification ESP, le
datagramme IP et la bande-annonce ainsi que l'en-tête ESP sont inclus dans
le processus de hachage, comme le montre la figure. Ensuite, un nouvel en-
tête IP est attaché à la charge utile authentifiée. La nouvelle adresse IP est
utilisée pour acheminer le paquet via Internet.
Lorsque l'authentification et le cryptage sont sélectionnés, le cryptage est
effectué en premier.

Une raison de cet ordre de traitement est qu'il facilite la détection et le rejet rapides des
paquets rejoués ou faux par le dispositif de réception. Avant de déchiffrer le paquet, le
récepteur peut authentifier les paquets entrants. En faisant cela, il peut détecter rapidement
les problèmes et potentiellement réduire l'impact des attaques DoS.
Jusqu'à présent, la discussion sur IPsec s'est concentrée sur IPv4. Toutefois, IPsec a été
initialement créé pour assurer la sécurité des paquets IPv6. Par conséquent, les
implémentations IPsec pour IPv4 et IPv6 sont similaires en ce qui concerne les normes. En
IPv4, AH et ESP sont des en-têtes de protocole IP. IPv6 utilise les en-têtes d'extension avec
une valeur d'en-tête de 50 pour ESP et de 51 pour AH.
Diapositive 28

• Mode de transport
En mode transport, la sécurité est fournie uniquement pour la couche transport du
modèle OSI et au-dessus. Le mode transport protège la charge utile du paquet
mais laisse l'adresse IP d'origine en clair. L'adresse IP d'origine est utilisée pour
acheminer le paquet via Internet. Le mode transport ESP est utilisé entre les
hôtes.
• Mode tunnel
Le mode Tunnel fournit une sécurité pour le paquet IP original complet. Le paquet
IP d'origine est chiffré, puis encapsulé dans un autre paquet IP. C'est ce qu'on
appelle le cryptage IP-in-IP. L'adresse IP sur le paquet IP extérieur est utilisée
pour acheminer le paquet via Internet.
Diapositive 29

Le mode transport AH fournit une authentification et une intégrité pour

l'ensemble du paquet. Il ne crypte pas les données, mais il est protégé contre
les modifications. Le mode tunnel AH encapsule le paquet IP AH dans un
nouvel en-tête IP, et signe le paquet entier pour l'intégrité et l'authentification.
Diapositive 30
Diapositive 31

 Le protocole IKE (Internet Key Exchange) est une norme de protocole de

gestion des clés.
 IKE négocie automatiquement les associations de sécurité IPsec et active les
communications sécurisées IPsec.
 IKE est un protocole hybride qui implémente des protocoles d'échange de clés
dans le cadre ISAKMP (Internet Security Association Key Management
Protocol).
 ISAKMP définit le format du message, la mécanique d'un protocole d'échange
de clés et le processus de négociation pour construire une SA pour IPsec.
 Au lieu de transmettre des clés directement à travers un réseau, IKE calcule
des clés partagées basées sur l'échange d'une série de paquets de
données. Cela empêche un tiers de déchiffrer les clés même si le tiers a
capturé toutes les données échangées qui ont été utilisées pour calculer les
clés.
 IKE utilise le port UDP 500 pour échanger des informations IKE entre les
passerelles de sécurité.
 Les paquets du port UDP 500 doivent être autorisés sur toute interface IP qui
connecte un homologue de passerelle de sécurité.

IKE améliore IPsec en ajoutant des fonctionnalités et simplifie la configuration pour la norme
IPsec. Sans IKE en place, la configuration IPsec serait un processus de configuration manuel
complexe qui ne serait pas bien adapté.
Diapositive 32
Diapositive 33

IKE utilise ISAKMP pour la phase 1 et la phase 2 de la négociation de clé. La phase 1 négocie
une association de sécurité (une clé) entre deux homologues IKE. La clé négociée en phase 1
permet aux homologues IKE de communiquer de manière sécurisée en phase 2. Lors de la
négociation de la phase 2, IKE établit des clés (associations de sécurité) pour d'autres
applications, telles que IPsec.
Dans la phase 1, deux homologues IPsec effectuent la négociation initiale des SA. L'objectif
de base de la phase 1 est de négocier la politique ISAKMP, d'authentifier les homologues et
de mettre en place un tunnel sécurisé entre les homologues. Ce tunnel sera ensuite utilisé
dans la phase 2 pour négocier la politique IPsec, comme le montre la figure.
Remarque : Les règles IKE et ISAKMP sont équivalentes. L'expression politique ISAKMP est
utilisée dans ce cours pour mieux répondre aux commandes ( crypto isakmp policy, show
isakmp policy, etc.).
La phase 1 peut être implémentée en mode principal ou en mode agressif. Lorsque le mode
principal est utilisé, les identités des deux homologues IKE sont masquées. Le mode agressif
prend moins de temps que le mode principal pour négocier les clés entre
homologues. Cependant, puisque le hachage d'authentification est envoyé non crypté avant
l'établissement du tunnel, le mode agressif est vulnérable aux attaques par force brute.
Remarque : Dans le logiciel Cisco IOS, l'action par défaut pour l'authentification IKE consiste
à activer le mode principal. Cependant, le logiciel Cisco IOS répondra en mode agressif à un
homologue IKE qui initie le mode agressif.
Diapositive 34

Le but de IKE Phase 2 est de négocier les paramètres de sécurité IPsec qui
seront utilisés pour sécuriser le tunnel IPsec

IKE Phase 2 est appelé mode rapide et ne peut se produire qu'après que IKE a établi un
tunnel sécurisé dans la Phase 1. Les SA sont négociées par le processus IKE ISAKMP au nom
d'IPsec, qui a besoin de clés de chiffrement pour fonctionner. Le mode rapide négocie les SA
IKE Phase 2. Dans cette phase, les SA utilisées par IPsec sont unidirectionnelles; par
conséquent, un échange de clé séparé est requis pour chaque flux de données.
Le mode rapide renégocie également une nouvelle SA IPsec lorsque la durée de vie IPsec SA
expire. Fondamentalement, le mode rapide actualise le matériel de chiffrement qui crée la
clé secrète partagée. Ceci est basé sur le matériel de chiffrement qui est dérivé de l'échange
DH dans la phase 1.

IKE version 2, un protocole de gestion de clés de nouvelle génération basé sur RFC 4306 , est
une amélioration du protocole IKE. IKE version 2 prend en charge la détection NAT pendant la
phase 1 et NAT Traversal (NAT-T) pendant la phase 1. Si les deux périphériques VPN sont
compatibles NAT-T et s'ils détectent qu'ils se connectent via un périphérique NAT, NAT-T est
auto détecté et auto négocié. NAT-T encapsule les paquets ESP dans UDP et attribue les ports
Source et Destination à 4500. Les paquets ESP peuvent maintenant traverser le NAT.
Diapositive 35

À la fin de cette section, vous devriez être capable de:

• Décrire la négociation IPsec et les cinq étapes de la configuration IPsec.

• Configurer la stratégie ISAKMP.

• Configurer la stratégie IPsec.

• Configurer et appliquer une carte de chiffrement (crypto map).

• Vérifier le VPN IPsec.

Diapositive 36
Diapositive 37

Négociation VPN IPsec:

Étape 1 - L'hôte A envoie
un trafic intéressant à l'hôte
B.

Négociation VPN IPsec:

Etape 2 - R1 et R2
négocient une session IKE
Phase 1.

Négociation VPN
IPsec: Étape 3 - R1 et
R2 négocient une
session IKE Phase 2.

La négociation IPsec pour établir un VPN implique cinq étapes, parmi lesquelles IKE Phase 1
et Phase 2:
Étape 1. Un tunnel ISAKMP est initié lorsque l'hôte A envoie un trafic "intéressant" à l'hôte B.
Le trafic est considéré comme intéressant lorsqu'il se déplace entre les homologues et
répond aux critères définis dans une ACL (Figure 1).
Étape 2. IKE Phase 1 commence. Les pairs négocient la politique d'ISAKMP SA. Lorsque les
pairs sont d'accord sur la politique et sont authentifiés, un tunnel sécurisé est créé (Figure 2).
Étape 3. IKE Phase 2 commence. Les homologues IPsec utilisent le tunnel sécurisé authentifié
pour négocier la stratégie IPsec SA. La négociation de la politique partagée détermine
comment le tunnel IPsec est établi (Figure 3).
Diapositive 38

Négociation VPN IPsec:

Etape 4 - Les informations
sont échangées via un
tunnel IPsec.

Négociation VPN
IPsec: Étape 5 - Le
tunnel IPsec est
terminé.

Étape 4. Le tunnel IPsec est créé et les données sont transférées entre les homologues IPsec
en fonction des SA IPsec (Figure 4).
Étape 5. Le tunnel IPsec se termine lorsque les SA IPsec sont supprimées manuellement ou
lorsque leur durée de vie expire (Figure 5).
Diapositive 39

L'implémentation d'un VPN site à site nécessite la configuration de paramètres pour IKE
Phase 1 et Phase 2. Dans la configuration de phase 1, les deux sites sont configurés avec les
associations de sécurité ISAKMP nécessaires pour garantir la création d'un tunnel
ISAKMP. Dans la configuration de phase 2, les deux sites sont configurés avec les associations
de sécurité IPsec pour garantir la création d'un tunnel IPsec dans le tunnel ISAKMP. Les deux
tunnels ne seront créés que lorsqu'un trafic intéressant est détecté.
La topologie de la figure pour XYZCORP sera utilisée dans cette section pour illustrer une
implémentation VPN IPsec de site à site. Cliquez sur chaque routeur pour afficher la
configuration actuelle. Les deux routeurs sont configurés avec un adressage IP et un routage
statique. Un ping étendu sur R1 vérifie que le routage entre les réseaux locaux est
opérationnel.
Diapositive 40

XYZCORP Security Policy Configuration Tasks

Encrypt traffic with AES 256 and SHA
Authentication with PSK
Exchange keys with group 24
ISAKMP tunnel lifetime is 1 hour
IPsec tunnel uses ESP with a 15-min. lifetime
1. Configure the ISAKMP policy for IKE Phase 1
2. Configure the IPsec policy for IKE Phase 2
3. Configure the crypto map for IPsec policy
4. Apply the IPsec policy
5. Verify the IPsec tunnel is operational

Les exigences de politique de sécurité pour les implémentations VPN IPsec de site à site
XYZCORP sont illustrées dans la Figure. Les tâches de configuration requises pour satisfaire à
cette politique sont aussi illustrées à la même Figure.
Diapositive 41

Syntaxe ACL pour

le trafic IPsec

Bien que XYZCORP n'ait pas de configuration ACL existante, ce ne serait pas le cas dans un
réseau de production. Les routeurs de périmètre implémentent généralement une stratégie
de sécurité restrictive, bloquant tout le trafic sauf pour le trafic spécifiquement
autorisé. Avant d'implémenter un VPN IPsec site à site, assurez-vous que les ACL existantes
ne bloquent pas le trafic nécessaire aux négociations IPsec. La syntaxe de la commande ACL
permettant le trafic ISAKMP, ESP et AH est illustrée à la Figure.
Diapositive 42

Permettre le trafic pour les négociations IPsec

Cliquez sur R1 pour afficher une configuration ACL qui autoriserait le trafic nécessaire aux
négociations IPsec. R2 aurait une configuration similaire.
Diapositive 43

La topologie XYZCORP utilise le routage statique, il n'y a donc pas de trafic de diffusion ou de
multidiffusion qui doit être acheminé via le tunnel. Mais que se passerait-il si XYZCORP
décidait d'implémenter EIGRP ou OSPF? Ces protocoles de routage utilisent des adresses de
multidiffusion pour échanger des informations de routage avec des voisins. IPsec ne prend
en charge que le trafic monodiffusion. Pour activer le trafic de protocole de routage, les
homologues d'une implémentation VPN IPsec de site à site doivent être configurés avec un
tunnel GRE (Generic Routing Encapsulation) pour le trafic de multidiffusion.
Le protocole GRE prend en charge le tunneling multiprotocole, comme illustré dans la
figure. Il peut encapsuler plusieurs types de paquets de protocole de couche 3 OSI dans un
tunnel IP. L'ajout d'un en-tête GRE supplémentaire entre la charge utile et l'en-tête IP de
tunnellisation fournit la fonctionnalité multiprotocole. Le protocole GRE prend également en
charge le tunneling multidiffusion IP. Les protocoles de routage utilisés dans le tunnel
permettent l'échange dynamique d'informations de routage dans le réseau virtuel. GRE ne
fournit pas de chiffrement.
Diapositive 44
Diapositive 45

La première tâche consiste à configurer la stratégie ISAKMP pour IKE Phase 1. La stratégie
ISAKMP répertorie les SA que le routeur est prêt à utiliser pour établir le tunnel IKE Phase
1. Cisco IOS vient avec les politiques ISAKMP par défaut déjà en place. Pour afficher les
stratégies par défaut, entrez la commande show crypto isakmp default policy, comme
indiqué dans la figure.
R1 a sept politiques ISAKMP par défaut allant de la plus sécurisée (politique 65507) à la
moins sécurisée (politique 65514). Si aucune autre stratégie n'a été définie par
l'administrateur, R1 tentera d'utiliser la stratégie par défaut la plus sécurisée. Si R2 a une
politique de correspondance, alors R1 et R2 peuvent négocier avec succès le tunnel ISAKMP
de phase 1 IKE sans aucune configuration par l'administrateur. Sept politiques par défaut
permettent une flexibilité dans les négociations. S'il n'y a pas d'accord pour utiliser la
stratégie par défaut la plus sécurisée, R1 tentera d'utiliser la stratégie la plus sécurisée
suivante.
Dans cet exemple, aucune des stratégies par défaut ne correspond à la stratégie de sécurité
de XYZCORP. Une nouvelle politique ISAKMP devra donc être configurée.
Diapositive 46

Pour configurer une nouvelle stratégie ISAKMP, utiliser la commande crypto isakmp
policy Numéro, comme indiqué dans la figure. Le seul argument pour la commande est de
définir une priorité pour la stratégie (de 1 à 10000). Les pairs tenteront de négocier en
utilisant la politique avec le nombre le plus bas (priorité la plus élevée). Les pairs n'ont pas
besoin de numéros de priorité correspondants.
En mode de configuration de stratégie ISAKMP, les SA du tunnel IKE Phase 1 peuvent être
configurées. Utilisez la mnémonique HAGLE pour vous rappeler les cinq SA à configurer:
• H ash
• A uthentication
• G roup
• L ifetime
• E ncryption
Diapositive 47

Pour répondre aux exigences de stratégie de sécurité pour XYZCORP, configurez la stratégie
ISAKMP avec les SA suivantes:
• Hash est SHA
• L'authentification est une clé pré-partagée
• Le groupe DH est 24
• La durée de vie est de 3600 secondes
• Le cryptage est AES 256
Utiliser la commande show crypto isakmp policy pour vérifier la configuration. Dans la
figure, cliquer sur R1 pour afficher la configuration de la stratégie ISAKMP. R2 a une
configuration équivalente.
Diapositive 48

La commande crypto isakmp key

La stratégie de sécurité XYZCORP requiert l'utilisation d'une clé pré-partagée pour

l'authentification entre les homologues. La syntaxe de la commande est illustrée à la Figure.
L'administrateur peut spécifier un nom d'hôte ou une adresse IP pour l'homologue. XYZCORP
utilise la phrase clé cisco12345 et l'adresse IP du pair.
Diapositive 49

Configuration de la clé pré-partagée

Diapositive 50
Diapositive 51

Le tunnel IKE Phase 1 n'existe pas encore

Bien que la stratégie ISAKMP pour le tunnel IKE Phase 1 soit configurée, le tunnel n'existe pas
encore. Ceci est vérifié avec la commande show crypto isakmp sa dans la Figure 1. Un trafic
intéressant doit être détecté avant que les négociations IKE Phase 1 puissent
commencer. Pour le VPN site-à-site XYXCORP, le trafic intéressant est toute communication
entre les LAN du Site 1 et du Site 2.
Pour définir un trafic intéressant, configurer chaque routeur avec une ACL pour autoriser le
trafic du LAN local vers le LAN distant. La liste de contrôle d'accès sera utilisée dans la
configuration de la crypto map pour spécifier le trafic qui déclenchera le démarrage de IKE
Phase 1.
Diapositive 52

Configurer une ACL pour définir le trafic intéressant

Les routeurs des Figures 1 et 2 affichent la configuration de la liste de contrôle d'accès.

Diapositive 53

La commande crypto ipsec transform-set

L'étape suivante consiste à configurer l'ensemble des algorithmes de cryptage et de hachage

qui seront utilisés pour transformer les données envoyées via le tunnel IPsec. C'est ce qu'on
appelle transform set. Lors des négociations IKE Phase 2, les homologues conviennent
du IPsec transform set à utiliser pour protéger le trafic intéressant.
Configurer un transform set à l'aide de la commande crypto ipsec transform-set, comme
indiqué dans la Figure. D'abord, spécifier un nom pour le transform set (R1-R2, dans
l'exemple). L'algorithme de cryptage et de hachage peut ensuite être configuré dans
n'importe quel ordre.
Diapositive 54

La commande crypto ipsec transform-set

Diapositive 55
Diapositive 56

Paramètre Description
Map-name Identifie la crypto map set.
Seq-num Numéro de séquence que vous attribuez à l'entrée
crypto map. Utilisez la commande crypto map map-
name seq-num pour modifier l'entrée ou le profil de la
crypto map existante.
Ipsec-isakmp Indique que IKE sera utilisé pour établir IPsec pour
protéger le trafic spécifié par cette entrée de la crypto
map.
Ipsec-manual Indique que IKE ne sera pas utilisé pour établir les SA
IPsec pour protéger le trafic spécifié par cette entrée
de la crypto map entry.

Maintenant que le trafic intéressant est défini et qu'un IPsec transform set est configuré, il
est temps de lier ces configurations avec le reste de la stratégie IPsec dans une Crypto
map. La syntaxe permettant de démarrer une crypto map est illustrée à la figure. Le numéro
de séquence est important lors de la configuration de plusieurs entrées de crypto
map. XYZCORP n'aura besoin que d'une entrée de crypto map pour faire correspondre le
trafic et compte pour les SA restantes. Bien que l' option ipsec-manual soit affichée, son
utilisation sort du cadre de ce cours.
Diapositive 57

Commande de configuration de Crypto Map

La figure affiche les configurations disponibles pour une entrée crypto map lorsqu’on est en
mode de configuration de crypto map. Le nom de la crypto map est R1-R2_MAP et le
numéro de séquence est 10.
Diapositive 58

Configuration de Crypto Map :

Pour terminer la configuration afin de respecter la stratégie de sécurité IPsec pour XYZCORP,
procédez comme suit:
Étape 1. Liez l'ACL et transform set à la crypto map.
Étape 2. Spécifiez l'adresse IP de l'homologue.
Étape 3. Configurez le groupe DH.
Étape 4. Configurez la durée de vie du tunnel IPsec.
Diapositive 59

Vérification de la configuration de la Crypto Map:

Utiliser la commande show crypto map pour vérifier la configuration de la crypto map,
comme indiqué dans la Figure. Toutes les SA requises doivent être en place. Notez dans la
section en surbrillance de la figure qu'aucune interface n'est actuellement répertoriée
comme utilisant la crypto map.
Diapositive 60

Pour appliquer la crypto map, entrer dans le mode de configuration d'interface pour
l'interface sortante et configurer la commande crypto map map-name. Notez que
la sortie show crypto map affiche maintenant que l'interface Serial 0/0/0 utilise la crypto
map. R2 est configuré avec la même commande sur son interface Serial 0/0/0.
Diapositive 61
Diapositive 62

Utiliser le ping étendu pour envoyer un trafic intéressant

Maintenant que les stratégies ISAKMP et IPsec sont configurées et que la crypto map est
appliquée aux interfaces sortantes appropriées, tester les deux tunnels en envoyant un trafic
intéressant sur le lien.
Le trafic de l'interface LAN sur R1 destiné à l'interface LAN sur R2 est considéré comme un
trafic intéressant car il correspond aux ACL configurées sur les deux routeurs. Un ping étendu
de R1 testera efficacement la configuration VPN. Le premier ping a échoué car il faut
quelques millisecondes pour établir les tunnels ISAKMP et IPsec.
Diapositive 63

Vérifier que le tunnel ISAKMP est établi

L'envoi d'un trafic intéressant ne signifie pas que les tunnels sont établis. R1 et R2 routent le
trafic entre les deux réseaux locaux même si les configurations de stratégie ISAKMP et IPsec
sont erronées. Pour vérifier que les tunnels ont été établis, utiliser les commandes show
crypto isakmp sa et show crypto ipsec sa.
Cliquer sur R1 dans la figure 1 pour voir la sortie pour le tunnel ISAKMP. Noter que le tunnel
est actif entre les deux homologues, 172.30.2.1 et 172.30.2.2.
Diapositive 64

Vérifier que le tunnel IPsec est établi

Cliquer sur R1 dans la figure 2 pour voir la sortie pour le tunnel IPsec.
Diapositive 65

Objectifs du chapitre:
• Expliquer l'objectif des VPN.

• Expliquer comment les VPN IPsec fonctionnent.

• Configurez un VPN IPsec de site à site, avec l'authentification par clé

pré-partagée, en utilisant l'interface de ligne de commande.