Boîte à Outils Informatique
Procédure

Diagnostiquer un tunnel IPsec FortiGate

Diagnostiquer méthodiquement un tunnel IPsec FortiGate : Phase 1, Phase 2, selectors, routage, policies, compteurs, capture et debug IKE ciblé.

Réseau
ThématiqueFortiGate →
⌚ Environ 6 min de lecture
Voir mes favoris
DomaineRéseauNiveauAvancéDurée30-120 minRisqueMoyen

Objectif

Identifier précisément pourquoi un tunnel IPsec FortiGate est down, up sans trafic ou fonctionnel dans un seul sens, en séparant l’analyse de la connectivité WAN, de la Phase 1 IKE, de la Phase 2, des selectors, du routage et des policies.

Prérequis

  • Nom exact de la Phase 1 et, si possible, de la Phase 2 concernée.
  • IP publique ou FQDN du pair, interface WAN utilisée et heure précise du dernier échec.
  • Sous-réseaux locaux/distants attendus et type de routage : routes statiques, SD-WAN ou routage dynamique.
  • Accès aux logs VPN des deux extrémités ou canal de coordination avec l’administrateur distant.
  • Sauvegarde

Procédure pas à pas

1

Qualifier le symptôme avant de modifier

Déterminez si la Phase 1 est absente, si la Phase 2 ne s’établit pas, si le tunnel est up mais sans octet ou si un seul sens circule. Relevez l’heure, la dernière modification et les sous-réseaux affectés. Un diagnostic efficace commence par un symptôme reproductible et un seul flux de test.

get vpn ipsec tunnel summary
diagnose vpn ike status
Résultat attendu
  • Le tunnel concerné est identifié sans confusion.
  • Le niveau de panne est classé : IKE/Phase 1, IPsec/Phase 2 ou trafic post-tunnel.
2

Vérifier la connectivité vers le pair et les ports IKE

Confirmez que l’interface WAN est opérationnelle et que le pair est joignable selon l’architecture. IKE utilise UDP 500 et, avec NAT-T, UDP 4500. ESP peut être visible directement lorsque NAT-T n’est pas utilisé. Une capture courte permet de voir si les paquets sortent, si le pair répond et si la négociation bascule en 4500.

diagnose sniffer packet any 'host <PEER-IP> and (udp port 500 or udp port 4500 or proto 50)' 4 30 l
Résultat attendu
  • Des paquets IKE sortent vers le pair et des réponses reviennent si le chemin amont est fonctionnel.
3

Contrôler la Phase 1 IKE

Affichez l’état des gateways IKE et comparez version IKE, identité, proposition cryptographique, authentification, DPD et adresse du pair. Une erreur de PSK, certificat ou proposal bloque généralement ici. Ne rendez pas la suite cryptographique plus permissive au hasard : comparez d’abord la configuration distante.

diagnose vpn ike gateway list
show full-configuration vpn ipsec phase1-interface
Résultat attendu
  • Une SA IKE établie est visible lorsque la Phase 1 est correcte.
  • Les paramètres critiques correspondent à ceux documentés chez le pair.
4

Contrôler Phase 2, selectors et compteurs

Une Phase 1 up ne garantit pas la Phase 2. Inspectez les SAs IPsec, proxy IDs/selectors, PFS, proposals et lifetimes. Vérifiez surtout que les réseaux source et destination correspondent réellement aux réseaux envoyés par le pair. Les compteurs rx/tx permettent de voir si le chiffrement existe mais que le trafic ne revient pas.

diagnose vpn tunnel list name <TUNNEL-NAME>
show full-configuration vpn ipsec phase2-interface
Résultat attendu
  • Une SA Phase 2 est installée avec les selectors attendus.
  • Les compteurs permettent de distinguer absence de trafic, trafic seulement émis ou trafic bidirectionnel.
5

Vérifier routes et chemin de sortie

