Décortiquer IPsec avec strongSwan sur Debian

16/07/2022 · 20 mins de lecture · cybersecurite reseaux ipsec vpn tunnel strongswan debian  ·
Partager sur:

Traductions

Sommaire

Dans cet article, je vous propose de décortiquer le concept de réseau privé virtuel ou Virtual Private Network (VPN) avec le protocole Internet Protocol Security (IPsec). L’objectif est de vous aider à mieux comprendre les différentes étapes de mise en place d’un tunnel IPsec qui s’appuie sur différents protocoles ainsi que de vous montrer un exemple concret pas-à-pas sur le système d’exploitation Debian GNU/Linux à l’aide de la solution strongSwan.

Introduction

Les tunnels, dans le contexte des réseaux, permettent de faire communiquer des informations d’un réseau sur un autre réseau par encapsulation des données, un peu comme si vous empruntiez un tunnel pour traverser une montagne difficile à franchir autrement afin de vous rendre d’une vallée à une autre. Généralement, cela permet de faire communiquer entre eux deux réseaux privés (les vallées), c’est-à-dire non routés sur Internet, en utilisant un réseau public comme Internet (la montagne) comme transport sous-jacent. Dans ce cas, cela s’appelle un VPN. Il existe d’autres intérêts à mettre en place des tunnels et différents type de protocoles réseaux permettant la réalisation de ces derniers. Nous allons nous intéresser ici à IPsec, un protocole permettant la mise en place de VPN client-à-site (un hôte vers un réseau distant, par exemple des employés en télétravail connectés à leur réseau d’entreprise) ou site-à-site (un réseau vers un autre réseau distant, par exemple le réseau d’un site d’entreprise satellite connecté au réseau du site principal de l’entreprise).
De mon expérience, j’ai croisé IPsec dans de nombreuses implémentations et il est parfois mal compris dans sa mise en place. Au-delà de se contenter de le “faire marcher”, il est primordial de comprendre les différents mécanismes mis en jeu afin d’effectuer les bons choix de configuration et faciliter la maintenance et le dépannage.

IPsec : la théorie

IPsec est en réalité une suite de protocoles permettant le transfert des données de manières sécurisées et permettant la négociation des paramètres de sécurité nécessaires. IPsec propose en outre différents modes de fonctionnement définissant la manière d’acheminer les données.

AH et ESP

Deux protocoles opérant au-dessus du protocole Internet Protocol (IP) permettent de proposer des fonctionnalités différentes pour le transfert des données transmises dans le cadre d’IPsec :

  • Authentication Header (AH) offre l’intégrité des données (les données n’ont pas été altérées) et l’authentification des données (les données proviennent bien de l’adresse source du paquet) pour le paquet IP entier.
  • Encapsulating Security Payload (ESP) offre l’intégrité des données, la confidentialité des données (les données n’ont pas été divulguées) et l’authentification des données pour les données (ou payload) du paquet IP.

Il est à noter que les deux protocoles ci-dessous ont un mécanisme d’anti-rejeu ou anti-replay afin d’éviter le rejeu ou l’injection malveillante de paquets à l’aide de numéros de séquences. Aussi, AH et ESP peuvent éventuellement être combinés.

Mode transport et mode tunnel

IPsec peut opérer en mode transport ou en mode tunnel selon le besoin.

  • En mode tunnel, le paquet IP originel (en-tête IP et données sus-jacentes à savoir la payload) est encapsulé dans un nouveau paquet IP avec un en-tête ESP et/ou AH. Ce mode est utilisé pour établir des VPN.
  • En mode transport, la payload originelle est conservée dans le paquet IP originel auquel on ajoute un en-tête ESP et/ou AH. Ce mode est utilisé pour sécuriser le transfert d’information sans établir un VPN.

    En-têtes AH et ESP en mode transport

    En-têtes AH et ESP en mode tunnel

ISAKMP et IKE

Un autre protocole est utilisé pour l’établissement du tunnel de manière sécurisée : Internet Security Association and Key Management Protocol (ISAKMP) qui permet l’échange de clés de chiffrement et l’authentification des membres. ISAKMP est en fait plus un cadre qui est implémenté via différents protocoles possibles : Internet Key Exchange (IKE), Kerberized Internet Negociation of Keys (KINK)… L’objectif de ces protocoles est de construire des associations de sécurité ou Security Associations (SA) qui sont des ensembles d’attributs (algorithme de chiffrement, clés de chiffrement, fonction de hachage, fonction pseudo-aléatoire, identifiants, etc.) rendant possible une communication sécurisée via AH ou ESP.

