Dépannage VPN IPsec sur Sophos Firewall

Les VPN IPsec site-à-site fonctionnent souvent discrètement tant qu’ils sont opérationnels. Cependant, si un tunnel ne s’établit pas, reste instable après une reconnexion ou est affiché comme connecté mais ne transporte aucun trafic, une analyse méthodique est nécessaire. Sinon, on risque de passer d’une clé PSK à des routes, des règles de pare-feu et des journaux sans identifier la cause réelle.

Cet article explique comment vérifier systématiquement les connexions IPsec sur Sophos Firewall : d’abord l’établissement du tunnel, ensuite les réseaux négociés, et enfin le flux de paquets réel. Si un nouveau tunnel de site est en cours de planification ou de configuration, commencez par Configurer un VPN IPsec site-à-site sur Sophos Firewall. Pour les bases générales de la CLI, consultez également Dépannage CLI Sophos Firewall : commandes essentielles.

Avant le dépannage

Il est conseillé de documenter brièvement la situation initiale. Cela peut sembler trivial, mais cela permet de gagner beaucoup de temps, car de nombreux problèmes IPsec proviennent d’hypothèses asymétriques : une partie pense qu’elle connecte le réseau A au réseau B, tandis que l’autre partie attend d’autres ID, sous-réseaux ou une autre version IKE.

Points importants :

• Nom du tunnel: azure-vpn
• Passerelle locale: Adresse WAN ou FQDN de Sophos Firewall
• Passerelle distante: IP publique ou FQDN de l’autre partie
• Version IKE: IKEv1 ou IKEv2
• Authentification: Clé pré-partagée ou certificat
• ID local / ID distant: Adresse IP, FQDN ou identifiant de type e-mail
• Réseaux locaux: 172.16.10.0/24
• Réseaux distants: 10.20.30.0/24
• Type de VPN: basé sur la politique ou basé sur la route
• Gateway type: Initiate the connection, Respond only ou groupe de failover
• Profil IPsec: Phase 1, Phase 2, groupes DH, PFS et lifetimes
• Trafic attendu: Source, Destination, Port et Direction

Pour les IPsec basés sur la politique, les réseaux locaux et distants font partie de la négociation du tunnel. Pour les IPsec basés sur la route, il est également important de savoir quelles routes pointent vers l’interface du tunnel. Si le trafic circule dans la mauvaise direction malgré un tunnel actif, les Routes IPsec, les routes statiques, les routes de politique SD-WAN ou la Priorité des routes sur Sophos Firewall sont souvent impliquées.

Si le tunnel est établi et que de petits tests fonctionnent, mais que de plus grands transferts échouent, il faut également vérifier le MTU et le MSS. Le processus est décrit dans Vérifier le MTU et le MSS sur Sophos Firewall en cas de problèmes VPN.

⚠️ Les journaux de débogage et les captures de paquets peuvent contenir des données sensibles, telles que des adresses IP publiques, des réseaux internes, des noms d’hôtes ou des données utilisateur. Ces données doivent être collectées de manière ciblée et limitée dans le temps, et vérifiées avant toute transmission.

Chemin de diagnostic

Pour la pratique, une séquence simple est utile :

1. Le tunnel s’établit-il ? Sinon, vérifiez d’abord la version IKE, le profil IPsec, les ID, la clé PSK/certificat, NAT-T et l’accessibilité de l’autre partie.
2. La Phase 2 est-elle établie ? Sinon, vérifiez les sélecteurs de trafic, les réseaux locaux et distants, PFS et les propositions de Phase 2.
3. Une association de sécurité est-elle installée ? Si oui, vérifiez ipsec statusall et surveillez les compteurs d’octets.
4. Le trafic passe-t-il par le tunnel ? Sinon, vérifiez les règles de pare-feu, NAT, routage, priorité des routes, routes IPsec et retour.
5. Les paquets sont-ils visibles ? Si incertain, combinez le Log Viewer et la capture de paquets.

Une erreur courante : un statut de tunnel vert prouve seulement que l’IPsec a été négocié. Il ne prouve pas que les règles de pare-feu sont correctes, que les routes sont exactes ou que l’autre partie connaît le chemin de retour.

Avant de passer à l’Advanced Shell, il vaut la peine de regarder les listes WebAdmin :

