VPN IPsec site à site entre deux pfSense

Un VPN IPsec site à site relie en permanence les réseaux de deux sites par un tunnel chiffré entre leurs pare-feu : les postes des deux côtés communiquent sans rien installer, comme s'ils étaient reliés par un câble privé. Sur pfSense, le tunnel se décrit en deux phases : la phase 1 authentifie les deux pare-feu et protège leur négociation (IKEv2), la phase 2 dit quels réseaux passent dans le tunnel et comment ils sont chiffrés (ESP). Ce chapitre relie le siège de Sorbier et l'entrepôt de Mâcon, écrit les règles du tunnel et donne la méthode de dépannage.

Le besoin

L'entrepôt de Mâcon (192.168.20.0/24, pfSense d'adresse publique 198.51.100.40) doit joindre l'application de gestion (srv-gestion) au siège (192.168.10.0/24, pfSense 203.0.113.17), et ses deux serveurs se répliquent avec ceux du siège : dc-macon, contrôleur en lecture seule, avec srv-ad et srv-ad2 ; srv-macon, cible DFS du dossier Logistique, avec srv-fichiers. Il n'y a pas de lien loué entre les deux sites : seulement leurs accès Internet. IPsec est le choix naturel : normalisé, intégré à tous les pare-feu (le jour où Mâcon passe sous un autre produit, le tunnel reste possible) et bien accéléré par le matériel.

Les paramètres, identiques des deux côtés

Les deux pare-feu doivent proposer des paramètres compatibles, sinon la négociation échoue. On les fixe dans un tableau avant de configurer, et on le range dans la documentation.

Avec un algorithme GCM, le chiffrement et l'intégrité sont assurés ensemble : aucune fonction de hachage séparée n'est nécessaire en phase 2. La confidentialité persistante (Perfect Forward Secrecy) refait un échange Diffie-Hellman à chaque renouvellement de clé : la découverte d'une clé ne permet pas de déchiffrer les échanges passés (cours Cryptographie).

Configurer la phase 1

Sur pf1 (siège), VPN > IPsec > Tunnels > Add P1 :

Dans les options avancées, garde Dead Peer Detection activé : chaque pare-feu vérifie régulièrement que l'autre répond, et relance la négociation sinon.

Configurer la phase 2

Sous la phase 1, Show Phase 2 Entries > Add P2 :

Save, Apply Changes. Sur le pfSense de Mâcon, la même configuration en miroir : Remote Gateway 203.0.113.17, la même clé partagée, les mêmes propositions, et une phase 2 avec Local Network 192.168.20.0/24 et Remote Network 192.168.10.0/24.

Tunnel par politique et réduction des sélecteurs (narrowing)

