Sophos Firewall : diagnostiquer méthodiquement un VPN IPsec

Lors du dépannage IPsec, l’ordre des contrôles est essentiel : vérifier d’abord IKE et la Child SA, puis les règles firewall, le NAT, le routage et le chemin retour. Un tunnel vert confirme uniquement la négociation, pas le bon fonctionnement du trafic utilisateur.

Pour un nouveau tunnel, commencer par Configurer un VPN IPsec site à site sur Sophos Firewall. Les étapes suivantes s’appliquent à une connexion déjà configurée.

Ne pas modifier comme premier essai les paramètres avancés globaux tels que le nettoyage des sessions au failover, la fenêtre anti-replay, le seuil de cookies IKEv2 ou l’utilisation d’adresses de peer déjà résolues. Utiliser en sécurité les paramètres VPN globaux explique leur effet, le contrôle initial et le rollback.

Parcours de diagnostic

Le tunnel reste down : Vérifier dans strongswan.log la version IKE, le profil IPsec, la gateway, la Local/Remote ID, le PSK ou le certificat.
La Phase 1 est établie, mais aucune Child SA : Comparer les Traffic Selectors, la proposition de Phase 2, PFS et les sous-réseaux.
Le tunnel est vert : Avec ipsec statusall, vérifier que la SA est ESTABLISHED, que la Child SA est INSTALLED et que les compteurs d’octets augmentent.
Une seule direction compte des octets : Vérifier les règles firewall, le NAT, le routage et surtout le chemin retour sur le site distant.
La cause reste inconnue : Suivre un seul flux de test avec Log Viewer et Packet Capture.

Quelques valeurs documentées suffisent au départ : nom du tunnel, adresse IP ou FQDN du peer, version IKE, Local/Remote ID, réseaux locaux et distants, mode policy-based ou route-based, profil IPsec ainsi qu’un test avec source, destination et service. Exemple : tunnel azure-vpn, local 172.16.10.0/24, distant 10.20.30.0/24.

Avec IPsec policy-based, les réseaux font partie de la négociation. IPsec route-based utilise une interface XFRM et des routes statiques, SD-WAN ou dynamiques. Si le chemin est incorrect, consulter les guides distincts sur les routes IPsec et la Route Precedence.

⚠️ Les logs et Packet Captures peuvent contenir des adresses IP publiques, des réseaux internes, des noms d’hôte ou des données utilisateur. Les collecter de manière ciblée et pendant une durée limitée, puis les contrôler avant tout partage.

Avant le diagnostic en CLI, Current activities > IPsec connections affiche uniquement les connexions IPsec actuellement établies. La liste peut être filtrée par Connection name, Local server name, Local subnet, Username, Remote server/host ou Remote subnet, puis rechargée avec Refresh. Disconnect coupe activement la connexion sélectionnée et n’est pas une simple actualisation sans effet : documenter d’abord l’heure et l’état, puis ne déconnecter que dans une fenêtre de test planifiée. Cet instantané ne remplace pas la vérification des Child SA, des logs et du trafic.

Vérifier les logs et la CLI

Sous Site-to-site VPN > IPsec, Show additional properties affiche notamment Local subnet, Remote subnet, Gateway type et Profile. Sous Profiles > IPsec profiles, les valeurs de Phase 1 et de Phase 2 peuvent également être comparées directement.

Les fichiers les plus importants dans /log sont :

strongswan.log : IKE, authentification et Child SAs
charon.log : démon IKE
ipsec_monitor.log : surveillance du service IPsec
/log/ipsec_conn/ipsec_<connectionname>.log : actions Connect, Activate et Deactivate dans WebAdmin
xfrmi.log : interfaces XFRM
dgd.log : Dead Gateway Detection et failover VPN

La liste centrale actuelle des logs SFOS 22 mentionne ipsec_monitor.log. Une ancienne page de dépannage Sophos indique encore strongswan-monitor.log ; pour les systèmes SFOS 22 actuels, la liste la plus récente fait foi.

