🔑 IPsec et IKEv2 — Fondements VPN

🎯 Introduction (10 min)

En 2019, une vulnérabilité critique (CVE-2019-11510) a été découverte dans Pulse Secure : un 0-day permettant la lecture de fichiers sensibles sans authentification, facilitant l'accès non autorisé à des réseaux d'entreprises et massivement exploité par des groupes APT. Cet incident montre à quel point une mauvaise configuration ou des logiciels non mis à jour côté VPN peuvent ouvrir des portes sur l'ensemble du SI d'une PME. Dans le contexte du télétravail massif de 2020, des VPN mal configurés ont amplifié les risques — l'objectif de cette séance est de comprendre les protocoles et les mécanismes d'IPsec pour concevoir des VPN robustes.

🎯 Objectifs de la séance

À l'issue de cette séance, vous serez capable de :

• Expliquer les principaux protocoles VPN (L2TP/IPsec, SSL VPN, OpenVPN) et les différences IKEv1 vs IKEv2.
• Détailler les mécanismes d'IPsec (SA, ESP, AH, modes tunnel/transport, phases IKE) et choisir des paramètres cryptographiques pertinents (AES-256-GCM, SHA-256/384, DH groups).
• Configurer et vérifier une mise en œuvre site-à-site IPsec IKEv2 sur routeurs Cisco et diagnostiquer une négociation.

1. Protocoles VPN (70 min)

Les VPN sont des solutions qui permettent d'étendre un réseau privé au-dessus d'un réseau non fiable (Internet). Il existe deux grandes familles : les VPN basés sur IPsec (opérés au niveau IP) et les VPN basés sur TLS/SSL (opérés au-dessus de TCP/UDP). Chaque choix a des conséquences opérationnelles (interopérabilité, NAT traversal, gestion des certificats) et de sécurité.

1.1 L2TP/IPsec — historique et usage

L2TP est un protocole de tunneling qui transporte des trames PPP ; il est fréquemment utilisé conjointement avec IPsec pour fournir chiffrement et intégrité. Les clients Windows/macOS disposent d'un support natif pour L2TP/IPsec, ce qui en fait une solution courante pour des accès distants légers. L2TP encapsule des sessions PPP, puis IPsec (ESP) chiffre le trafic ; la négociation des clés se fait via IKE (UDP 500) avec NAT-T en UDP 4500 si un NAT est rencontré.

1.2 SSL VPN / TLS-based VPN

Les solutions SSL VPN (ex : appliances type Pulse Secure, ou serveurs OpenVPN en TLS) utilisent la pile TLS. Elles offrent souvent une expérience utilisateur plus flexible (port 443, meilleur NAT traversal) et peuvent proposer des modes « clientless » pour accès web. Les clients OpenVPN peuvent s'appuyer sur TLS mutual auth (certificats) pour l'authentification forte côté client.

1.3 OpenVPN

OpenVPN est une implémentation TLS robuste et très utilisée en PME : il supporte les modes tun (Layer 3) et tap (Layer 2), fonctionne sur UDP/TCP, et permet d'utiliser une PKI (easy-rsa) pour mutualiser confiance et révocation. OpenVPN est simple à déployer sur Debian et sur des postes clients Linux/Windows.

1.4 IKEv1 vs IKEv2

IKEv1 (ancêtre) utilise deux modes d'échange (main/aggressive) et est plus verbeux ; IKEv2 refond le protocole : échanges simplifiés, meilleure gestion du rekey, support natif de MOBIKE (mobilité) et meilleure résistance au NAT. IKEv2 est recommandé pour les déploiements modernes, il supporte EAP pour des authentifications avancées et négocie plus clairement les suites crypto (proposals).

2. IPsec — concepts et paramètres (70 min)

