VPN site à site et client
Définition
Un VPN étend un réseau privé par-dessus une infrastructure non fiable: le trafic est encapsulé puis chiffré de bout en bout. Un VPN site à site relie deux passerelles (deux sièges, un annexe) et prend en charge tout le trafic des réseaux derrière elles; un VPN client (remote access) relie un poste nomade au réseau de l'entreprise et ne protège que le flux de cet hôte. Cisco attend les deux formes IPsec, et le réflexe GRE plus IPsec quand on doit transporter du multicast ou du routage dynamique.
Contexte
Le blueprint 200-301 thème 5.5 demande de décrire les VPN IPsec remote access et site à site. Pas de configuration ASA complète exigée: l'examen interroge les pots communs, les composants IPsec, les ports, ce que NAT-T résout et le rôle de AnyConnect. Les sorties show crypto ipsec sa et show crypto isakmp sa apparaissent dans les questions de vérification.
IKE et IPsec: deux phases, deux associations
IKE (RFC 2409, IKEv2 RFC 7296) négocie les sécurité associations (SA) sur UDP 500. IKEv2 condense l'accord en deux échanges (IKE_SA_INIT, IKE_AUTH) et gère la rekey et le MOBIKE pour la mobilité des clients; IKEv1, encore présent, empile six messages et des modes agressifs dépréciés. IPsec applique ensuite le chiffrement:
| Protocole | Numéro IP | Apporte | Chiffre | Authentifie |
|---|---|---|---|---|
| AH | 51 | Intégrité et origine | Non | Oui (tout l'en-tête) |
| ESP | 50 | Confidentialité, intégrité | Oui | Oui (charges) |
| ESP + NAT-T | UDP 4500 | Idem, encapsulé pour traverser un NAT | Oui | Oui |
AH casse avec les NAT car il signe l'IP source; ESP est le choix par défaut. Les transforms typiques: AES-256 ou AES-128-GCM pour le chiffrement, HMAC-SHA ou SHA-256 pour l'intégrité, groupe DH 14 ou 21 pour la clé. En mode tunnel, IPsec encapsule le paquet complet: l'IP d'origine devient invisible, les routeurs intermédiaires ne voient que les deux passerelles. En mode transport, seuls les en-têtes de transport sont protégés, usage rare entre hôtes.
Site à site et le cas GRE
Une passerelle IPsec en mode tunnel ne transporte que de l'unicast IP; OSPF, EIGRP ou une diffusion multicast n'y passent pas, car le multicast est traité comme du broadcast dans un tunnel sans résolution de next-hop. D'où le modèle GRE (protocole 47) posé sous IPsec: GRE encapsule tout, IPsec chiffre le paquet GRE. Le trafic entre 10.10.10.0/24 et 10.10.20.0/24 traverse un tunnel GRE, la route OSPF passe par ce tunnel, et le crypto map chiffre le tout vers le pair.
interface Tunnel0
ip address 172.16.99.1 255.255.255.252
tunnel source GigabitEthernet0/0
tunnel destination 198.51.100.2
!
crypto isakmp policy 10
encryption aes 256
authentication pre-share
group 14
crypto isakmp key CLE-FORT address 198.51.100.2
!
crypto ipsec transform-set TS esp-aes 256 esp-sha-hmac
mode tunnel
!
crypto map CM1 local-address GigabitEthernet0/0
crypto map CM1 10 ipsec-isakmp
set peer 198.51.100.2
set transform-set TS
match address ACL-CRYPTO
!
interface GigabitEthernet0/0
crypto map CM1
ACL-CRYPTO (crypto ACL) décide ce qui doit être chiffré: un permit ip 10.10.10.0 0.0.0.255 10.10.20.0 0.0.0.255. Hors de cette liste, le trafic sort en clair. Le compteur show crypto ipsec sa (encrypted, decrypted) valide le chemin.
NAT-T: UDP 4500
Un routeur SOHO qui réécrit l'IP source casse l'intégrité d'ESP. NAT-T (RFC 3947 et 3948) détecte le NAT pendant IKE sur UDP 500, puis bascule tout le trafic ESP encapsulé dans UDP 4500. Un firewall intermédiaire doit donc laisser UDP 500 et 4500, et le protocole IP 50 si le NAT est absent. Sur les plateformes récentes, crypto isakmp nat-traversal 20 envoie un keepalive toutes les 20 s pour garder la translation ouverte.
VPN client avec AnyConnect
Le client remote access moderne n'est plus le legacy IPsec client: Cisco AnyConnect (et sa relève Secure Client) s'appuie sur TLS/DTLS ou sur IPsec IKEv2, et l'authentification peut reposer sur un certificat posé sur le poste. Le contrôleur (ASA ou headend) authentifie via AAA local ou SAML avec MFA, attribue un pool d'adresses (par exemple 10.10.30.0/24), une ACL de sécurité et pousse le DNS interne. Le split tunnel autorise le trafic Internet local du laptop, le full tunnel sort tout par le headend, ce qui est souvent exigé par la compliance mais coûte en bande passante. Les thèmes 5.9 et 5.10 croisent ce sujet avec WPA2/WPA3 côté Wi-Fi, autre accès distant mais logique d'identité différente.
Exemple concret
Deux sites: Paris 10.10.10.0/24 et Lyon 10.10.20.0/24, reliés par Internet via deux routeurs ISR avec 198.51.100.1 et .2, et un ISP qui applique un NAT (RFC 3022) côté Lyon. Sans NAT-T: le tunnel monte, les routes OSPF ne passent jamais par le GRE et les pings inter-VLANs échouent, car le NAT réécrit l'en-tête IP et casse la vérification d'intégrité d'ESP. Après crypto isakmp nat-traversal 20 et autorisation UDP 500/4500 sur le modem: rekey observé à 86400 s, SA active, 412 Mo chiffrés par heure sur la liaison 100 Mbps, 6 pour cent de charge. Les itinérants basculent sur AnyConnect avec MFA: 60 connexions simultanées, pool 10.10.30.0/24, full tunnel vers Paris, le DNS interne résout l'intranet pendant le VPN.