• Sous Site-to-site VPN > IPsec, Show additional properties permet d’afficher des colonnes supplémentaires comme Local subnet, Remote subnet, Gateway type ou Profile.
• Sous Profiles > IPsec profiles, des propriétés supplémentaires peuvent également être affichées pour comparer plus vite les valeurs de Phase 1 et de Phase 2.

Ce n’est pas aussi profond qu’un log, mais cela évite des erreurs banales : mauvais profil, mauvais Gateway type, sous-réseaux identiques dans plusieurs tunnels ou tunnel qui ne fait pas partie du groupe de failover attendu.

Quelle couche est affectée ?

Avant de consulter les journaux de débogage, il est utile de classer grossièrement le problème. Cela permet de déterminer plus rapidement si l’on doit chercher au niveau IKE, Phase 2, routage ou flux de paquets.

• Le tunnel reste inactif: IKE, passerelle, ID, PSK, certificat ou proposition Vérifiez strongswan.log en direct et comparez la Phase 1
• Le tunnel oscille entre actif et inactif: Renouvellement, DPD, stabilité WAN ou proposition Comparez les horodatages, DPD, durée de vie et événements WAN
• Phase 1 établie, mais pas de Child SA: Sélecteurs de trafic, proposition de Phase 2 ou PFS Vérifiez les réseaux locaux et distants en miroir
• Tunnel vert, mais compteurs d’octets vides: Le trafic n’atteint pas le tunnel Vérifiez la règle de pare-feu, NAT, route et passerelle client
• Seuls les octets sortants augmentent: Chemin de retour ou autre partie manquante Vérifiez le pare-feu distant, la route distante et le système cible
• La capture de paquets montre des paquets sans règle correspondante: L’ordre des règles, la zone ou le service ne correspond pas Comparez Log Viewer, Policy Test et Rule ID

Cette classification ne remplace pas une analyse détaillée. Elle empêche cependant de chercher une erreur de Phase 2 dans les règles de pare-feu ou de réinitialiser inutilement la clé pré-partagée pour un problème de retour.

Collecte des journaux

Sophos Firewall utilise StrongSwan pour IPsec. Les journaux principaux se trouvent dans /log :

• strongswan.log: Principal fichier journal IPsec pour IKE, authentification et Child SAs
• charon.log: Journal du démon IKE, utile selon la version et la situation
• strongswan-monitor.log: Surveillance du service IPsec
• dgd.log: Détection de passerelle morte et basculement VPN

On accède à la Advanced Shell via SSH et on se rend au besoin dans le répertoire des journaux :

cd /log

Le journal en direct peut être suivi directement :

tail -f /log/strongswan.log

Si plusieurs tunnels sont actifs, il est conseillé de filtrer. Cela peut se faire par le nom du tunnel, une IP de pair ou un texte d’erreur typique :

tail -f /log/strongswan.log | grep -i azure-vpn

Pour les fichiers journaux existants, less est souvent plus confortable :

less /log/strongswan.log

Dans less, on peut rechercher avec /terme dans le fichier. Alternativement, grep filtre directement :

grep -i "no proposal" /log/strongswan.log

Activer le débogage StrongSwan

Si le journal normal ne suffit pas, on peut passer le service StrongSwan en mode débogage :

service strongswan:debug -ds nosync

Ensuite, vérifiez si le service fonctionne en mode débogage :

service -S | grep strongswan

La sortie devrait indiquer RUNNING,DEBUG pour strongswan. Ensuite, reconnectez le tunnel ou reproduisez l’erreur et observez le journal :

tail -f /log/strongswan.log

La même commande de débogage désactive à nouveau le mode débogage :

service strongswan:debug -ds nosync

⚠️ Ne laissez le débogage actif que le temps nécessaire. Le débogage IPsec peut générer rapidement de gros fichiers journaux et occuper inutilement de l’espace sur le pare-feu.

Phase 1 : IKE, ID et authentification

Si le tunnel ne s’établit pas du tout, la cause se situe généralement avant ou pendant la Phase 1. Les passerelles négocient alors IKE, l’authentification et les identités des deux parties, mais pas encore les réseaux de données.

Causes typiques :

