Configurer un VPN IPsec Site-to-Site avec des certificats sur Sophos Firewall

Une preshared key partagée se configure rapidement pour un tunnel entre deux sites. Avec plusieurs pare-feu ou des exigences PKI plus strictes, un digital certificate est souvent plus facile à maîtriser : chaque côté possède sa propre clé privée, les pairs approuvent les CA émettrices et un certificat individuel peut être renouvelé ou révoqué de manière ciblée.

Cette procédure montre une connexion IPsec policy-based entre deux Sophos Firewall. Elle complète le guide général pour configurer un VPN IPsec Site-to-Site. Les conceptions route-based nécessitent également de planifier le routage et XFRM, mais la procédure de confiance et de certificats décrite ici reste identique.

La procédure sûre en huit étapes

1. Documenter les rôles du tunnel, les réseaux, le profil IKEv2 et les Certificate IDs.
2. Vérifier sur les deux pare-feu qu’un backup de configuration et un accès administrateur fonctionnel sont disponibles.
3. Exporter la CA émettrice de chaque pare-feu et l’importer sur le pair.
4. Générer sur chaque pare-feu un certificat signé localement distinct avec une Certificate ID unique.
5. Exporter uniquement le certificat public et l’importer sur le pair comme Remote Certificate.
6. Créer une connexion IPsec policy-based avec Authentication type > Digital certificate des deux côtés.
7. Contrôler strictement Device Access et les règles de pare-feu générées automatiquement.
8. Valider l’état du tunnel, la confiance du certificat, les logs et le trafic réel dans les deux directions.

⚠️ Le fichier de clé privée reste sur le pare-feu où le certificat a été généré. Seuls les certificats de CA et les certificats publics des pairs sont transférés pour établir la confiance. Sans second accès administrateur testé, backup et voie de récupération documentée, ne pas désactiver les tunnels PSK existants ni remplacer les certificats de production.

Exemple et valeurs de planification

L’exemple relie le siège SF1 à la succursale SF2 :

SF1-LAN 192.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 192.20.20.0/24 SF2-LAN

• WAN de SF1 : 172.10.10.1
• WAN de SF2 : 172.20.20.1
• Certificat de SF1 : SF1_Certificate
• Certificat de SF2 : SF2_Certificate
• Certificate ID de SF1 : 172.10.10.1
• Certificate ID de SF2 : 172.20.20.1

Ces adresses et noms sont des valeurs de documentation. Dans l’environnement réel, utiliser les véritables adresses WAN, objets réseau et un schéma d’ID unique à l’échelle de l’organisation. La Certificate ID doit rester associée au pair correspondant et ne doit pas être confondue avec le nom d’affichage ou un SAN arbitraire.

Établir une confiance mutuelle entre les CA

Sur SF1, commencer par contrôler et télécharger la CA émettrice sous Certificates > Certificate authorities. Si l’exemple utilise la CA locale Default, donner au fichier exporté un nom explicite tel que Head_Office_Default.pem. Sur SF2, l’importer sous Certificates > Certificate authorities > Add, par exemple sous le nom SF1_CA.

Répéter ensuite la procédure dans l’autre sens : exporter la CA de SF2, lui attribuer un nom explicite tel que Branch_Office_Default.pem, puis l’importer sur SF1, par exemple sous le nom SF2_CA.

Les noms de fichier servent uniquement à l’administration. Le Subject, l’Issuer, le Fingerprint, la durée de validité et la chaîne de CA correcte sont déterminants. Comparer ces valeurs par un canal indépendant avant l’import. Gérer les certificats sur Sophos Firewall explique les tâches générales relatives aux CA, aux certificats et à leur attribution aux services.

Ne pas régénérer la CA intégrée Default au passage. Une régénération modifie le Trust Anchor et peut affecter d’autres portails, services TLS et pairs IPsec. Pour une CA d’entreprise, importer plutôt sa chaîne de confiance complète.

Préparer les certificats locaux et distants

