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 ainsi que les ID locales et distantes.
2. Vérifier sur les deux pare-feu l’heure, un backup de configuration et un accès administrateur fonctionnel.
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 et des ID de pair explicites 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 10.10.10.0/24 → SF1 → policy-based IPsec → SF2 → 10.20.20.0/24 SF2-LAN

• WAN de SF1 : 198.51.100.10
• WAN de SF2 : 203.0.113.20
• Certificat de SF1 : SF1_Certificate
• Certificat de SF2 : SF2_Certificate
• Certificate ID de SF1 : 198.51.100.10
• Certificate ID de SF2 : 203.0.113.20

Les adresses WAN proviennent des plages de documentation RFC 5737 et les adresses LAN sont privées. 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.

Avant de créer les certificats, vérifier la synchronisation NTP sous Administration > Time. Une heure incorrecte peut faire échouer l’importation et le contrôle de validité. Cette procédure IPsec exige également des certificats RSA : SFOS 22 prend en charge ECDSA pour d’autres usages, mais pas pour les connexions IPsec.

É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 avec le rôle Validation only.

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. Si une CA subordonnée est utilisée, sa CA racine doit également être présente. 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. Ne pas sélectionner une CA publique comme Remote CA certificate : Sophos avertit que tout certificat approprié émis par cette CA pourrait permettre un accès non autorisé.

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. Sélectionner RSA, une Key length conforme à la politique interne et un Secure hash autorisé ; RSA 2048 et SHA-256 sont les valeurs d’exemple de la procédure Sophos. Définir Valid from et Valid until de manière à conserver assez de temps pour un renouvellement contrôlé. SFOS utilise un an par défaut, mais la politique de l’organisation détermine la validité réelle.

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 198.51.100.10. Sophos accepte ici toute adresse IP valide ; choisir un identifiant stable et reproduire exactement son type et sa valeur dans la configuration du pair.

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 203.0.113.20 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. SFOS ajoute automatiquement les certificats locaux signés localement et révoqués à sa CRL par défaut. Le pair n’apprend la révocation qu’après le transfert de la CRL actuelle et son importation sous Certificates > Certificate revocation lists > Add. Pour un certificat émis en externe, importer la CRL de la CA externe. Voir Certificate Revocation Lists sur Sophos Firewall pour la procédure complète.

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
• Remote CA certificate : SF2_CA
• Listening interface : WAN de SF1
• Local subnet : SF1_LAN
• Gateway address : adresse WAN de SF2
• Remote subnet : SF2_LAN
• Local ID type / Local ID : IP address / 198.51.100.10
• Remote ID type / Remote ID : IP address / 203.0.113.20

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
• Remote CA certificate : SF1_CA
• Local subnet : SF2_LAN
• Gateway address : adresse WAN de SF1
• Remote subnet : SF1_LAN
• Local ID type / Local ID : IP address / 203.0.113.20
• Remote ID type / Remote ID : IP address / 198.51.100.10

Planifier les profils et les ID comme des paires : la Local ID d’un côté correspond à la Remote ID de l’autre. Les ID DNS, IP et e-mail n’ont pas besoin d’être résolues comme des adresses de gateway, mais leur type et leur valeur doivent correspondre exactement. Pour DER ASN1 DN [X.509], saisir comme Remote ID le Distinguished Name du certificat du pair. 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 une règle entrante et une règle sortante en tête du groupe Automatic VPN rules. 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.

/log/strongswan.log est le principal point de départ pour les erreurs IKE et de certificats. /log/charon.log journalise le service VPN IPsec, /log/ipsec_monitor.log surveille le service IPsec ; /log/ipsec_conn/ipsec_<connectionname>.log consigne les actions propres à la connexion. /log/dgd.log concerne le failover des liens ou du VPN. 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. Vérifier également que le bon Remote CA certificate est sélectionné. 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, les Local et Remote ID doivent se refléter exactement par type et par valeur. Comparer dans /log/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.

Dans un cluster HA, effectuer les modifications sur le Primary actuel, puis attendre que SFOS synchronise la configuration du pare-feu vers l’Auxiliary. Après la synchronisation, vérifier d’abord la sélection des certificats et le tunnel sur le Primary, puis valider un failover HA planifié avec du trafic réel. Un backup HA ne peut être restauré que sur le Primary actuel et la restauration le redémarre sans failover. Il s’agit d’une récupération avec interruption, et non d’un substitut rapide au rétablissement de l’attribution précédente des certificats.

Questions fréquentes