• La version IKE ne correspond pas
• Le profil IPsec ou la proposition ne correspond pas
• L’ID local ou distant est différent de celui attendu
• La clé pré-partagée est incorrecte
• L’autre partie atteint la mauvaise IP publique
• NAT-T ou la redirection de port sur UDP 500 et 4500 n’est pas correcte
• Les certificats, CA ou validité ne correspondent pas pour l’authentification basée sur certificat

No IKE config found

Une entrée de journal comme no IKE config found ou NO_PROPOSAL_CHOSEN signifie souvent que Sophos Firewall ne trouve pas de configuration IKE appropriée pour le paquet entrant. Cela peut être dû à la version IKE, à la passerelle, aux ID ou au profil IPsec.

Vérifiez :

• IKEv1 ou IKEv2 est-il correct des deux côtés ?
• L’autre partie correspond-elle à l’adresse de passerelle distante configurée ou au FQDN ?
• Les ID locaux et distants correspondent-ils ?
• Le chiffrement, l’authentification, le groupe DH et la durée de vie sont-ils compatibles ?
• L’autre partie utilise-t-elle une IP publique différente de celle documentée ?

Peer authentication failed

peer authentication failed, AUTH_FAILED ou no matching peer config found indique souvent des ID ou des données d’authentification non correspondants. Avec une clé pré-partagée, on soupçonne souvent d’abord la clé. C’est souvent correct, mais pas toujours. Si l’ID ne correspond pas, le pare-feu peut ne pas vérifier la configuration de pair attendue.

Vérifiez :

• L’ID local d’un côté correspond à l’ID distant de l’autre côté.
• L’ID distant d’un côté correspond à l’ID local de l’autre côté.
• L’orthographe, la casse, le FQDN et les adresses IP sont exacts.
• La clé pré-partagée a été saisie sans espaces au début ou à la fin.
• Pour plusieurs tunnels vers la même autre partie, il est clair quelle connexion doit correspondre.

Invalid HASH_V1 payload ou decryption failed

Avec IKEv1, des messages comme invalid HASH_V1 payload length ou decryption failed indiquent souvent une clé pré-partagée incorrecte. Avec IKEv2, on voit plutôt AUTHENTICATION_FAILED ou AUTH_FAILED.

En pratique, il est préférable de réinitialiser la clé pré-partagée des deux côtés plutôt que de la comparer visuellement. Le copier-coller à partir de gestionnaires de mots de passe, les espaces invisibles ou les caractères spéciaux différents sont des pièges classiques.

Phase 2 : Sélecteurs de trafic et associations de sécurité

Si la Phase 1 réussit mais que la Phase 2 échoue, cela concerne généralement les réseaux et la Child SA. Sophos Firewall doit négocier avec l’autre partie quels sous-réseaux locaux et distants sont autorisés à passer par le tunnel.

Indications typiques dans les journaux :

• traffic selectors ... inacceptable
• failed to establish CHILD_SA
• received traffic selectors didn't match
• TSi et TSr montrent des réseaux différents de ceux attendus

Vérifiez :

• Les réseaux locaux et distants sont configurés en miroir des deux côtés.
• Le masque de réseau et les objets hôtes individuels sont exacts.
• Il n’y a pas de chevauchements involontaires avec d’autres tunnels.
• Plusieurs réseaux de Phase 2 sont représentés de la même manière des deux côtés.
• PFS, chiffrement ESP, authentification et durée de vie sont compatibles.

Exemple : Si Sophos Firewall attend localement 172.16.10.0/24 et à distance 10.20.30.0/24, l’autre partie doit proposer exactement en miroir 10.20.30.0/24 vers 172.16.10.0/24. Un /24 d’un côté et un hôte unique ou un réseau plus grand de l’autre côté peuvent suffire à empêcher l’installation de la Child SA.

Le tunnel est établi, mais aucun trafic ne passe

Si le tunnel est affiché comme connecté mais qu’aucun trafic ne passe, l’IPsec lui-même n’est pas automatiquement la cause. Cela concerne généralement le routage, les règles de pare-feu, le NAT ou le chemin de retour.

Commencez par vérifier l’état IPsec dans la Advanced Shell :

ipsec statusall

Les points intéressants sont :