IKE est très largement employé et repose sur le protocole User Datagram Protocol (UDP) avec le port 500. Il permet la réalisation de différentes opérations :

  • Authentification à base de certificats numériques ou de clés prédéfinies et partagées ou pre-shared key (PSK).
  • Echange de clés de chiffrement à base de la méthode d’échange de clés Diffie-Hellman (DH). Cela permet la définition d’un secret partagé via l’envoi d’informations en clair sur le réseau alors non sécurisé, en reposant sur le principe mathématique que pour un attaquant qui intercepterait ces informations, l’exponentiation est extrêmement difficile à inverser via le logarithme discret. La valeur du module arithmétique utilisée est spécifiée via des groupes numérotés (plus la valeur du groupe est grande, plus la taille du module est grande ce qui renforce l’échange de clés). Je vous invite à lire cette page pour plus de détails.

IKE existe en deux versions : IKEv1 et IKEv2. Cette dernière est plus performante et plus sécurisée que sa prédécésseur, c’est pourquoi je ne vais m’intéresser ici qu’à IKEv2. Le protocole IKEv2 est un ensemble d’échange de requêtes et réponses structurés et visant à définir des SA d’abord pour chiffrer l’échange IKE puis pour chiffrer l’échange de données via ESP et/ou AH :

  • IKE_SA_INIT : échange pour négocier les paramètres de sécurité (algorithme de chiffrement pour la confidentialité, fonction de hachage pour l’intégrité, fonction pseudo-aléatoire ou Pseudo-Random Function pour dériver les clés de chiffrement à partir de la négociation initiale, groupe et valeur DH pour l’échange de clés initial, nonce pour éviter le rejeu des valeurs cryptographiques calculées).
  • IKE_AUTH : échange pour transmettre les identités et création de la première SA ESP et/ou AH.
  • INFORMATIONAL : échange pour vérifier la continuitié d’une SA, supprimer des SA, reporter des erreurs, etc.
  • CREATE_CHILD_SA : échange pour créer des SA ESP et/ou AH supplémentaires.

    Echanges IKEv2

IPsec permet d’obtenir de la confidentialité persistente ou Forward Secrecy (FS) ou encore Perfect Forward Secrecy (PFS) en négociant des clés de chiffrements différentes via un nouvel échange DH et ce pour chaque nouvelle SA avec IKE. Ainsi, si les secrets utilisés pour la génération de clés étaient compromis par un attaquant, les communications passées ne sont pas compromises.

NAT-T

En utilisant IPsec, plusieurs problèmes peuvent apparaitre à cause d’une éventuelle utilisation de la traduction d’adresse ou Network Address Translation (NAT). En effet, si une traduction d’adresse source dans l’en-tête IP est effectuée sur le chemin entre les deux passerelles essayant de négocier l’établissement du tunnel, l’adresse d’une passerelle étant modifiée, l’authenticité de cette dernière ne peut pas être vérifiée par son homologue ce qui empêche la mise en place du tunnel avec IKE. De plus, avec le protocole ESP, il n’y a pas d’en-tête TCP ou UDP qui offrent des sommes de contrôles (checksum) et des numéros de ports permettant le multiplexage de paquets via la modification des ports destination avec du Port Address Translation (PAT).
Pour résoudre ces problèmes, IKE est ainsi capable de détecter la présence de NAT appliqué entre les deux passerelles et de déclencher l’encapsulation des paquets IKE puis ESP dans un segment UDP avec le port (source et destination) 4500. Cela s’appelle le NAT-Traversal (NAT-T). On peut alors réussir la négociation du tunnel puis effectuer du PAT sur le chemin si besoin grâce au nouvel en-tête UDP offrant des numéros de port.
Notez que AH n’est pas supporté par le NAT-T, car l’authentification AH repose justement sur le fait de ne pas modifier l’en-tête IP (ce qui n’est pas le cas pour ESP). L’utilisation de NAT-T est très répandue de par l’intense utilisation de NAT sur Internet. L’emploi d’AH se retrouve alors restreinte.

