Objectif
Traiter un incident VPN site-à-site de manière reproductible : qualifier l’impact, préserver les éléments utiles, distinguer panne Internet, IKE, IPsec, routage ou firewall, restaurer le service puis documenter la cause.
Prérequis
- Heure de début approximative, sites concernés et applications impactées.
- Accès aux deux équipements VPN ou contact avec l’équipe distante.
- Configuration de référence du tunnel et coordonnées des liens opérateurs.
- Flux de test connu entre une source et une destination représentatives.
- Emplacement pour conserver logs, captures, commandes exécutées et chronologie.
Procédure pas à pas
Qualifier l’impact et la chronologie
Déterminez si tous les réseaux du tunnel sont affectés ou seulement une application. Vérifiez si l’incident coïncide avec un changement, un reboot, une bascule WAN ou une maintenance opérateur. Notez les heures dans un fuseau unique afin de corréler les logs des deux sites. Testez si d’autres tunnels utilisant le même WAN sont eux aussi affectés.
- Le périmètre et l’heure de début sont suffisamment précis pour rechercher les événements correspondants.
Vérifier les liaisons WAN indépendamment du VPN
Contrôlez les interfaces, routes par défaut, SD-WAN et la joignabilité du pair. Un tunnel ne peut pas s’établir si l’adresse publique a changé, si le lien est down ou si un NAT amont bloque IKE. Comparez les IP publiques réellement utilisées aux valeurs configurées et cherchez une bascule opérateur récente.
- Les deux sites disposent d’un chemin WAN fonctionnel vers l’adresse du pair.
Collecter l’état IKE/IPsec sans le réinitialiser
Capturez les informations de Phase 1 et Phase 2 avant toute action de remise à zéro. Les compteurs et durées d’établissement peuvent montrer si le tunnel vient de tomber ou s’il est resté up sans trafic. Conservez les sorties dans le dossier d’incident pour comparer avant et après remise en service.
get vpn ipsec tunnel summarydiagnose vpn ike gateway listdiagnose vpn tunnel list- L’état des SAs avant intervention est sauvegardé.
Comparer selectors, routes et policies
Vérifiez que le flux métier est inclus dans les selectors et qu’il suit bien la route du tunnel. Contrôlez aussi la policy de sécurité et le NAT. Si plusieurs VPN ou routes plus spécifiques existent, assurez-vous que le trafic n’est pas envoyé vers une autre sortie. Comparez la route retour sur le site distant.
get router info routing-table details <REMOTE-HOST>- Le chemin logique du flux est connu avant toute modification.
Capturer un flux de test
Lancez un test unique et observez les paquets IKE ou applicatifs. Sur FortiGate
diagnose sniffer packet any 'host <TEST-HOST> or host <PEER-IP>' 4 50 l- La capture montre où le trafic cesse ou si le pair ne répond pas.
Effectuer une remise en service ciblée
Si la cause est identifiée et qu’une action est nécessaire, privilégiez l’élément minimal : corriger une route, une policy, un selector ou rétablir le lien WAN. Si les paramètres sont corrects mais qu’une SA est bloquée, utilisez une action ciblée sur le tunnel plutôt qu’un flush global ou un reboot de l’appliance.
- Le service revient sans affecter les autres tunnels ou réseaux.
Valider les applications et le sens retour
Après rétablissement, testez les applications réellement utilisées, pas uniquement ICMP. Vérifiez le sens retour, les DNS internes éventuels et les compteurs du tunnel. Surveillez au moins un rekey si l’incident peut être lié au renouvellement des SAs ou à un changement d’adresse du pair.
diagnose vpn tunnel list name <TUNNEL-NAME>- Les compteurs augmentent dans les deux sens et les applications sont validées.
Clôturer avec cause et actions préventives
Rédigez une chronologie courte : symptôme, observations, cause, action de remise en service et prévention. Si la cause reste inconnue, indiquez-le explicitement et conservez les captures ; n’inventez pas une cause à partir du simple fait qu’un redémarrage ou une renégociation a résolu le symptôme.
- Le rapport distingue clairement cause confirmée, hypothèse et simple action de rétablissement.
Validation
La procédure est validée lorsque :
- Le tunnel est établi et les SAs restent stables.
- Les flux métier critiques fonctionnent dans les deux sens attendus.
- La cause ou, à défaut, les éléments collectés sont documentés.
- Aucun debug permanent ni modification temporaire non documentée ne reste actif.
Retour arrière
- Revenir à la configuration de référence si une modification d’urgence dégrade la situation.
- Retirer les routes, policies ou paramètres temporaires créés uniquement pour le diagnostic.
- Si une bascule WAN temporaire a été utilisée, restaurer le chemin nominal seulement après validation du lien principal.
Dépannage / erreurs fréquentes
- Tunnel down sur les deux côtés : commencer par WAN, IP du pair et IKE avant les policies internes.
- Tunnel up mais aucun trafic : inspecter routes, selectors, policies et NAT.
- Un seul réseau du VPN est KO : comparer le selector concerné aux autres avant de toucher à la Phase 1.
- Incident récurrent au même intervalle : corréler l’heure aux lifetimes/rekeys, DPD et changements d’adresse du pair.
- Le service revient après flush mais la cause n’est pas connue : conserver les sorties avant/après et ouvrir une analyse séparée au lieu de considérer le problème clos.