• La SA IKE est-elle ESTABLISHED ?
• La Child SA est-elle INSTALLED ?
• Quels réseaux locaux et distants sont affichés ?
• Les compteurs d’octets augmentent-ils dans les deux sens ?
• Ne voit-on que des octets sortants, mais pas d’entrants ?
• Y a-t-il des reconnections ou des renouvellements réguliers ?

Pour un IPsec route-based, on peut aussi vérifier si le XFRM state et la XFRM policy sont bien installés :

ip xfrm state
ip xfrm policy

Si ipsec statusall montre une SA établie, mais que ip xfrm state ou ip xfrm policy ne correspond pas au tunnel attendu, le problème n’est souvent plus le PSK ou le proposal, mais les Traffic Selectors, la configuration XFRM, les routes ou des tunnels concurrents.

Si la Child SA est installée mais que les compteurs d’octets restent vides, le trafic attendu n’atteint probablement pas le tunnel. Vérifiez alors le chemin avant et après IPsec.

Règles de pare-feu

Pour que le trafic passe par le tunnel, des règles de pare-feu appropriées sont nécessaires. Selon le modèle de zones, cela peut être LAN vers VPN, VPN vers LAN ou une zone dédiée. La règle doit couvrir correctement la source, la destination, le service et la direction.

Important :

• Activez Log firewall traffic dans les règles concernées.
• Vérifiez la position de la règle pour qu’aucune règle plus générale ne s’applique avant.
• Choisissez correctement les zones source et destination.
• N’utilisez pas d’objets trop larges pour plusieurs VPN si cela peut correspondre au mauvais tunnel.
• Vérifiez consciemment les fonctionnalités de sécurité comme IPS, le filtrage Web ou le contrôle des applications si elles sont actives sur le trafic.

Un processus de vérification général est décrit dans Tester une règle de pare-feu avec Log Viewer, Policy Test et Packet Capture.

Routage et routes IPsec

Si le pare-feu n’envoie pas le trafic dans le tunnel, vérifiez les routes. Pour les IPsec basés sur la politique, la table de routage IPsec peut également être pertinente :

ip route show table 220

Si une attribution manuelle est nécessaire, une Route IPsec sur Sophos Firewall peut aider. Si plusieurs types de routage sont en concurrence, vérifiez également la Priorité de routage sur Sophos Firewall.

Vérifiez :

• Y a-t-il une route statique plus spécifique qui intercepte le trafic ?
• Une route de politique SD-WAN s’applique-t-elle avant la route VPN ?
• La passerelle client pointe-t-elle vraiment vers Sophos Firewall ?
• L’autre partie a-t-elle une route de retour vers le réseau local ?
• Y a-t-il des réseaux locaux et distants qui se chevauchent ?

Pour un VPN route-based, il faut également contrôler les interfaces XFRM. Deux interfaces XFRM ne doivent pas être configurées avec des réseaux d’interface qui se chevauchent ou sont identiques. Si xfrm1 et xfrm2 se trouvent dans le même réseau de transfert, le tunnel peut être correctement established et malgré tout router de manière incorrecte. Dans ce cas, vérifier l’adressage XFRM sous Network > Interfaces et utiliser des réseaux distincts.

Si plusieurs connexions IPsec utilisent les mêmes sous-réseaux locaux et distants, elles ne doivent pas exister simplement côte à côte. Ces connexions doivent faire partie d’un design de failover explicite ou recevoir une logique de selectors/routing distincte. Sinon, la firewall ne peut pas utiliser de manière fiable le tunnel attendu.

NAT

Le NAT n’est pas fondamentalement incorrect avec IPsec, mais il doit être configuré consciemment. Un MASQ involontaire ou une règle SNAT trop large peut faire en sorte que l’autre partie n’associe plus le trafic au réseau attendu.

Vérifiez :

• Une règle MASQ générique s’applique-t-elle avant une règle NAT VPN spécifique ?
• L’autre partie attend-elle des adresses IP d’origine ou des adresses traduites ?
• Le NAT est-il documenté des deux côtés ?
• La règle NAT correspond-elle à la direction du trafic ?

Si le NAT est impliqué, l’article Comprendre le NAT sur Sophos Firewall : SNAT, DNAT, MASQ, PAT est utile.

SFOS 22 : Vérifiez consciencieusement le NAT et l’IPsec basé sur la politique