Contrôlez que le réseau distant est envoyé vers l’interface tunnel ou vers le mécanisme SD-WAN prévu. Si plusieurs routes existent, comparez distance et priorité. Sur le chemin retour, le site distant doit posséder une route vers le réseau local. Une route plus spécifique vers Internet ou un autre VPN peut rendre le tunnel up mais inutilisable.

get router info routing-table details <REMOTE-HOST>
get router info routing-table all
Résultat attendu
  • La destination de test utilise réellement le tunnel attendu.
6

Vérifier les firewall policies et le NAT

Identifiez la policy LAN vers IPsec et, si nécessaire, IPsec vers LAN. Le NAT est généralement désactivé pour un VPN site-à-site classique sauf conception volontaire différente. Vérifiez les objets source/destination, services, ordre des règles et logs. Une règle plus large placée avant la policy VPN peut envoyer le trafic vers la mauvaise sortie.

Résultat attendu
  • Le flux de test matche la policy VPN attendue.
  • Le NAT et les objets réseau sont cohérents avec les selectors.
7

Tracer un flux de test à travers FortiOS

Si le tunnel et le routage semblent corrects, lancez un debug flow sur une IP source/destination précise. Le résultat permet de voir la route choisie, la policy et un éventuel deny. Stoppez et réinitialisez toujours le debug. Sur NP6/NP7, tenez compte de l’offload matériel qui peut masquer certaines traces.

diagnose debug reset
diagnose debug flow filter clear
diagnose debug flow filter saddr <SOURCE-IP>
diagnose debug flow filter daddr <DESTINATION-IP>
diagnose debug flow show function-name enable
diagnose debug enable
diagnose debug flow trace start 100
diagnose debug flow trace stop
diagnose debug disable
diagnose debug reset
Résultat attendu
  • La décision de routage et la policy sont visibles pour le flux exact.
  • Le debug est arrêté immédiatement après collecte.
8

Activer un debug IKE ciblé uniquement si nécessaire

Pour un échec de négociation non expliqué, filtrez le journal IKE sur le tunnel puis activez temporairement le debug du daemon IKE. Reproduisez une seule négociation, capturez le message d’erreur et désactivez le debug. Analysez le premier mismatch réel au lieu de modifier plusieurs propositions au hasard.

diagnose vpn ike log filter clear
diagnose vpn ike log filter name <PHASE1-NAME>
diagnose debug application ike -1
diagnose debug enable
diagnose debug disable
diagnose debug reset
Résultat attendu
  • Le message permet de rattacher l’échec à l’authentification, au proposal, à l’identité, au selector ou à la connectivité.

Validation

La procédure est validée lorsque :

  • Phase 1 et Phase 2 sont établies avec les paramètres et selectors documentés.
  • La route vers le réseau distant utilise le chemin prévu et la policy VPN matche le trafic.
  • Les compteurs IPsec augmentent dans les deux sens lors du test.
  • Un flux applicatif représentatif fonctionne et aucun debug n’est laissé actif.

Retour arrière

  • Si une modification a été faite pendant le diagnostic, revenir au dernier état documenté qui permettait l’établissement du tunnel.
  • Ne videz une SA ou ne redémarrez un tunnel qu’après avoir mesuré l’impact ; privilégiez une action ciblée.
  • Réappliquer la sauvegarde si plusieurs paramètres ont été modifiés sans résultat reproductible.

Dépannage / erreurs fréquentes

  • Phase 1 absente : vérifier réponse du pair, UDP 500/4500, identité, PSK/certificat et proposals.
  • Phase 1 up mais Phase 2 absente : comparer selectors, PFS, proposals et lifetimes.
  • Tunnel up, tx augmente mais rx reste à zéro : analyser routage et selectors du pair distant ainsi que son firewall.
  • Trafic bidirectionnel dans le tunnel mais application KO : contrôler service cible, firewall hôte, DNS et MTU.
  • Debug flow silencieux : vérifier l’offload NP6/NP7 et préférer une capture ciblée avant de désactiver l’accélération.

Références officielles

♡ 0