Dans l’Advanced Shell, le log principal peut être suivi en direct ou filtré. Si l’accès SSH et le shell ne sont pas encore familiers, consulter Dépannage CLI Sophos Firewall : commandes importantes.

cd /log
tail -f /log/strongswan.log
tail -f /log/strongswan.log | grep -i azure-vpn
less /log/strongswan.log
grep -i "no proposal" /log/strongswan.log

Ces lignes sont des alternatives et non une procédure continue. Dans less, utiliser /terme-recherche pour effectuer une recherche dans le fichier.

Débogage de StrongSwan

Si le journal normal ne suffit pas, relever d’abord l’état actuel dans l’Advanced Shell :

service -S | grep strongswan

Si la sortie indique déjà un état de débogage actif, ne pas relancer la commande de bascule. Identifier d’abord qui l’a activé et dans quel but ; la séquence ci-dessous ne s’applique que si le débogage était initialement inactif. Le libellé exact peut varier selon le build.

⚠️ Ne laisser le débogage actif que brièvement. Il peut rapidement produire de gros fichiers journaux et occuper l’espace de stockage.

Si le débogage n’est pas actif, exécuter la commande une fois puis contrôler le nouvel état :

service strongswan:debug -ds nosync
service -S | grep strongswan

Suivre ensuite strongswan.log dans un second terminal, reproduire le problème une seule fois et arrêter tail avec Ctrl+C :

tail -f /log/strongswan.log

Pour terminer, exécuter une fois la même commande de bascule. La seconde ligne doit confirmer le retour à l’état normal sans débogage relevé auparavant :

service strongswan:debug -ds nosync
service -S | grep strongswan

Vérifier l’établissement du tunnel

Phase 1 : IKE, IDs et authentification

Si le tunnel ne s’établit pas, la version IKE, la gateway, les IDs, la proposition, le PSK ou le certificat ne correspondent généralement pas.

no IKE config found ou Remote peer is refusing our Phase 1 proposals : Le firewall ne trouve aucune connexion correspondante ou le profil ne correspond pas. Vérifier la version IKE, la Listening Interface, l’adresse du peer, la Local/Remote ID et le profil.
peer authentication failed, AUTH_FAILED, AUTHENTICATION_FAILED, no matching peer config found ou Remote peer reports we failed to authenticate : Les IDs et l’authentification ne correspondent pas à la configuration attendue du peer.
invalid HASH_V1 payload length ou decryption failed : Avec IKEv1, il s’agit souvent d’un PSK incorrect ; avec IKEv2, AUTH_FAILED apparaît plus fréquemment.
Le site distant atteint une autre adresse publique, ou UDP 500/4500 n’est pas transmis correctement par le NAT, un routeur ou le fournisseur.
Avec des certificats, la chaîne de certificats, la CA émettrice, la validité ou l’ID attendu ne correspond pas.

Si un certificat a été révoqué avant son expiration ou si l’effet de la révocation reste incertain, vérifier ensemble l’issuer, le numéro de série, thisUpdate, nextUpdate et le rejet propre au service. La procédure sûre est décrite dans Importer et tester les Certificate Revocation Lists sur Sophos Firewall.

Le Local ID d’un côté doit correspondre au Remote ID de l’autre, et inversement. Comparer d’abord les ID et le PSK enregistré des deux côtés. Si le PSK doit être remplacé, coordonner l’opération sur les deux pairs pendant une fenêtre de maintenance ; les espaces invisibles et les copier-coller depuis un gestionnaire de mots de passe sont des causes fréquentes. Un ID incorrect peut empêcher l’association du pair avant même la vérification du PSK attendu.

Phase 2 : Traffic Selectors et Child SA

Si la Phase 1 est établie, mais qu’aucune Child SA n’existe, les sous-réseaux ou les valeurs de Phase 2 diffèrent généralement.