Lors des mises à niveau vers SFOS 22, l’IPsec basé sur la politique doit être vérifié avec soin. Sophos mentionne dans les notes de version de SFOS 22 un comportement modifié pour le VPN IPsec basé sur la politique. De plus, le problème résolu NC-170917 est documenté : le trafic IPsec basé sur la politique pouvait échouer si la règle SNAT par défaut était configurée avec une adresse IP statique au lieu de MASQ.

En pratique, cela signifie que si un tunnel basé sur la politique est vert après la mise à niveau, mais que le trafic est absent ou unilatéral, le NAT ne doit pas être traité comme un sujet secondaire. Une ancienne règle SNAT par défaut large ou inhabituellement ajustée peut modifier exactement le trafic que l’autre partie attend avec les réseaux d’origine.

Points de vérification typiques après une mise à niveau SFOS 22 :

• Le tunnel est-il vraiment basé sur la politique ?: Pour l’IPsec basé sur la politique, les réseaux locaux et distants font partie de la négociation. Le NAT peut briser cette attente.
• La règle SNAT par défaut a-t-elle été ajustée ?: Une IP SNAT statique au lieu de MASQ peut avoir des effets différents après une mise à niveau.
• Y a-t-il des règles NAT VPN spécifiques ?: Celles-ci doivent être placées au-dessus des règles SNAT ou MASQ générales et correspondre à la direction du trafic.
• Les sélecteurs de trafic et les objets NAT correspondent-ils ?: L’autre partie doit attendre soit les réseaux d’origine, soit les réseaux traduits, pas les deux par hasard.
• La capture de paquets montre-t-elle l’IP source attendue ?: Cela permet de voir si le pare-feu utilise une autre adresse source avant le tunnel.

Un test propre consiste en une source, une destination et un service. Ensuite, vérifiez successivement la règle de pare-feu, la règle NAT, ipsec statusall, ip route show table 220, la capture de paquets et l’autre partie. Si le test ne fonctionne qu’avec la règle NAT désactivée ou déplacée, le problème ne réside pas dans l’établissement du tunnel, mais dans le chemin vers le tunnel.

Pour la planification de la mise à niveau, consultez également Vérifier Sophos Firewall avant la mise à niveau SFOS 22. Pour les bases du NAT et l’ordre des règles, Comprendre le NAT sur Sophos Firewall est une meilleure introduction.

Rekey, failover et état d’interface

Lorsqu’un tunnel fonctionne d’abord puis tombe plus tard, la configuration initiale n’est pas toujours fausse. Il faut alors examiner la chronologie :

• Traffic-based Rekeying chez des tiers : Sophos Firewall attend une logique de rekey basée sur le temps. Si la contrepartie impose un rekey basé sur le trafic, le tunnel peut finir par se bloquer ou renégocier.
• Key exchange collisions : si les deux côtés rekeyent en même temps, des phases instables peuvent apparaître. Dans ces cas, les lifetimes Phase 1 et Phase 2 doivent être ajustées consciemment entre initiator et responder.
• Interface désactivée : si l’interface associée est désactivée, un tunnel Site-to-Site initiateur se coupe immédiatement. Les connexions responder et Remote Access tombent au plus tard par inactivité ou DPD timeout.
• DGD et groupe de failover : dans les scénarios de failover, vérifier aussi dgd.log, l’état gateway, la connexion primaire/secondaire et les paires de sous-réseaux identiques.

Ces erreurs se reconnaissent mieux avec des horodatages qu’avec un seul snapshot. Pour des problèmes intermittents, il faut donc rapprocher chronologiquement l’état du tunnel, strongswan.log, dgd.log, les événements WAN et le test applicatif.

SFOS 22 : PPPoE-WAN avec interface alias et accélération IPsec

Après une mise à niveau vers SFOS 22.0 GA ou SFOS 22.0 MR1, un tunnel IPsec peut être connecté mais ne pas transmettre de trafic dans certains cas particuliers. Sophos mentionne dans la liste des problèmes connus NC-181526 : sur le matériel XGS, les tunnels IPsec sur les interfaces alias d’un port PPPoE-WAN peuvent être établis mais ne pas transmettre de trafic utilisateur si l’accélération IPsec est active.