Créer le certificat local sur SF1

Sur SF1, créer un certificat sous Certificates > Certificates > Add > Generate locally-signed certificate. L’exemple Sophos utilise RSA, une Key length de 2048 et SHA-256. Ces valeurs ne remplacent pas la politique de chiffrement et de validité de l’organisation ; le profil IPsec choisi et les deux pairs doivent les prendre en charge.

Sous Subject Alternative Names (SANs) > Advanced settings, sélectionner une Certificate ID. Les types pris en charge sont DNS, IP address, Email et DER ASN1 DN [X.509]. L’exemple utilise IP address avec 172.10.10.1.

Avec DER ASN1 DN [X.509], Sophos reprend le Subject de la CA émettrice. Dans ce cas, laisser DNS names et IP address vides sous les SANs, car des valeurs supplémentaires provoquent, selon Sophos, un conflit lors de l’authentification IPsec.

Après Save, contrôler la validité, l’Issuer, la Certificate ID et la présence de la clé privée. Exporter le certificat public, remplacer si nécessaire son extension par .cer, puis l’importer sur SF2 sous Certificates > Certificates > Add > Upload certificate sous le nom SF1_Certificate. La colonne Trusted du pair doit confirmer la confiance via SF1_CA.

Créer le certificat local sur SF2

Répéter la procédure sur SF2 avec une clé privée distincte. Dans l’exemple, le certificat s’appelle SF2_Certificate, sa Certificate ID est 172.20.20.1 et la CA émettrice est la CA locale de SF2.

Importer le certificat public sur SF1. La mention Trusted doit y être confirmée via la CA SF2_CA importée auparavant. Chaque pare-feu possède maintenant exactement deux rôles différents :

• Local certificate : son propre certificat avec la clé privée.
• Remote certificate : le certificat public du pair, validé par sa CA.

Une coche de confiance verte prouve la chaîne de certificats, mais pas le fonctionnement du tunnel. La validité, la Certificate ID, le profil IKE, la gateway et les réseaux doivent toujours correspondre. La révocation et la distribution des CRL constituent un processus d’exploitation distinct ; voir Certificate Revocation Lists sur Sophos Firewall.

Créer la connexion IPsec des deux côtés

Sous Site-to-site VPN > IPsec > Add, créer deux connexions correspondantes. Dans l’exemple, le siège attend la succursale :

• Connection type : Policy-based
• Gateway type : Respond only
• Profile : Head office (IKEv2) ou un clone de profil personnalisé coordonné
• Authentication type : Digital certificate
• Local certificate : SF1_Certificate
• Remote certificate : SF2_Certificate
• Listening interface : WAN de SF1
• Local subnet : SF1_LAN
• Gateway address : adresse WAN de SF2
• Remote subnet : SF2_LAN

Inverser les rôles dans la succursale :

• Gateway type : Initiate the connection
• Profile : Branch office (IKEv2) ou le profil personnalisé correspondant
• Local certificate : SF2_Certificate
• Remote certificate : SF1_Certificate
• Local subnet : SF2_LAN
• Gateway address : adresse WAN de SF1
• Remote subnet : SF1_LAN

Planifier les profils comme une paire. Comprendre les profils IPsec sur Sophos Firewall explique comment IKEv2, la phase 1, la phase 2, PFS, les lifetimes et DPD interagissent.

Contrôler Device Access et les règles de pare-feu

Le côté configuré avec Gateway type > Respond only doit pouvoir accepter les connexions IPsec sur le chemin WAN prévu. Sous Administration > Device access, activer donc IPsec uniquement pour la zone WAN réellement nécessaire ou utiliser une exception Local Service ACL limitée aux adresses de pairs connues. SSO, les certificats ou un algorithme IPsec robuste ne justifient pas un accès WebAdmin ou SSH étendu. Configurer Device Access en toute sécurité sur Sophos Firewall explique la planification des ACL.