traffic selectors ... inacceptable
failed to establish CHILD_SA
received traffic selectors didn't match
Remote peer reports INVALID_ID_INFORMATION
valeurs différentes pour TSi et TSr
NO_PROPOSAL_CHOSEN après Phase 1 is up et Initiating establishment of Phase 2 SA

NO_PROPOSAL_CHOSEN ne suffit pas à lui seul pour classer le problème : avant la Phase 1, il indique des valeurs IKE/de Phase 1 ; après une Phase 1 réussie, il indique ESP, PFS ou d’autres valeurs de Phase 2.

Pour comparer l’ensemble des champs General settings, Phase 1, Phase 2 et DPD, consulter Comprendre et configurer en toute sécurité les profils IPsec Sophos Firewall.

Les réseaux doivent être symétriques. Si Sophos attend localement 172.16.10.0/24 et à distance 10.20.30.0/24, le site distant doit proposer 10.20.30.0/24 vers 172.16.10.0/24. Un /24 d’un côté et un seul hôte de l’autre, ou des objets hôtes gérés différemment, peuvent également empêcher la Child SA.

Le tunnel est établi, mais aucun trafic ne passe

Dans l’Advanced Shell, cette commande affiche les SA, les réseaux négociés et les compteurs d’octets :

ipsec statusall

Les valeurs importantes sont ESTABLISHED, INSTALLED et les compteurs dans les deux directions. Si les deux restent à zéro ou n’augmentent pas, le trafic de test n’atteint probablement pas le tunnel. Si seul le côté sortant augmente, le chemin retour ou une règle sur le site distant manque généralement ; si seuls les octets entrants augmentent, suspecter la route locale, la règle locale ou le système cible.

Suivre un flux de test

Un test ciblé est plus instructif que plusieurs pings simultanés :

Source IP : 172.16.10.25
Destination IP : 10.20.30.15
Service : ICMP ou TCP 443
direction attendue : LAN vers VPN
règle attendue : LAN_to_VPN_Branch

Vérifier ensuite dans cet ordre :

Activer Log firewall traffic dans la règle concernée.
Filtrer Log Viewer par source, destination et Rule ID.
Démarrer Packet Capture avec host 172.16.10.25 and host 10.20.30.15.
Exécuter le test une seule fois.
Comparer la règle, le champ NAT Rule ID, le transfert, la réponse et les compteurs d’octets.
Vérifier la route de retour, la règle distante et le système cible sur le site distant.

Packet Capture utilise un tampon limité et s’arrête lorsqu’il est plein. La vue affiche notamment Rule ID, NAT ID, Status et Reason. Lors d’une capture standard, le trafic FastPath accéléré est normalement envoyé temporairement par le SlowPath. Vérifier l’état du tampon, le filtre et l’heure du test avant de considérer une capture vide ou interrompue comme la preuve d’une absence de trafic.

Si aucun paquet n’arrive sur Sophos Firewall, la cause se situe en amont, par exemple au niveau de la gateway client, du VLAN ou du routage local. Si un paquet arrive, mais n’est pas transféré, la règle, le NAT, la route ou une fonction de sécurité ne correspond pas. Le test complet d’une règle est décrit sous Tester une règle firewall avec Log Viewer, Policy Test et Packet Capture.

Routage et XFRM

Pour un tunnel IPsec policy-based, SFOS crée les routes VPN dans le backend. Elles n’apparaissent pas dans la vue de routage normale. Les routes IPsec manuelles et la priorité des routes se consultent dans la Device Console :

system ipsec_route show
system route_precedence show

L’ordre par défaut est static, sdwan_policyroute, vpn. L’absence d’une entrée dans la vue normale ne prouve donc pas une erreur de routage. Pour le flux de test, corréler Diagnostics > Tools > Route lookup, le journal du pare-feu et Packet Capture.