Ce point ne doit être vérifié que si les causes normales ne correspondent pas. Un tunnel vert sans trafic est généralement toujours un problème de règle, de routage, de NAT ou de retour. Le cas particulier SFOS 22 devient plus probable si tous les points suivants sont réunis :

• Sophos Firewall fonctionne sur SFOS 22.0 GA ou SFOS 22.0 MR1.
• Il s’agit de matériel XGS.
• Le tunnel concerné utilise une interface alias sur un port PPPoE-WAN.
• Le tunnel s’établit, mais le trafic utilisateur est absent.
• Les règles de pare-feu, NAT, routes, retour et capture de paquets n’expliquent pas le comportement.
• L’accélération IPsec est active.

Comme solution de contournement, la désactivation de l’accélération IPsec est documentée :

system ipsec-acceleration off

Cela ne doit pas être utilisé comme une commande de réglage IPsec générique. Le changement doit être effectué dans une fenêtre de maintenance ou un processus de support documenté, avec un test avant/après et une attribution claire au problème affecté. Sophos liste SFOS 22.0.2 MR2 comme version de correction pour ce problème connu. Si cette version est approuvée pour l’environnement concerné, une mise à jour planifiée est plus propre qu’une solution de contournement oubliée.

Processus de vérification pratique :

1. Documentez le statut du tunnel et ipsec statusall.
2. Effectuez une capture de paquets avec un filtre source/destination étroit.
3. Vérifiez si le tunnel utilise vraiment une interface alias sur un port PPPoE-WAN.
4. Notez la version SFOS active et le modèle matériel.
5. Testez le changement d’accélération IPsec uniquement de manière ciblée et documentée.
6. Après le test, comparez les compteurs d’octets, la capture de paquets, le Log Viewer et le test d’application.

Combiner Log Viewer et Packet Capture

Le Log Viewer montre quelle règle ou quel module a évalué une connexion. Packet Capture dans WebAdmin montre si les paquets arrivent vraiment, sont transmis, rejetés ou traités par le pare-feu lui-même.

Pour le dépannage IPsec, définissez un test aussi étroit que possible :

• IP source: 172.16.10.25
• IP de destination: 10.20.30.15
• Service: ICMP ou TCP 443
• Direction attendue: LAN vers VPN
• Règle attendue: LAN_to_VPN_Branch

Ensuite :

1. Activez la journalisation dans la règle de pare-feu.
2. Filtrez le Log Viewer avec l’IP source, l’IP de destination et le module Firewall.
3. Démarrez la capture de paquets avec un filtre étroit, par exemple host 172.16.10.25 and host 10.20.30.15.
4. Reproduisez le test exactement une fois.
5. Vérifiez si les paquets arrivent, sont transmis et si les réponses reviennent.

Interprétation :

• Aucun paquet n’arrive sur Sophos Firewall: Vérifiez le client, la passerelle, le VLAN, le commutateur ou le routage local
• Le paquet arrive mais n’est pas transmis: Vérifiez la règle de pare-feu, le NAT, la route ou la fonctionnalité de sécurité
• Le paquet est envoyé dans le tunnel, mais la réponse manque: Vérifiez la route de retour, l’autre partie, le pare-feu distant ou l’hôte distant
• Seuls les octets sortants dans ipsec statusall: Vérifiez le chemin de retour ou la politique distante
• Seuls les octets entrants: Vérifiez la route locale, la règle de pare-feu locale ou le système cible

Pour des captures plus longues ou des cas de support, il peut être utile de collecter des journaux de manière ciblée. L’article Sauvegarder les journaux Sophos Firewall pour le support et l’analyse décrit l’exportation propre.

Scénarios d’erreur typiques

Les scénarios suivants se réfèrent aux chaînes de journalisation brutes StrongSwan/Charon de strongswan.log. Dans WebAdmin, les mêmes causes apparaissent souvent sous forme de message traduit, par exemple no IKE config found devient “Remote peer is refusing our Phase 1 proposals”, peer authentication failed devient “Remote peer reports we failed to authenticate” ou traffic selectors ... inacceptable devient “Remote peer reports INVALID_ID_INFORMATION”. Si vous consultez d’abord WebAdmin plutôt que le journal brut, cette correspondance aide à retrouver le cas correspondant.