Lorsque Create firewall rule est activé, SFOS crée automatiquement des règles VPN. Ces règles constituent un point de départ. Sous Rules and policies > Firewall rules, contrôler leur ordre, leur direction, les réseaux source et destination, les services et le logging, puis les limiter au besoin réel. Créer des règles de pare-feu sur Sophos Firewall explique la validation des règles.

Ping/Ping6 pour la zone VPN n’est nécessaire que si une adresse du pare-feu doit volontairement servir de cible de test. Il n’est pas nécessaire d’ouvrir largement ce service local pour un test end-to-end normal entre des hôtes situés derrière les pare-feu.

Valider le tunnel et les certificats

La validation distingue quatre niveaux :

1. Sous Site-to-site VPN > IPsec, la connexion et le tunnel sont actifs.
2. Les deux pare-feu affichent les Local et Remote Certificate attendus, des durées de validité correctes et un Issuer approuvé.
3. Un véritable hôte de test atteint le service prévu sur le réseau distant, puis la direction inverse est testée.
4. Firewall Rule ID, Packet Capture et les logs IPsec confirment le même chemin et les mêmes horodatages.

strongswan.log est le principal point de départ pour les erreurs IKE et de certificats. charon.log, ipsec_monitor.log et le log propre à la connexion sous /log/ipsec_conn/ fournissent des indications supplémentaires. Dépannage IPsec sur Sophos Firewall décrit la procédure de diagnostic complète.

Circonscrire les erreurs selon le symptôme

Le tunnel reste down

Vérifier d’abord que Local certificate et Remote certificate sont réellement inversés des deux côtés. Contrôler ensuite la Certificate ID, la Gateway address, le profil IKEv2, la validité et la chaîne de confiance. Un certificat de pair importé sans la CA correspondante ne constitue pas une identité approuvée.

Le certificat est Trusted, mais l’authentification échoue encore

Trusted confirme uniquement la chaîne. Avec DER ASN1 DN [X.509], aucune valeur SAN DNS ou IP supplémentaire ne doit remplacer l’identifiant. Avec les autres types d’ID, la valeur, le type et le pair attendu doivent correspondre exactement. Comparer dans strongswan.log les ID réellement présentées et attendues pour la même tentative de connexion.

Le tunnel est vert, mais aucun trafic ne passe

L’authentification par certificat a déjà réussi. Contrôler maintenant les sous-réseaux locaux et distants, les règles VPN automatiques, la Rule ID, le NAT, la route de retour et le véritable service de destination. Régénérer des certificats sans preuve ne ferait que masquer l’état initial dans ce scénario.

Le certificat arrive bientôt à expiration

Préparer le nouveau certificat local en parallèle, transférer sa partie publique au pair et y confirmer la confiance. Modifier Local certificate et Remote certificate des deux côtés de manière contrôlée uniquement pendant une fenêtre de maintenance. Conserver les anciens certificats et les anciennes CA jusqu’à la réussite de la validation bidirectionnelle, puis seulement les supprimer ou les révoquer.

Rollback et exploitation

Avant la modification, documenter les deux connexions IPsec, les noms des certificats, les Fingerprints, les Certificate IDs, les périodes de validité et l’ordre actuel des règles. Un backup de configuration de Sophos Firewall fait partie de la préparation, mais ne remplace pas un accès de récupération direct au pare-feu.

Si la validation échoue, restaurer les attributions de certificats précédentes ou réactiver le tunnel PSK toujours disponible. Supprimer les nouveaux certificats de pairs ou les CA importées uniquement après avoir vérifié qu’aucune autre connexion ni aucun autre service ne les utilise. Contrôler ensuite à nouveau l’état du tunnel et un flux de test réel.

En exploitation, les certificats nécessitent un responsable, une surveillance de l’expiration et une fenêtre de renouvellement planifiée. La première alerte doit laisser suffisamment de temps pour l’émission, la distribution de la confiance, le test parallèle et le rollback. Remplacer un certificat uniquement le jour de son expiration transforme une maintenance planifiée en panne VPN.

Questions fréquentes