Pour un tunnel IPsec route-based, le chemin dépend du type d’interface XFRM :

Any/Any ou Dual : l’interface XFRM possède des adresses IP. Une route statique, SD-WAN ou dynamique doit y diriger le trafic distant.
Traffic Selectors précis : SFOS crée automatiquement la route statique. Il n’est pas possible d’attribuer une adresse IP ou une route supplémentaire à l’interface XFRM.

Vérifier l’interface sous Network > Interfaces et le chemin sous Diagnostics > Tools > Route lookup. La Device Console affiche les routes statiques configurées :

show static-route

Contrôler les états XFRM dans l’Advanced Shell :

ip xfrm state
ip xfrm policy

Si plusieurs connexions utilisent les mêmes réseaux locaux et distants comme chemins de secours, leur sélection et leur basculement doivent être explicites. Regrouper les connexions policy-based et les connexions route-based avec des Traffic Selectors précis dans un même groupe de basculement IPsec. Les tunnels XFRM Any/Any peuvent à la place basculer au moyen de routes SD-WAN ; la procédure liée détaille l’ordre, le Health Check et le test contrôlé.

Vérifier le NAT selon le type de tunnel

Le NAT est autorisé, mais ne remplace pas une route. Vérifier d’abord que le chemin de la destination originale ou traduite choisit le bon tunnel, puis que le pair attend bien les adresses réellement utilisées.

Si les réseaux local et distant sont identiques, une simple remarque sur le SNAT ne suffit pas. Utiliser le NAT pour des réseaux IPsec qui se chevauchent décrit la procédure complète d’adressage, de tunnel, de règles et de routage symétriques.

Policy-based avec SNAT : la règle SNAT prévue exige Outbound interface Any. La règle SNAT par défaut avec des ports WAN précis ne correspond pas au trafic IPsec policy-based.
Route-based avec Any/Any ou Dual : l’interface XFRM possède une adresse IP et exige une route explicite. Déterminer la traduction à partir de la règle NAT correspondante et de Packet Capture, sans la déduire du seul type de tunnel.
Route-based avec des Traffic Selectors précis : SFOS crée automatiquement la route et n’attribue pas d’adresse IP à l’interface XFRM. Supposer un MASQ vers une prétendue adresse XFRM n’est donc pas un diagnostic fiable ; vérifier plutôt la source originale, la source traduite et la NAT Rule ID correspondante.

Documenter la source originale et la source traduite, les autoriser si nécessaire sur le pair et assurer leur chemin retour. NAT sur Sophos Firewall explique les principes et l’ordre des règles.

Instabilité et cas particuliers de SFOS 22

Si le trafic s’arrête ultérieurement, comparer les horodatages dans l’état du tunnel, strongswan.log, dgd.log, les événements WAN et le test applicatif. Les causes fréquentes sont :

L’équipement tiers utilise un rekeying basé sur le trafic ; Sophos Firewall prend en charge le rekeying basé sur le temps.
Les deux côtés effectuent le rekeying simultanément. Décaler volontairement les Key Lifetimes de Phase 1 et de Phase 2 de l’Initiator et du Responder.
L’interface attribuée a été désactivée. Les tunnels Initiator se déconnectent immédiatement, les tunnels Responder au plus tard après une période d’inactivité ou le DPD timeout.
Les transferts volumineux échouent malgré un petit test réussi ; vérifier alors MTU et MSS.

Plantages répétés du firewall avec du multicast via VPN

Si les plantages coïncident avec du trafic multicast passant par un tunnel VPN, consigner d’abord la version et le build du firmware, le tunnel concerné, les horodatages ainsi que les données de diagnostic ou de crash disponibles. Sophos confirme ce problème sous l’identifiant NC-180433 et l’a corrigé dans SFOS 22.0 MR2 Build 546.