• no IKE config found: La version IKE, la passerelle, les ID ou le profil ne correspondent pas Comparez la version IKE, les ID locaux/distants et les propositions
• NO_PROPOSAL_CHOSEN: Incompatibilité de proposition Vérifiez le chiffrement, l’authentification, le groupe DH, PFS et la durée de vie
• peer authentication failed: L’ID ou l’authentification ne correspond pas Vérifiez l’ID local/distant et la clé PSK/certificat
• AUTH_FAILED: La clé pré-partagée, le certificat ou l’ID ne correspond pas Réinitialisez la clé PSK, vérifiez la chaîne de certificats et les ID
• traffic selectors ... inacceptable: Les réseaux locaux et distants ne correspondent pas Comparez les sous-réseaux et les objets hôtes en miroir
• failed to establish CHILD_SA: Les réseaux de Phase 2 ou les propositions ESP ne correspondent pas Vérifiez les sélecteurs de trafic, PFS, le profil ESP et les durées de vie
• Tunnel vert, pas d’octets: Le trafic n’atteint pas le tunnel Vérifiez la règle de pare-feu, la route, le NAT et la passerelle client
• Octets sortants, pas d’entrants: L’autre partie ou le chemin de retour manque Vérifiez les règles distantes, la route distante et le système cible
• ipsec statusall affiche des SAs, mais le trafic route-based s’arrête plus tard: vérifier XFRM state, XFRM policy, réseaux XFRM qui se chevauchent, groupe de failover et comportement de rekey.
• Plusieurs tunnels avec les mêmes sous-réseaux: les tunnels doivent faire partie d’un groupe de failover ou recevoir une logique selector/routing clairement distincte.
• Les transferts importants échouent malgré un tunnel actif: MTU/MSS, perte de paquets ou découverte de MTU de chemin Vérifiez le MTU et le MSS en cas de problèmes VPN
• SFOS 22, IPsec basé sur la politique, tunnel vert, trafic manquant: Le NAT, la règle SNAT par défaut ou les sélecteurs de trafic ne correspondent pas correctement après la mise à niveau Vérifiez la règle SNAT par défaut, les règles NAT VPN, MASQ, la capture de paquets et l’autre partie
• SFOS 22, PPPoE-WAN alias, tunnel vert, pas de trafic: Problème connu possible avec l’accélération IPsec Vérifiez le type d’interface, la version SFOS et testez system ipsec-acceleration off uniquement de manière ciblée
• Reconnexions ou renouvellements fréquents: Durée de vie, DPD, ligne instable ou problème de proposition Vérifiez les temps de renouvellement, DPD, la stabilité WAN et les journaux

Liste de vérification pratique

À vérifier immédiatement :

• Notez le statut du tunnel et le dernier message d’erreur dans WebAdmin.
• Démarrez tail -f /log/strongswan.log et reconnectez le tunnel.
• Vérifiez la version IKE, l’ID local, l’ID distant et la clé pré-partagée.
• Comparez les sélecteurs de trafic ou les réseaux locaux et distants en miroir.
• Vérifiez ipsec statusall pour ESTABLISHED, INSTALLED et les compteurs d’octets.

Si le tunnel est établi :

• Vérifiez les règles de pare-feu dans les deux sens.
• Activez la journalisation sur les règles concernées.
• Filtrez le Log Viewer avec la source, la destination et l’ID de règle.
• Effectuez une capture de paquets avec un filtre étroit.
• Vérifiez les règles NAT et la priorité des routes.
• Pour un VPN route-based, vérifier ip xfrm state, ip xfrm policy et les réseaux d’interface XFRM.
• Pour plusieurs tunnels similaires, afficher le groupe de failover et les colonnes Local-/Remote-Subnet.
• Avec SFOS 22 et IPsec basé sur la politique, vérifiez la règle SNAT par défaut, les règles NAT VPN spécifiques et l’IP source attendue.
• Avec SFOS 22 et PPPoE-WAN alias, vérifiez si le problème connu d’accélération IPsec s’applique.
• Confirmez la route de retour sur l’autre partie.

Pour le support ou une analyse plus longue :

• Activez le débogage brièvement et désactivez-le ensuite.
• Sauvegardez les journaux pertinents.
• Documentez l’heure, le nom du tunnel, l’IP de pair, la source, la destination et le déroulement du test.
• Vérifiez les données sensibles avant de les transmettre.

FAQ