Boîte à Outils Informatique
Guide

Comment vérifier l’état d’un tunnel IPsec FortiGate

Contrôler rapidement l’état des tunnels IPsec depuis la CLI FortiGate.

ThématiqueFortiGate →
⌚ Environ 3 min de lecture
Voir mes favoris
FortiGate & VPN Avancé 8 min

Contrôler rapidement l’état des tunnels IPsec depuis la CLI FortiGate.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une sauvegarde ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Se connecter à la CLI

    Utilisez un accès d’administration sécurisé.

  2. 2

    Afficher le résumé VPN

    Utilisez get vpn ipsec tunnel summary.

  3. 3

    Contrôler un tunnel précis

    Utilisez diagnose vpn tunnel list name suivi du nom du tunnel.

  4. 4

    Vérifier les routes et policies

    Un tunnel monté ne garantit pas que le trafic est autorisé.

  5. 5

    Observer les logs si nécessaire

    Analysez les événements VPN et firewall avant d’activer un debug approfondi.

Commandes utiles

get vpn ipsec tunnel summary
diagnose vpn tunnel list name NOM_DU_TUNNEL

À retenir

  • Les commandes exactes peuvent varier selon la version FortiOS.
  • Désactivez les debug après utilisation pour éviter une charge et un volume de logs inutiles.
← Tous les guides
Complément technique

FortiGate IPsec : Phase 1, Phase 2 et trafic sont trois validations distinctes

Repères techniques

  • Phase 1 valide l’IKE/peer/authentification ; Phase 2 valide les SA IPsec et selectors. Un tunnel “up” peut malgré tout ne transporter aucun trafic.
  • NAT-T
  • Routes, policies, NAT et selectors doivent correspondre au flux réel dans les deux sens.

CLI ciblée

Lire les gateways/SA puis filtrer le debug sur le peer au lieu d’activer un debug IKE global non borné.

get vpn ipsec tunnel summary
diagnose vpn ike gateway list
diagnose vpn tunnel list

Pièges spécifiques

  • Un ping depuis le FortiGate sans préciser la source peut emprunter une autre interface que le trafic utilisateur.
  • Un Phase 2 down peut venir de selectors/proposals alors que la Phase 1 est parfaitement saine.

Comment valider

  • Les SA attendues sont up et leurs compteurs RX/TX augmentent pendant le test du vrai flux.
  • Policy, route et session montrent le chemin attendu sans NAT involontaire.

Preuves et vérifications

Phase 1 valide l’IKE/peer/authentification ; Phase 2 valide les SA IPsec et selectors. Un tunnel “up” peut malgré tout ne transporter aucun trafic. NAT-T utilise UDP/4500 lorsqu’un NAT est détecté ; sinon IKE démarre typiquement sur UDP/500.

Contrôle de résultat

Les SA attendues sont up et leurs compteurs RX/TX augmentent pendant le test du vrai flux. Policy, route et session montrent le chemin attendu sans NAT involontaire.

Point d’attention

Un ping depuis le FortiGate sans préciser la source peut emprunter une autre interface que le trafic utilisateur. Routes, policies, NAT et selectors doivent correspondre au flux réel dans les deux sens.

Concepts liés

Référence primaire : Fortinet Docs — FortiGate Administration Guide.

♡ 0