Dans la négociation IKEv2, les réseaux de la phase 2 deviennent des sélecteurs de trafic (traffic selectors). Le pare-feu qui lance la négociation (l'initiateur) propose « les paquets de tel réseau vers tel réseau » ; l'autre (le répondeur) compare cette proposition à sa propre configuration. La norme (RFC 7296, § 2.9) prévoit trois issues :

Exemple chiffré. Le siège a Local Network 192.168.10.0/24 et Remote Network 192.168.20.0/24. À Mâcon, quelqu'un a saisi Remote Network 192.168.10.176/28 au lieu de 192.168.10.0/24. Côté siège, l'intersection de 192.168.10.0/24 et de 192.168.10.176/28 est 192.168.10.176/28 (le /28 est contenu dans le /24) ; côté Mâcon, les deux configurations disent 192.168.20.0/24. Quel que soit le pare-feu qui négocie le premier, la phase 2 s'installe pour 192.168.10.176/28 ↔ 192.168.20.0/24. srv-gestion (.179) et les contrôleurs de domaine restent joignables ; le bastion (192.168.10.210) ne l'est plus pour Mâcon, et ses paquets vers 192.168.20.0/24, qu'aucune politique IPsec ne prend, partent vers la route par défaut et se perdent. Si Mâcon avait saisi 192.168.1.0/24, aucune intersection : TS_UNACCEPTABLE.

Les règles du tunnel

Sur le WAN : rien à écrire. pfSense ajoute automatiquement, et sans les afficher, les règles qui autorisent IKE (UDP 500), la traversée du NAT (UDP 4500) et ESP depuis et vers la passerelle distante déclarée en phase 1, et seulement elle. (L'option System > Advanced > Firewall & NAT > Disable all auto-added VPN rules les supprime, si l'on préfère les écrire soi-même.)

Dans l'onglet IPsec (tout ce qui sort des tunnels IPsec vers le pare-feu du siège) :

Pourquoi ces flux :

• dc-macon est un RODC : il demande lui-même la réplication de l'annuaire et de SYSVOL aux contrôleurs inscriptibles (la réplication vers un RODC est à sens unique, et c'est lui qui l'ouvre), et il leur transmet les authentifications des comptes dont il n'a pas le mot de passe en cache. D'où tous les ports d'Active Directory, mais depuis lui seul, et l'heure (UDP 123), qu'il prend dans la hiérarchie du domaine.
• Les postes et terminaux de Mâcon ouvrent leur session auprès de dc-macon, sur place. Ils n'ont besoin des contrôleurs du siège que pour le DNS : la zone de dc-macon est en lecture seule, il renvoie les mises à jour dynamiques (l'enregistrement du nom d'un poste) vers un DNS inscriptible, que le poste contacte directement. Décision de Sorbier : si dc-macon tombe, les salariés de l'entrepôt ouvrent leur session avec les identifiants mis en cache sur leur poste, plutôt que d'ouvrir tous les ports de l'annuaire à tout le réseau de Mâcon.
• srv-macon réplique le dossier Logistique avec srv-fichiers, dans les deux sens : la règle 5 ici, la règle 6 de l'onglet SERVEURS pour l'autre sens (chapitre 5). Le port dynamique de RPC est pris entre 49152 et 65535 ; on peut le fixer sur chaque serveur pour resserrer PORTS_DFSR.

Sur le pfSense de Mâcon, avec les mêmes alias, le trafic du site vers le siège entre par son interface LAN : ses règles LAN reprennent les règles 1 à 6 ci-dessus (même source, même destination, même port), autorisent DC_MACON vers LAN address port 53 (les noms d'Internet), puis la navigation éventuelle, et finissent par un refus journalisé. Son onglet IPsec autorise ce que le siège peut ouvrir vers Mâcon, et rien d'autre : SRV_FICHIERS vers SRV_MACON sur PORTS_DFSR (l'autre sens de la réplication), et BASTION vers 192.168.20.0/24 sur PORTS_ADMIN (l'administration, par le bastion seulement).

Vérifier le tunnel

• Status > IPsec > Overview : la phase 1 doit être ESTABLISHED et la phase 2 INSTALLED, avec des compteurs d'octets qui augmentent. Le bouton Connect P1 and P2s force la négociation.
• Onglets SADs et SPDs : les associations de sécurité (les clés en cours) et les politiques (quels réseaux entrent dans le tunnel).
• Depuis un terminal de Mâcon : ping 192.168.10.179, puis curl -I https://srv-gestion.ad.sorbier.example.
• Status > System Logs > IPsec : le déroulement de la négociation.

Dépanner une négociation

Les messages du journal IPsec (pfSense utilise strongSwan) disent presque toujours où chercher :

Exercices

Exercice 1 sur 4 Le tunnel qui ne monte pas Réussi À revoir

L'administrateur de Mâcon a configuré son côté. Le journal IPsec de pf1 affiche received NO_PROPOSAL_CHOSEN notify error en phase 1. Sa phase 1 utilise AES256-GCM, SHA256 et le groupe DH 14.

1. Qu'est-ce qui ne va pas ?
2. Corrige, et indique le message que tu t'attends à voir disparaître ou apparaître ensuite si la clé partagée a été mal recopiée.

Voir la réponseMasquer la réponse de l'exercice 1

1. Les propositions de phase 1 ne correspondent pas : le siège propose le groupe Diffie-Hellman 19, Mâcon le groupe 14. Aucune proposition commune, d'où NO_PROPOSAL_CHOSEN.
2. Aligner le groupe DH sur la valeur du tableau de référence (19) côté Mâcon. Si la clé partagée a été mal recopiée, la négociation des propositions réussit, mais l'authentification échoue : le message devient AUTHENTICATION_FAILED.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 2 sur 4 Les réseaux de la phase 2 Réussi À revoir

Le siège a configuré sa phase 2 avec Local Network 192.168.10.0/24 et Remote Network 192.168.20.0/24. Mâcon a mis Local Network 192.168.20.0/24 et Remote Network 192.168.10.176/28. Les deux pare-feu sont en IKEv2.

1. Le tunnel monte-t-il ? Si oui, que transporte-t-il exactement ?
2. Quel symptôme voit-on, et où le constates-tu sur pfSense ?
3. Propose deux façons d'aligner les configurations, et dis laquelle tu préfères avec les flux actuels (serveurs du siège et bastion).

Voir la réponseMasquer la réponse de l'exercice 2

1. Oui, sans message d'erreur. En IKEv2, le répondeur réduit (narrowing) les sélecteurs à l'intersection de la proposition et de sa propre configuration (RFC 7296, § 2.9). L'intersection de 192.168.10.0/24 et de 192.168.10.176/28 est 192.168.10.176/28 : la phase 2 s'installe pour 192.168.10.176/28 ↔ 192.168.20.0/24, quel que soit le pare-feu qui négocie. TS_UNACCEPTABLE n'apparaîtrait que si les réseaux n'avaient aucun recouvrement.
2. Les serveurs du siège (srv-gestion, contrôleurs, srv-fichiers, srv-journaux, tous dans 192.168.10.176/28) restent joignables depuis Mâcon ; le bastion (192.168.10.210) ne joint plus Mâcon, sans message clair : ses paquets ne correspondent à aucune politique IPsec et partent vers la route par défaut. Status > IPsec > SPDs (et la phase 2 dans Overview) montre 192.168.10.176/28 au lieu de 192.168.10.0/24.
3. (a) Mettre 192.168.10.0/24 comme réseau distant à Mâcon : le miroir exact du siège. (b) Restreindre volontairement les deux côtés : au siège, Local Network 192.168.10.176/28, plus une seconde phase 2 192.168.10.210/32 ↔ 192.168.20.0/24 pour le bastion, et le miroir à Mâcon. Avec les flux actuels, (b) est préférable : le tunnel ne transporte que ce qui sert, en plus des règles de l'onglet IPsec, c'est une défense en profondeur. Dans les deux cas, on aligne les configurations au lieu de laisser la réduction décider.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 3 sur 4 La phase 2 qui ne s'installe pas Réussi À revoir

Après un changement de configuration à Mâcon, Status > IPsec > Overview montre la phase 1 ESTABLISHED mais aucune phase 2, et le journal IPsec de pf1 affiche TS_UNACCEPTABLE. Le siège a toujours Local Network 192.168.10.0/24, Remote Network 192.168.20.0/24.

1. Que signifie le message ?
2. Mâcon a saisi Local Network 192.168.20.0/24 et Remote Network 192.168.1.0/24. Explique et corrige.

Voir la réponseMasquer la réponse de l'exercice 3

1. Le répondeur n'a trouvé aucune intersection entre les sélecteurs proposés et sa configuration : il refuse la phase 2. La phase 1 (authentification, clés d'IKE) est bonne, sinon on aurait NO_PROPOSAL_CHOSEN ou AUTHENTICATION_FAILED.
2. 192.168.1.0/24 et 192.168.10.0/24 n'ont aucune adresse en commun (faute de frappe probable) : aucune réduction n'est possible. Corriger à Mâcon Remote Network en 192.168.10.0/24, enregistrer, puis vérifier dans Status > IPsec > SPDs des deux côtés que les politiques sont bien 192.168.10.0/24 ↔ 192.168.20.0/24.

Tu avais trouvé ?

Oui, j'avais bonPas encore

Exercice 4 sur 4 Écrire les règles des deux côtés Réussi À revoir

Le service comptable du siège (VLAN POSTES) doit désormais imprimer sur l'imprimante de Mâcon 192.168.20.50 en IPP (TCP 631). Quelles règles ajoutes-tu, sur quel pare-feu et dans quel onglet ? Faut-il modifier la phase 2 ?

Voir la réponseMasquer la réponse de l'exercice 4

• pf1 (siège), onglet POSTES : Pass, TCP, source POSTES subnets (ou un alias des postes comptables), destination 192.168.20.50, port 631, au-dessus de la règle « Refus vers l'interne » (le réseau de Mâcon fait partie de RESEAUX_INTERNES).
• pfSense de Mâcon, onglet IPsec : Pass, TCP, source 192.168.10.64/26, destination 192.168.20.50, port 631, au-dessus du refus final de l'onglet.
• Phase 2 : rien à changer si elle couvre 192.168.10.0/24 ↔ 192.168.20.0/24. Si elle a été restreinte au VLAN SERVEURS côté siège, il faut ajouter une seconde phase 2 pour 192.168.10.64/26 ↔ 192.168.20.0/24 (ou 192.168.20.50/32), des deux côtés.

Tu avais trouvé ?

Oui, j'avais bonPas encore