Objectif
Modifier un tunnel IPsec FortiGate en production sans perdre la capacité de retour arrière, en figeant l’état initial, en coordonnant les deux extrémités, en changeant une seule dimension à la fois et en définissant à l’avance des critères de succès et d’abandon.
Prérequis
- Ticket ou plan de changement avec horaire, personnes présentes aux deux extrémités et durée maximale d’indisponibilité acceptée.
- Nom des Phase 1/Phase 2, IP des pairs, réseaux locaux/distants, routes et policies associées.
- Sauvegarde complète de la configuration FortiGate et extraits lisibles de la configuration IPsec actuelle.
- Jeu de tests métier précis : hôtes, ports, applications et sens de trafic.
- Plan de rollback écrit avec seuil de déclenchement, par exemple cinq minutes sans Phase 1 ou dix minutes sans flux métier.
Procédure pas à pas
Capturer l’état initial
Avant le créneau, relevez l’état du tunnel, les SAs, les compteurs, les routes et les policies. Exportez la configuration complète et copiez les blocs Phase 1/Phase 2. Cette référence permet de revenir exactement aux valeurs précédentes au lieu de se fier à la mémoire pendant une panne. Notez également la version FortiOS et l’heure de la capture.
get vpn ipsec tunnel summarydiagnose vpn ike gateway listdiagnose vpn tunnel list name <TUNNEL-NAME>show full-configuration vpn ipsec phase1-interfaceshow full-configuration vpn ipsec phase2-interface- Un état initial horodaté est disponible avant tout changement.
- Les compteurs de trafic et l’état des SAs sont connus.
Comparer les deux extrémités avant la fenêtre
Mettez côte à côte version IKE, proposals, groupes DH/PFS, lifetimes, identités et selectors. Si le changement concerne un nouvel algorithme ou un nouveau réseau, confirmez que le pair distant sait le supporter et qu’il sera modifié dans le même créneau. La coordination doit préciser qui change en premier et comment confirmer l’établissement.
- La configuration cible est identique sur tous les paramètres qui doivent matcher.
- Le responsable de chaque côté connaît l’ordre d’exécution et le signal de rollback.
Préparer les routes et policies sans les activer prématurément
Si de nouveaux réseaux doivent passer dans le tunnel, préparez les objets et vérifiez les routes et policies. Évitez d’envoyer du trafic vers un selector qui n’existe pas encore chez le pair. Lorsque la plateforme le permet, créez les objets non intrusifs avant la bascule afin de réduire le nombre d’actions pendant l’interruption.
- Les dépendances sont prêtes sans détourner le trafic avant la bascule.
Appliquer une seule dimension de changement
Commencez par le paramètre prévu dans le plan : proposal, selector, adresse du pair, PFS ou autre. Ne corrigez pas au passage des éléments sans lien avec le changement. Notez l’heure exacte de chaque modification pour la comparer aux logs IKE des deux côtés et faciliter le retour arrière.
- Chaque modification est traçable et peut être annulée indépendamment.
Contrôler immédiatement Phase 1 et Phase 2
Après la modification coordonnée, vérifiez d’abord IKE puis les SAs IPsec. Une Phase 1 up avec Phase 2 down indique un problème différent d’une absence totale d’IKE. Comparez les selectors affichés aux réseaux réellement ajoutés et contrôlez les compteurs avant de lancer des tests applicatifs.
diagnose vpn ike gateway listdiagnose vpn tunnel list name <TUNNEL-NAME>- Les deux phases sont établies avant de considérer la bascule technique réussie.
- Les selectors sont exactement ceux du plan de changement.
Tester les flux métier dans les deux sens
Générez des flux représentatifs plutôt qu’un simple ping
Test-NetConnection <REMOTE-HOST> -Port <TCP-PORT>diagnose vpn tunnel list name <TUNNEL-NAME>- Le service métier fonctionne et les compteurs augmentent dans les deux sens.
Déclencher le rollback dès le seuil atteint
Si le critère d’abandon est atteint, arrêtez le dépannage exploratoire et remettez les valeurs précédentes dans l’ordre inverse du changement. Coordonnez le retour sur les deux extrémités. Après rétablissement, confirmez que les anciennes SAs et les flux métier reviennent avant de poursuivre l’analyse hors production.
- Le retour à l’état initial peut être exécuté rapidement et sans improvisation.
Documenter l’état final et surveiller les rekeys
Conservez la configuration finale, les paramètres négociés, les tests réalisés et les anomalies éventuelles. Surveillez les rekeys suivants : un tunnel peut fonctionner immédiatement puis échouer au renouvellement si lifetimes ou PFS sont incohérents. Planifiez un contrôle après au moins un cycle de renouvellement pertinent.
- La documentation permet de reproduire ou d’annuler le changement lors d’une prochaine intervention.
Validation
La procédure est validée lorsque :
- La Phase 1 et la Phase 2 sont établies après le changement et après un rekey.
- Les nouveaux selectors ou paramètres apparaissent exactement comme prévu.
- Les applications critiques fonctionnent dans les deux sens requis.
- Le plan de rollback reste exécutable et la configuration finale est sauvegardée.
Retour arrière
- Remettre les valeurs Phase 2 puis Phase 1 modifiées dans l’ordre inverse de la bascule, en coordination avec le pair.
- Restaurer les routes et policies précédentes si elles faisaient partie du changement.
- Si le retour manuel échoue, utiliser la sauvegarde FortiGate validée et la procédure de restauration prévue.
- Ne poursuivre l’analyse qu’après retour du service si la fenêtre de changement est dépassée.
Dépannage / erreurs fréquentes
- Nouvelle proposal refusée : remettre l’ancienne proposition puis vérifier les capacités et la configuration exacte du pair.
- Nouveau selector absent : comparer les deux Phase 2 et les réseaux source/destination de chaque côté.
- Tunnel remonte mais le trafic suit l’ancienne route : contrôler distance, priorité et SD-WAN.
- Le tunnel tombe au rekey : comparer lifetimes, PFS et comportement DPD plutôt que de conclure sur le premier établissement.
- Les deux phases sont up mais une application reste KO : vérifier firewall hôte, MTU, DNS et dépendances applicatives avant de modifier encore IPsec.