En-tête ESP en mode tunnel avec NAT-T

Dans la suite de cet article, nous allons voir concrètement la mise en place d’un VPN IPsec par un exemple et creuser encore un peu plus certains aspects techniques.

IPsec : la pratique avec strongSwan sur Debian

Lorsqu’on monte un tunnel VPN, il y a donc plusieurs éléments principaux à choisir dans sa conception :

  • Le protocole : AH ou ESP, qui dépend des propriétés de sécurité souhaitées et de l’utilisation de NAT.
  • L’utilisation de NAT-T ou non.
  • Le mode : transport ou tunnel.
  • Les différents algorithmes de chiffrement, fonction de hachage, fonction pseudo-aléatoire et le groupe DH.
  • La méthode utilisée pour l’authentification : certificats numériques ou PSK.

Pour aller plus loin, je vous propose un exemple d’implémentation d’IPsec ESP avec IKEv2 par authentification PSK en mode tunnel sur la plateforme Debian grâce à la solution strongSwan. Cette dernière est une solution open source supportant de nombreux protocoles et modes de fonctionnement pour réaliser des VPN IPsec.
Le schéma ci-dessous illustre la maquette utilisée qui est composée de 2 passerelles (Gateway 1 et Gateway 2) établissant un VPN IPsec pour interconnecter un client et un serveur distant.

Maquette IPsec

Installation de strongSwan

Sur chaque passerelle, installez le paquet ou package strongSwan : 

$ sudo -- sh -c 'apt-get update && apt-get install -y strongswan'

Sur chaque passerelle, vérifiez que le service strongswan est actif : 