La description publique du problème ne précise ni type de tunnel particulier ni architecture multicast particulière et ne fournit aucun workaround en CLI. Sur un ancien build SFOS 22, vérifier le chemin de mise à niveau, installer MR2 Build 546 ou une version approuvée plus récente, puis retester le même trafic de manière contrôlée. Ne pas modifier les paramètres du tunnel, IPsec Acceleration ou les services sur la base de simples suppositions. Si le firewall continue de planter avec MR2 ou une version ultérieure, transmettre les données collectées à Sophos Support au lieu de continuer à attribuer automatiquement le problème à NC-180433.

La configuration normale et la validation contrôlée sont expliquées dans Routage multicast sur Sophos Firewall ; le plantage décrit ici reste un cas particulier lié au firmware.

Les paquets IKEv2 sont fragmentés

Avec le Known Issue NC-136352, le profil IKEv2 par défaut peut proposer un si grand nombre de groupes DH que les paquets IKE dépassent 1'500 octets. Si un composant intermédiaire rejette les fragments ou les informations PMTU, l’Initiator envoie les paquets à plusieurs reprises tandis que le Responder ne voit rien.

Pour ce symptôme précis, vérifier le peer dans l’Advanced Shell :

tcpdump -ni any 'host 203.0.113.10 and (udp port 500 or udp port 4500)'

Ensuite, ne proposer dans le profil IPsec que le groupe DH réellement nécessaire ou nettement moins de groupes. Sophos Firewall tcpdump décrit les filtres tcpdump généraux et l’export PCAP.

Alias PPPoE et IPsec Acceleration

NC-181526 concerne SFOS 22.0 GA Respin Build 411 ou MR1 sur certaines XGS Appliances : le tunnel utilise une interface alias d’un port PPPoE-WAN, est connecté, mais ne transporte aucune donnée utilisateur lorsque IPsec Acceleration est active. Les XGS 88/88w, 108/108w, 118/118w et 128/128w sont exclus.

La Sophos Known Issues List actuelle indique SFOS 22.0.2 MR2 Build 546 comme version corrigée ; NC-181526 n’apparaît toutefois pas séparément dans la liste publiée des correctifs MR2. Après la mise à jour, répéter donc le même flux de test au lieu de déduire le correctif de la seule version.

⚠️ La désactivation d’IPsec Acceleration est globale, redémarre tous les tunnels IPsec et provoque une interruption. Ne la tester dans une fenêtre de maintenance que si la combinaison du build, du matériel, de l’alias PPPoE et des symptômes correspond exactement.

Les commandes suivantes s’exécutent dans la Device Console :

system ipsec-acceleration show
system ipsec-acceleration disable
system ipsec-acceleration show

En l’absence d’amélioration, rétablir l’état relevé avant le test. Si l’accélération était active, utiliser :

system ipsec-acceleration enable

Avec NC-180520, SFOS 22.0 MR2 corrige un cas d’alias IP similaire, mais différent : la gateway XFRM pouvait rester inaccessible lorsque l’Acceleration était active si ESP arrivait par un autre port WAN. Les deux Issue IDs ne doivent pas être considérés comme identiques. Le contrôle de mise à niveau SFOS 22 regroupe d’autres vérifications avant et après la mise à jour.

Validation et escalade

Après chaque modification, répéter le même flux de test unique et documenter au moins les points suivants :

Heure, nom du tunnel, adresse IP du peer, source, destination et service
État WebAdmin et ipsec statusall avant et après le test
Règles firewall et NAT attribuées
Packet Capture et compteurs dans les deux directions
Route de retour et règle distante sur le site distant
Modification, résultat et rollback préparé

Ne désactiver ensuite que le debug StrongSwan activé pendant cette procédure. Ne pas modifier un état préexistant sans en connaître le responsable et le but. Enregistrer de manière ciblée les logs pertinents pour Sophos Support ; Enregistrer les logs Sophos Firewall décrit l’export. Vérifier que les paquets de logs volumineux et les captures ne contiennent pas de données sensibles avant leur partage.