IPsec n'est pas un seul protocole mais un ensemble : les Security Associations (SA) définissent l'ensemble des paramètres cryptographiques (algorithme de chiffrement, algorithme d'intégrité, durée de vie, paramètres DH). Deux protocoles principaux protègent le trafic :

• AH (Authentication Header) : fournit intégrité et authentification de paquets y compris certains champs d'en-tête IP, mais il est peu compatible avec le NAT.
• ESP (Encapsulating Security Payload) : fournit chiffrement et authentification des données — c'est le choix par défaut pour la plupart des VPN.

Tunnel vs transport

IKE — phases de négociation

• Phase 1 (ISAKMP / IKE SA) : négociation d'une SA IKE (authentification et échange de clés Diffie-Hellman). IKEv1 distingue main mode / aggressive mode ; IKEv2 fait tout en une série d'échanges plus robustes (IKE_SA_INIT + IKE_AUTH).
• Phase 2 (IPsec SA / Quick Mode) : négociation des SAs IPsec (ESP/AH) qui vont chiffrer réellement le trafic.

Paramètres cryptographiques recommandés

Certificats PKI vs PSK

3. Exemple de configuration Cisco IKEv2 site-à-site

Contexte : R1 (Siège Nice) IP publique 91.208.45.12, R2 (Succursale Cannes) IP publique 203.0.113.2.
Réseaux locaux : Nice 192.168.10.0/24, Cannes 192.168.30.0/24.

R1 (Nice) — configuration IKEv2 + IPsec

! Contexte IOS 16.x — Routeur R1 (Nice)
hostname R1-Nice
!
interface GigabitEthernet0/0
 description WAN
 ip address 91.208.45.12 255.255.255.248
!
crypto ikev2 proposal IKEV2-PROP
 encryption aes-gcm-256
 integrity sha256
 group 14
!
crypto ikev2 policy IKEV2-POL
 proposal IKEV2-PROP
!
crypto ikev2 keyring KEYRING-NICE
 peer R2-Cannes
  address 203.0.113.2
  pre-shared-key local  0 MyVerySecretPSK
  pre-shared-key remote 0 MyVerySecretPSK
!
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 203.0.113.2 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KEYRING-NICE
 proposal IKEV2-POL
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS
 set ikev2-profile IKEV2-PROFILE
!
interface Tunnel0
 ip address 10.10.10.1 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 203.0.113.2
 tunnel protection ipsec profile IPSEC-PROFILE
!
ip route 192.168.30.0 255.255.255.0 Tunnel0

R2 (Cannes) — configuration miroir

hostname R2-Cannes
!
interface GigabitEthernet0/0
 ip address 203.0.113.2 255.255.255.248
!
crypto ikev2 proposal IKEV2-PROP
 encryption aes-gcm-256
 integrity sha256
 group 14
!
crypto ikev2 keyring KEYRING-CANNES
 peer R1-Nice
  address 91.208.45.12
  pre-shared-key local  0 MyVerySecretPSK
  pre-shared-key remote 0 MyVerySecretPSK
!
crypto ikev2 profile IKEV2-PROFILE
 match identity remote address 91.208.45.12 255.255.255.255
 authentication local pre-share
 authentication remote pre-share
 keyring local KEYRING-CANNES
 proposal IKEV2-POL
!
crypto ipsec transform-set TS esp-aes 256 esp-sha256-hmac
 mode tunnel
!
crypto ipsec profile IPSEC-PROFILE
 set transform-set TS
 set ikev2-profile IKEV2-PROFILE
!
interface Tunnel0
 ip address 10.10.10.2 255.255.255.252
 tunnel source GigabitEthernet0/0
 tunnel destination 91.208.45.12
 tunnel protection ipsec profile IPSEC-PROFILE
!
ip route 192.168.10.0 255.255.255.0 Tunnel0

Vérification et sorties attendues

! Vérifier IKEv2 SA (R1 ou R2)
Router# show crypto ikev2 sa
ID LOCAL                 REMOTE                fvrf  fpolicy
1 91.208.45.12:500       203.0.113.2:500       0     active
  IKEv2 SA established, encrypted: 1, authenticated: 1

! Vérifier IPsec SA
Router# show crypto ipsec sa
interface: Tunnel0
    Crypto map tag: IPSEC-MAP, seqnum: 10, local addr: 91.208.45.12
    local  ident (addr/mask/prot/port): (91.208.45.12/255.255.255.255/0/0)
    remote ident (addr/mask/prot/port): (203.0.113.2/255.255.255.255/0/0)
    current_peer 203.0.113.2
    #pkts encaps: 12, #pkts encrypt: 12, #pkts digest: 12

🛠️ Travaux Pratiques (70 min)

Contexte du TP

Vous êtes technicien chez InnovatTech SARL (Nice). Le siège (R1 — Cisco ISR 4321) doit établir un VPN site-à-site IPsec IKEv2 vers la succursale Cannes (R2 — Cisco). Le responsable réseau vous fournit les adresses publiques et vous demande une configuration IKEv2 avec PSK pour valider le mécanisme avant migration vers PKI.

Objectif

Configurer un VPN site-à-site IPsec IKEv2 entre R1 (Nice) et R2 (Cannes), vérifier la négociation IKE et IPsec, et vérifier que les réseaux 192.168.10.0/24 et 192.168.30.0/24 peuvent communiquer via le tunnel.

Prérequis techniques

• Accès console/SSH aux routeurs R1 et R2 (IOS 16.x) avec privilèges d'administration.
• Adresses publiques assignées : 91.208.45.12 pour R1, 203.0.113.2 pour R2.
• Accès au plan d'adressage InnovatTech (réseaux locaux déjà configurés).
• Outil de test : un poste Linux sur 192.168.10.X capable de pinger 192.168.30.5.

Étapes

1. Préparer les adresses et ACLs

Sur chaque routeur, vérifiez les interfaces WAN et les routes vers les réseaux locaux.

! Vérifier interfaces
R1# show ip interface brief
R2# show ip interface brief

2. Configurer IKEv2 et IPsec (R1 puis R2)

Copier/adapter les blocs de configuration fournis dans la section précédente (proposals, keyring, profile, ipsec profile, Tunnel0). Utiliser la même PSK sur les deux pairs (MyVerySecretPSK dans l'exemple), ou de préférence stocker les PSK dans un gestionnaire sécurisé.

3. Activer le routage vers le tunnel

R1(config)# ip route 192.168.30.0 255.255.255.0 Tunnel0
R2(config)# ip route 192.168.10.0 255.255.255.0 Tunnel0

4. Vérifier la négociation

R1# show crypto ikev2 sa
R1# show crypto ipsec sa
! (optionnel si IKEv1 présent)
R1# show crypto isakmp sa

Vous devriez voir un IKEv2 SA « established » et des compteurs IPsec non nuls (pkts encaps/decaps). Si rien n'apparaît, vérifiez NAT, ACLs et la correspondance des PSK.

5. Test de connectivité

# Sur le poste Linux client (192.168.10.x)
$ ip route
$ ping -c 4 192.168.30.5

# Vérification côté routeur
R1# show crypto ipsec sa | include pkts

Livrable attendu

• Fichiers de configuration (extraits) des deux routeurs contenant les blocs IKEv2/IPsec, l'interface Tunnel et les routes.
• Sorties des commandes de vérification (show crypto ikev2 sa, show crypto ipsec sa) montrant les SA établies.
• Capture d'un ping réussi entre 192.168.10.10 et 192.168.30.5 avec horodatage.

Critères de réussite

• ☐ Une IKEv2 SA active sur R1 et R2 (show crypto ikev2 sa montre « established »).
• ☐ Des compteurs non nuls dans show crypto ipsec sa (paquets chiffrés/déchiffrés).
• ☐ Ping réussi entre les deux sous-réseaux via le tunnel.

🔁 Synthèse de séance (10 min)

Cette séance a posé les fondations des VPN IPsec : on a vu qu'IPsec construit des SAs qui définissent comment chiffrer et authentifier le trafic, qu'ESP est le protocole pratique pour chiffrer des flux, et qu'IKEv2 simplifie et sécurise la négociation des clés. En pratique, privilégiez AES-256-GCM et ECDH (group 20) lorsque le matériel le permet ; préférez PKI pour des accès multiples et PSK pour de petites liaisons point-à-point bien contrôlées.

🎮 QCM — Testez vos connaissances

Séance suivante : Séance 2 — OpenVPN et déploiement d'accès distant sécurisé (PKI + 2FA).