Dépannage VPN IPsec sur Sophos Firewall

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.

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.
Le firewall plante à répétition avec du multicast via VPN : Ne pas provoquer le problème par d’autres tests de charge. Consigner la version du firmware, les horodatages et les données de diagnostic disponibles ; NC-180433 est corrigé dans SFOS 22.0 MR2 Build 546.

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.

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.

Debug StrongSwan

Si le log normal ne suffit pas, vérifier d’abord l’état actuel dans l’Advanced Shell :

service -S | grep strongswan

Si RUNNING,DEBUG est déjà affiché, ne pas exécuter à nouveau le toggle comme s’il s’agissait d’une activation. Utiliser le debug existant, puis le désactiver comme décrit ci-dessous.

⚠️ Ne laisser le debug actif que brièvement. Il peut rapidement générer de gros fichiers de logs et occuper de l’espace de stockage.

Si le debug n’est pas encore actif, exécuter le toggle, contrôler le nouvel état et reproduire l’erreur une seule fois :

service strongswan:debug -ds nosync
service -S | grep strongswan
tail -f /log/strongswan.log

Pour strongswan, l’état doit indiquer RUNNING,DEBUG. Ensuite, la même commande désactive à nouveau le mode debug ; la deuxième commande confirme le retour à l’état normal :

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.

La Local ID d’un côté doit correspondre à la Remote ID de l’autre, et inversement. Redéfinir le PSK des deux côtés ; les espaces invisibles ou les copier-coller depuis un gestionnaire de mots de passe sont des causes fréquentes. Un ID incorrect peut empêcher l’association du peer 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 vides, 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.

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

Avec IPsec policy-based, SFOS 22 gère les routes VPN dans le backend. Les routes IPsec manuelles et la Route Precedence sont contrôlées dans la Device Console :

system ipsec_route show
system route_precedence show

La commande de l’Advanced Shell connue des anciennes procédures de dépannage ne constitue pas une preuve fiable pour un tunnel policy-based sous SFOS 22 :

ip route show table 220

Sous SFOS 22, les routes VPN policy-based et les entrées ipsec_route manuelles n’y sont pas visibles. Une entrée manquante ne prouve donc ni l’absence d’une route ni une erreur de routage.

Avec IPsec route-based, une route statique, SD-WAN ou dynamique vers l’interface XFRM ainsi que des états XFRM correspondants doivent être présents. Vérifier l’interface XFRM sous Network > Interfaces et le chemin sous Diagnostics > Tools > Route lookup ; la Device Console affiche les routes statiques configurées :

show static-route

Les états XFRM sont contrôlés dans l’Advanced Shell :

ip xfrm state
ip xfrm policy

Les interfaces XFRM ne doivent pas utiliser de réseaux de transfert qui se chevauchent. Les connexions avec des sous-réseaux locaux et distants identiques doivent appartenir à un groupe de failover IPsec commun ou disposer d’une logique de Selectors et de Routing clairement différente. La procédure associée explique l’ordre du groupe, le Health Check et le test de basculement contrôlé.

Vérifier le NAT selon le type de tunnel

Le NAT est autorisé, mais il doit correspondre au type de tunnel et aux adresses attendues par le site distant.

Policy-based avec SNAT : La règle SNAT prévue nécessite 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 : MASQ traduit la source vers l’adresse IP XFRM ; celle-ci est visible dans l’en-tête IP interne de Packet Capture.
Route-based avec des Traffic Selectors précis : Si une règle MASQ correspond, le firewall rejette le trafic, car aucune adresse IP n’est attribuée à de telles interfaces XFRM.

La source d’origine et la source traduite doivent être documentées, autorisées sur le site distant et disposer d’une route de 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.
Plusieurs connexions avec les mêmes sous-réseaux ne se trouvent pas dans le même groupe de failover.
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 Build 411 ou MR1 Build 490 sur certaines appliances XGS physiques : 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 initial :

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é

Désactiver ensuite le debug StrongSwan. 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.