$ systemctl status strongswan-starter.service ; systemctl is-enabled strongswan-starter.service
● strongswan-starter.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
     Loaded: loaded (/lib/systemd/system/strongswan-starter.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2022-07-16 09:04:05 UTC; 20min ago
   Main PID: 3207 (starter)
      Tasks: 18 (limit: 529)
     Memory: 2.1M
        CPU: 13ms
     CGroup: /system.slice/strongswan-starter.service
             ├─3207 /usr/lib/ipsec/starter --daemon charon --nofork
             └─3211 /usr/lib/ipsec/charon
enabled

Les passerelles devant être en capacité d’effectuer du routage de paquet, activez le routage de paquet (ou IP Forwarding) sur chaque passerelle : 

$ sudo sysctl -w net.ipv4.ip_forward=1

Configuration d’IPsec

Sur chaque passerelle, sauvegardez le fichier configuration IPsec par défaut : 

$ sudo mv /etc/ipsec.conf /etc/ipsec.conf.bkp

Sur chaque passerelle, créez un nouveau fichier de configuration IPsec : 

$ sudo vim /etc/ipsec.conf

Sur la passerelle Gateway 1, insérez-y la configuration suivante : 

config setup
        charondebug="all"
        uniqueids=yes
conn ipsec-example
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=psk
        left=193.167.10.14
        leftsubnet=10.10.1.0/24
        right=193.167.10.13
        rightsubnet=10.10.2.0/24
        ike=aes256gcm16-sha256-modp1024!
        esp=aes256gcm16-sha256-modp1024!
        keyingtries=%forever
        ikelifetime=60s
        lifetime=30s
        dpddelay=10s
        dpdaction=restart

Sur la passerelle Gateway 2, insérez-y la configuration suivante : 

config setup
        charondebug="all"
        uniqueids=yes
conn ipsec-example
        type=tunnel
        auto=start
        keyexchange=ikev2
        authby=psk
        left=193.167.10.13
        leftsubnet=10.10.2.0/24
        right=193.167.10.14
        rightsubnet=10.10.1.0/24
        ike=aes256gcm16-sha256-modp1024!
        esp=aes256gcm16-sha256-modp1024!
        keyingtries=%forever
        ikelifetime=60s
        lifetime=30s
        dpddelay=10s
        dpdaction=restart

Détaillons chacun de ces paramètres (je vous invite aussi à lire la documentation officielle) :

  • config setup : section définissant les paramètres généraux
    • charondebug="all" : défini le niveau d’information de logging (où généralement le fichier /var/log/syslog est utilisé) par le démon charon en charge d’implémenter IKEv2 pour strongSwan. Ici nous choisissons de logguer tous les messages.
    • uniqueids=yes: défini si un identifiant unique doit être utilisé par chaque SA. Ici nous choisissons que oui.
  • conn ipsec-example : section définissant les paramètres de connexion IPsec. Ici nous nommons la section ipsec-example.
    • type=tunnel: défini le mode IPsec. Ici nous choisissons le mode tunnel.
    • auto=start: défini l’action à effectuer au démarrage du démon. Ici nous choisissons de charger les paramètres et de démarrer la connexion IPsec.
    • keyexchange=ikev2: défini le protocole pour l’établissement du tunnel sécurisé. Ici nous choisissons IKEv2.
    • authby=psk: défini la méthode d’authentification. Ici nous choisissons PSK.
    • left=193.167.10.13 : défini l’adresse IP externe (utilisée pour monter le tunnel) de la première passerelle. Ici il s’agit de l’adresse de l’interface eth2 de la passerelle Gateway 1 ou Gateway 2 (à inverser selon que la configuration est celle de Gateway 1 ou Gateway 2).
    • leftsubnet=10.10.2.0/24 : défini l’adresse du réseau interne associé à la première passerelle. Ici il s’agit du réseau associé à la passerelle Gateway 1 ou Gateway 2 (à inverser selon que la configuration est celle de Gateway 1 ou Gateway 2).
    • right=193.167.10.14 : défini l’adresse IP externe (utilisée pour monter le tunnel) de la deuxième passerelle. Ici il s’agit de l’adresse de l’interface eth2 de la passerelle Gateway 2 ou Gateway 1 (à inverser selon que la configuration est celle de Gateway 2 ou Gateway 1).
    • rightsubnet=10.10.1.0/24 : défini l’adresse du réseau interne associé à la deuxième passerelle. Ici il s’agit du réseau associé à la passerelle Gateway 2 ou Gateway 1 (à inverser selon que la configuration est celle de Gateway 2 ou Gateway 1).
    • ike=aes256gcm16-sha256-modp1024! : défini la suite cryptographique ou cipher suite (algorithme de chiffrement, fonction de hachage et groupe DH qui contient ici la longueur du module arithmétique) pour les SA IKE. Ici nous choisissons l’algorithme Advanced Encryption Standard (AES) avec une longueur de clé de chiffrement de 256 bits et le mode d’opération Galois/Counter Mode (GCM) qui permet d’ajouter une fonction d’authentification supplémentaire ; la fonction de hachage Secure Hash Algorithm 256 (SHA-256) permettant de générer une empreinte de 256 bits pour le contrôle d’intégrité des données et en tant que fonction pseudo-aléatoire ; le groupe 2 DH utilisant un module arithmétique de 1024 bits. Vous pouvez consulter ici l’ensemble des valeurs possibles.
    • esp=aes256gcm16-sha256-modp1024!! : défini la suite cryptographique ou cipher suite (algorithme de chiffrement, fonction de hachage et groupe DH qui contient ici la longueur du module arithmétique) pour les SA ESP. Ici nous choisissons l’algorithme AES avec une longueur de clé de chiffrement de 256 bits et le mode d’opération GCM qui permet d’ajouter une fonction d’authentification supplémentaire ; la fonction de hachage SHA-256 permettant de générer une empreinte de 256 bits pour le contrôle d’intégrité des données et en tant que fonction pseudo-aléatoire ; le groupe 2 DH utilisant un module arithmétique de 1024 bits ce qui permet ici de demander un nouvel échange DH lors de la renégociation des SA. Vous pouvez consulter ici l’ensemble des valeurs possibles.
    • keyingtries=%forever : défini le nombre de tentatives pour négocier une connexion. Ici nous choisissons de tenter en boucle.
    • ikelifetime=60s : défini la durée de validité d’un canal de négociation IKE (donc d’une SA IKE) avant renégociation. Ici nous choisissons volontairement une valeur très basse, à savoir 60 secondes.
    • lifetime=30s : défini la durée de validité d’une SA pour l’envoi des paquets de données. Ici nous choisissons volontairement une valeur très basse à savoir 30 secondes.
    • dpddelay=10s : défini l’intervalle entre deux paquets IKE INFORMATIONAL si aucun trafic n’est reçu. Ici nous choisissons volontairement une valeur basse à savoir 10 secondes.
    • dpdaction=restart: défini l’action à effectuer en cas de timeout à la suite de l’envoi des messages IKE INFORMATIONAL. Ici nous choisissons de relancer la négociation IKE.

Ensuite, générez une PSK sur une des passerelle (ici nous choisissons une valeur aléatoire codée en Base64 sur 32 octets, ce qui donne une entropie suffisamment élevée) : 

$ openssl rand -base64 32
pH56SwETVACv0FaMjPv28fH3Jkq6PVqeeRCvlTZtKCk=

Sur la passerelle Gateway 1, ajoutez la PSK à la configuration IPsec : 

$ echo "193.167.10.14 192.167.10.13 : PSK \"pH56SwETVACv0FaMjPv28fH3Jkq6PVqeeRCvlTZtKCk=\"" | sudo tee -a /etc/ipsec.secrets

Sur la passerelle Gateway 2, ajoutez la PSK à la configuration IPsec : 

$ echo "193.167.10.13 192.167.10.14 : PSK \"pH56SwETVACv0FaMjPv28fH3Jkq6PVqeeRCvlTZtKCk=\"" | sudo tee -a /etc/ipsec.secrets

Etablissement du tunnel

Lancez l’établissement du tunnel en démarrant le démon IKE charon avec la configuration IPsec sur chaque passerelle : 

$ sudo ipsec start

Vérifiez le bon établissement du tunnel avec la commande suivante sur chaque passerelle : 

$ sudo ipsec status
Security Associations (1 up, 0 connecting):
ipsec-example[1]: ESTABLISHED 53 seconds ago, 193.167.10.14[193.167.10.14]...193.167.10.13[193.167.10.13]
ipsec-example{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: ceea3102_i c6ea8633_o
ipsec-example{2}:   10.10.1.0/24 === 10.10.2.0/24
Ici on peut voir que le tunnel est bien établi entre les deux passerelles et on peut voir les valeurs des Security Parameter Index (SPI) utilisées. Ces derniers sont des identifiants codés sur 32 bits et insérés dans l’en-tête ESP. Ils permettent d’associer les paquets à des SA.

Sur les passerelles strongSwan, insèrez automatiquement des routes statiques afin de router le trafic des réseaux internes dans le tunnel. Pour ce faire, il utilise la table de routage 220. Vous pouvez visualisez ces routes une fois le démon lancé : 

$ sudo ip route list table 220
10.10.2.0/24 via 193.167.10.13 dev eth2 proto static src 10.10.1.254
Dans notre cas, ici sur Gateway 1, une route a été insérée pour joindre le réseau interne associé à Gateway 2 en passant par Gateway 2 (ce trafic sera soumis à l’encapsulation ESP bien sûr, comme nous le confirmerons juste après). Si le trafic est émis par Gateway 1 elle-même, il arrivera avec comme adresse IP source l’adresse IP de l’interface du réseau interne associé à Gateway 1.

strongSwan utilise le framework xfrm pour encapsuler les paquets dans le tunnel IPsec. On peut ainsi visualiser la configuration en place avec xfrm sur les passerelles : 

$ sudo ip xfrm policy
src 10.10.1.0/24 dst 10.10.2.0/24 
	dir out priority 375423 ptype main 
	tmpl src 193.167.10.14 dst 193.167.10.13
		proto esp spi 0xc6ea8633 reqid 1 mode tunnel
src 10.10.2.0/24 dst 10.10.1.0/24 
	dir fwd priority 375423 ptype main 
	tmpl src 193.167.10.13 dst 193.167.10.14
		proto esp reqid 1 mode tunnel
src 10.10.2.0/24 dst 10.10.1.0/24 
	dir in priority 375423 ptype main 
	tmpl src 193.167.10.13 dst 193.167.10.14
		proto esp reqid 1 mode tunnel

Une autre commande permet de visualiser les états ou states des SA effectivement en place : 

$ sudo ip xfrm state
src 193.167.10.14 dst 193.167.10.13
	proto esp spi 0xc6ea8633 reqid 1 mode tunnel
	replay-window 0 flag af-unspec
	aead rfc4106(gcm(aes)) 0xc6c5007ab2941ec02d4b5069ef311439aa71c7c4788b87347a0b6deb40ab46e4836a3f9d 128
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 193.167.10.13 dst 193.167.10.14
	proto esp spi 0xceea3102 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	aead rfc4106(gcm(aes)) 0x6c9dfc3a57558810a3e3fcab5946a89df77f68d05acca022e0530efbfb9d23e12c1f475e 128
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

En observant les logs de strongSwan, on peut suivre le bon déroulement de l’établissement du tunnel : 

$ sudo tail -fn 0 /var/log/syslog | grep charon
Jul 16 14:27:54 debian11 charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.9.1, Linux 5.10.0-12-amd64, x86_64)
Jul 16 14:27:54 debian11 charon: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Jul 16 14:27:54 debian11 charon: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Jul 16 14:27:54 debian11 charon: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Jul 16 14:27:54 debian11 charon: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Jul 16 14:27:54 debian11 charon: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Jul 16 14:27:54 debian11 charon: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Jul 16 14:27:54 debian11 charon: 00[CFG]   loaded IKE secret for 193.167.10.14 192.167.10.13
Jul 16 14:27:54 debian11 charon: 00[LIB] loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic counters
Jul 16 14:27:54 debian11 charon: 00[LIB] dropped capabilities, running as uid 0, gid 0
Jul 16 14:27:54 debian11 charon: 00[JOB] spawning 16 worker threads
Jul 16 14:27:54 debian11 charon: 05[CFG] received stroke: add connection 'ipsec-example'
Jul 16 14:27:54 debian11 charon: 05[CFG] added configuration 'ipsec-example'
Jul 16 14:27:54 debian11 charon: 06[CFG] received stroke: initiate 'ipsec-example'
Jul 16 14:27:54 debian11 charon: 06[IKE] initiating IKE_SA ipsec-example[1] to 193.167.10.13
Jul 16 14:27:54 debian11 charon: 06[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jul 16 14:27:54 debian11 charon: 06[NET] sending packet: from 193.167.10.14[500] to 193.167.10.13[500] (328 bytes)
Jul 16 14:27:54 debian11 charon: 09[NET] received packet: from 193.167.10.13[500] to 193.167.10.14[500] (336 bytes)
Jul 16 14:27:54 debian11 charon: 09[ENC] parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Jul 16 14:27:54 debian11 charon: 09[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_1024
Jul 16 14:27:54 debian11 charon: 09[IKE] authentication of '193.167.10.14' (myself) with pre-shared key
Jul 16 14:27:54 debian11 charon: 09[IKE] establishing CHILD_SA ipsec-example{1}
Jul 16 14:27:54 debian11 charon: 09[ENC] generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
Jul 16 14:27:54 debian11 charon: 09[NET] sending packet: from 193.167.10.14[4500] to 193.167.10.13[4500] (269 bytes)
Jul 16 14:27:54 debian11 charon: 10[NET] received packet: from 193.167.10.13[4500] to 193.167.10.14[4500] (237 bytes)
Jul 16 14:27:54 debian11 charon: 10[ENC] parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Jul 16 14:27:54 debian11 charon: 10[IKE] authentication of '193.167.10.13' with pre-shared key successful
Jul 16 14:27:54 debian11 charon: 10[IKE] IKE_SA ipsec-example[1] established between 193.167.10.14[193.167.10.14]...193.167.10.13[193.167.10.13]
Jul 16 14:27:54 debian11 charon: 10[IKE] scheduling reauthentication in -543s
Jul 16 14:27:54 debian11 charon: 10[IKE] maximum IKE_SA lifetime -3s
Jul 16 14:27:54 debian11 charon: 10[CFG] selected proposal: ESP:AES_GCM_16_256/NO_EXT_SEQ
Jul 16 14:27:54 debian11 charon: 10[IKE] CHILD_SA ipsec-example{1} established with SPIs ceea3102_i c6ea8633_o and TS 10.10.1.0/24 === 10.10.2.0/24
Jul 16 14:27:54 debian11 charon: 10[IKE] received AUTH_LIFETIME of -839s, scheduling reauthentication in -1379s
Jul 16 14:27:54 debian11 charon: 10[IKE] peer supports MOBIKE

Transfert de données dans le tunnel

A partir de l’établissement du tunnnel IPsec, nous avons mené les tests suivants depuis le client :

  • Attente sur 5 secondes.
  • Envoi de 3 requêtes Internet Control Message Protocol (ICMP) Echo Request du client vers le serveur à l’aide de la commande ping pour tester le transfert de données via ESP.
  • Attente sur 35 secondes.
  • Envoi de 3 requêtes ICMP Echo Request à l’aide de la commande ping du client vers le serveur pour re-tester le transfert de données via ESP.

Une capture de paquets a été lancée sur l’interface externe eth2 de la passerelle Gateway 1. Je vous propose de la décortiquer.

Capture de paquets de l'établissement du tunnel et transfert de données

J’ai mis en place un filtre sur les protocoles ISAKMP, ICMP et ESP.

Le paquet n°1 est un paquet de type requête IKE_SA_INIT de Gateway 1 vers Gateway 2.

Paquet de requête IKE_SA_INIT

Comme on peut le voir (même si toute la payload n’apparait pas), il contient la SA avec les paramètres cryptographiques. A ce stade, seul le SPI associé à la SA IKE de l’initiateur (Gateway 1) a été généré.

Le paquet n°2 est un paquet de type réponse IKE_SA_INIT de Gateway 2 vers Gateway 1.

Paquet de réponse IKE_SA_INIT

Comme on peut le voir (même si toute la payload n’apparait pas), il contient la SA avec les paramètres cryptographiques. A ce stade, les deux SPI associés aux SA IKE ont été générés.

Les paquets n°3 et n°4 correspondent respectivement aux messages IKE_AUTH de requête et IKE_AUTH de réponse. Une grande partie de la payload de ces paquets est chiffrée car elle permet de négocier les SA ESP. On remarque que strongSwan basculant en NAT-T par défaut pour IKE, le paquet IKE est encapsulé dans un segment UDP transmis avec le port 4500.

Les paquets n°5 et n°6, n°8 et n°9, n°11 et n°12, correspondent aux 3 premières paires de requêtes ICMP Echo Request et réponses ICMP Echo Reply encapsulés dans des paquets ESP et donc chiffrés. On retrouve dans ces paquets deux informations intéressantes : le SPI ESP et le numéro de séquence ESP. Les paquet n°7, n°10 et n°13 correspondent aux réponses ICMP Echo Reply décapsulées et en clair, transmisent par la passerelle Gateway 2 vers le client.

Les paquets n°14 et n°15 correspondent de messages IKE INFORMATIONAL qui a lieu environ 10 secondes après le dernier paquet de données ICMP. Il s’agit de la résultante du paramètre dpddelay=10s que nous avons configuré pour vérifier l’état du tunnel en cas d’inactivité pendant 10 secondes. On constate d’ailleurs que 10 secondes plus tard, en l’absence de données tranmises, un nouvel échange de ce type a lieu via les paquets n°16 et n°17.

A compter de 30 secondes après l’établissement du tunnel (survenu à partir du paquet n°4), on constate qu’à partir du paquet n°18, un nouvel échange IKE INFORMATIONAL bilatéral a lieu pour renégocier les SA ESP. Il en résulte alors un échange IKE CREATE_CHILD_SA via les paquets n°22 et n°23. Ceci est la résultante du paramètre lifetime=30s que nous avons configuré.

Les paquets n°24 et n°25, n°27 et n°28, n°30 et n°31, correspondent aux 3 paires suivantes de requêtes ICMP Echo Request et réponses ICMP Echo Reply encapsulés dans des paquets ESP et donc chiffrés. On retrouve dans ces paquets que le SPI ESP a changé. En effet, ceci est le résultat de la renégociation IKE CREATE_CHILD_SA survenue lors des paquets n°22 et n°23. Les paquet n°26, n°29 et n°32 correspondent aux réponses ICMP Echo Reply décapsulées et en clair, transmisent par la passerelle Gateway 2 vers le client.

Le comportement IKE avec les vérifications et renégociations se poursuit alors de la même manière sur les paquets suivants.

Conclusion

Nous avons revu comment IPsec est conçu autour d’une suite de protocoles essentiels à l’établissement d’un tunnel sécurisé. La mise en pratique avec comme exemple IPsec ESP en mode tunnel avec PSK via strongSwan sur Debian nous a permis de vérifier la théorie et comprendre pas-à-pas les différentes étapes de la vie d’un tunnel IPsec.

Sources

Traductions