FortiGate : VPN IPsec site à site pas à pas

📍 Guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
Ce tutoriel fait partie d’une série sur le cœur de réseau professionnel. Pour la vue d’ensemble, lisez d’abord le guide principal.

Relier deux sites d’une même organisation par Internet tout en gardant le trafic confidentiel est l’un des besoins les plus courants en entreprise. Le standard universel pour cela est le VPN IPsec site à site, et FortiGate en fait une opération guidée. Dans ce tutoriel, vous allez monter un tunnel IPsec entre deux pare-feu FortiGate, configurer les politiques qui autorisent le trafic à le traverser, et vérifier que les deux réseaux communiquent de façon chiffrée.

🎯 Ce que vous allez apprendre

• Comprendre les deux phases de négociation IPsec et pourquoi elles doivent concorder des deux côtés.
• Créer un tunnel IPsec site à site avec l’assistant FortiOS.
• Définir les routes et les politiques de pare-feu qui font passer le trafic dans le tunnel.
• Vérifier l’état du tunnel et diagnostiquer un tunnel qui refuse de monter.

🛠️ Ce que vous allez construire

À la fin, deux sites — appelons-les siège et agence — disposeront d’un tunnel chiffré permanent. Un poste du siège pourra joindre un serveur de l’agence comme s’ils étaient sur le même réseau local, et tout ce trafic transitera chiffré sur Internet. C’est l’ossature d’un réseau multi-sites professionnel.

Prérequis

• Deux pare-feu FortiGate sous FortiOS (version 7.6.x recommandée), physiques ou virtuels (FortiGate-VM).
• Une adresse IP publique joignable sur le WAN de chaque site (au moins une des deux doit être fixe et accessible).
• Des plans d’adressage internes distincts de chaque côté (par exemple 10.1.0.0/24 au siège, 10.2.0.0/24 à l’agence).
• Niveau : intermédiaire. Test express : si vous savez ouvrir l’interface d’un FortiGate et lire une table de routage, vous êtes prêt.
• ⏱️ Temps estimé : ~45 minutes.

Étape 1 — Comprendre les deux phases d’IPsec

Avant de cliquer, comprenons ce qui se joue. Un tunnel IPsec se négocie en deux temps. La phase 1 établit un canal sécurisé entre les deux pare-feu pour qu’ils s’authentifient mutuellement et conviennent des algorithmes : c’est la poignée de main. La phase 2 négocie ensuite les paramètres du trafic réellement chiffré qui passera dans le tunnel.

La conséquence pratique est fondamentale : les paramètres des deux extrémités doivent concorder exactement. Même clé pré-partagée, mêmes algorithmes de chiffrement et de hachage, mêmes réseaux déclarés. La quasi-totalité des tunnels qui « ne montent pas » s’expliquent par un désaccord sur un de ces paramètres. Garder cette symétrie en tête transforme le diagnostic en simple comparaison ligne à ligne.

Étape 2 — Lancer l’assistant VPN sur le premier site

Connectez-vous à l’interface du FortiGate du siège. Rendez-vous dans VPN → IPsec Wizard. L’assistant simplifie énormément la création en générant automatiquement les objets nécessaires. Choisissez le modèle Site to Site, indiquez qu’il s’agit d’un FortiGate distant (template « FortiGate »), et donnez un nom parlant au tunnel, par exemple VPN-Siege-Agence.

L’assistant demande ensuite l’adresse de l’extrémité distante (l’IP publique du WAN de l’agence) et l’interface sortante (le WAN du siège). Vous saisissez la clé pré-partagée — une chaîne secrète robuste que vous noterez précieusement, car elle devra être strictement identique à l’agence. Enfin, vous déclarez les sous-réseaux locaux et distants : 10.1.0.0/24 comme réseau local, 10.2.0.0/24 comme réseau distant.

VPN → IPsec Wizard
  Template type:    Site to Site
  Remote device:    FortiGate
  Name:             VPN-Siege-Agence
  Remote IP:        <IP publique WAN agence>
  Outgoing iface:   wan1
  Pre-shared key:   <clé secrète forte>
  Local subnet:     10.1.0.0/24
  Remote subnet:    10.2.0.0/24

En validant, FortiOS crée pour vous le tunnel IPsec (phases 1 et 2), les routes statiques vers le réseau distant, et une paire de politiques de pare-feu autorisant le trafic dans les deux sens. C’est tout l’intérêt de l’assistant : il évite les oublis qui font échouer une configuration manuelle.

Étape 3 — Configurer le second site en miroir

Sur le FortiGate de l’agence, on répète l’opération en inversant les rôles. C’est ici que la rigueur paie : chaque paramètre doit refléter celui du siège. La clé pré-partagée est identique, l’adresse distante devient l’IP publique du siège, le réseau local devient 10.2.0.0/24 et le réseau distant 10.1.0.0/24.

VPN → IPsec Wizard
  Template type:    Site to Site
  Remote device:    FortiGate
  Name:             VPN-Agence-Siege
  Remote IP:        <IP publique WAN siège>
  Outgoing iface:   wan1
  Pre-shared key:   <même clé secrète>
  Local subnet:     10.2.0.0/24
  Remote subnet:    10.1.0.0/24

Après validation, les deux extrémités ont une configuration symétrique. Le tunnel devrait commencer à négocier dès qu’un trafic cherche à le traverser, ou immédiatement si vous avez activé l’option « auto-negotiate ». La symétrie parfaite entre les deux écrans est la meilleure garantie de succès.

Étape 4 — Vérifier les routes et les politiques

L’assistant a créé les routes et les politiques, mais il est essentiel de comprendre ce qu’il a fait pour pouvoir l’ajuster. Dans Network → Static Routes, vous devez voir une route vers le réseau distant pointant vers l’interface du tunnel IPsec. Sans cette route, le pare-feu ne saurait pas qu’il faut emprunter le tunnel pour joindre l’autre site.

Dans Policy & Objects → Firewall Policy, repérez les deux politiques générées : l’une autorise le trafic du réseau local vers le réseau distant via le tunnel, l’autre le sens inverse. Par défaut, l’assistant autorise tout le trafic entre les deux réseaux. En production, on resserre ces politiques pour n’autoriser que les services nécessaires — par exemple le partage de fichiers vers un serveur précis — selon le principe du moindre privilège.

Étape 5 — Établir et tester le tunnel

Il est temps de vérifier que tout fonctionne. Dans VPN → IPsec Tunnels, sélectionnez votre tunnel : un indicateur d’état vous dit s’il est monté. S’il est inactif, générez du trafic pour le réveiller en envoyant un ping depuis un poste du siège vers une machine de l’agence.

# Depuis un poste du réseau du siège
ping 10.2.0.10

# Sur le FortiGate, en CLI, contrôler l'état du tunnel
get vpn ipsec tunnel summary

Si le ping aboutit, félicitations : le trafic traverse le tunnel chiffré. La commande CLI get vpn ipsec tunnel summary confirme l’état, le nombre de paquets entrants et sortants, et les sélecteurs négociés. Des compteurs qui augmentent dans les deux sens signent un tunnel pleinement fonctionnel. Côté interface graphique, l’état passe au vert et affiche le volume de données échangées.

Comprendre les paramètres de chiffrement

L’assistant masque volontairement la richesse des paramètres IPsec, mais il vaut la peine de savoir ce qui se cache derrière, car c’est là que se jouent à la fois la sécurité et la compatibilité. La phase 1 négocie trois choses : l’algorithme de chiffrement (par exemple AES-256), la fonction de hachage qui garantit l’intégrité (par exemple SHA-256), et le groupe Diffie-Hellman qui détermine la robustesse de l’échange de clés. Plus le groupe Diffie-Hellman est élevé, plus l’échange résiste à une tentative de cassage, au prix d’un léger surcoût de calcul.

La phase 2 reprend des choix similaires pour le trafic réel et y ajoute la notion de Perfect Forward Secrecy (PFS) : activée, elle garantit que la compromission d’une clé ne permet pas de déchiffrer les échanges passés, car chaque session dérive une clé indépendante. En entreprise, on active la PFS dès que les deux extrémités la supportent. Le point à retenir est qu’un tunnel entre deux FortiGate récents peut adopter des paramètres modernes sans difficulté, alors qu’un tunnel vers un vieil équipement tiers devra parfois se contenter d’algorithmes plus anciens — d’où l’importance de connaître ces réglages pour trouver le dénominateur commun le plus sûr.

Comprendre ces couches change aussi la façon de diagnostiquer. Quand la phase 1 échoue, le problème est dans l’authentification ou les algorithmes ; quand la phase 1 réussit mais que la phase 2 échoue, le problème est dans les sélecteurs de trafic ou les paramètres PFS. Cette grille de lecture, à elle seule, fait gagner un temps considérable face à un tunnel récalcitrant.

Surveiller et journaliser le tunnel

Un tunnel qui fonctionne aujourd’hui peut tomber demain pour mille raisons extérieures : changement d’adresse publique, coupure du fournisseur, maintenance de l’autre site. C’est pourquoi on ne se contente jamais d’établir un tunnel : on le surveille. FortiOS journalise les événements VPN dans Log & Report, où l’on retrouve les négociations réussies, les échecs d’authentification et les renégociations périodiques. Consulter ces journaux après une coupure révèle immédiatement si le tunnel est tombé à cause d’un problème d’authentification, d’un sélecteur ou d’une perte de connectivité pure.

Pour une infrastructure sérieuse, on va plus loin en exportant ces journaux vers un collecteur centralisé et en posant une alerte sur la chute d’un tunnel critique. L’objectif est de savoir qu’un lien inter-sites est tombé avant que les utilisateurs ne s’en plaignent. Coupler le tunnel à une supervision active — vérification périodique de la joignabilité d’une machine distante à travers le tunnel — transforme une interconnexion passive en service dont on maîtrise réellement la disponibilité.

🐞 Pièges fréquents

✅ Récapitulatif

Vous avez monté un tunnel IPsec site à site entre deux FortiGate avec l’assistant FortiOS, compris le rôle des phases 1 et 2, configuré les deux extrémités en miroir, vérifié routes et politiques, puis testé la connectivité chiffrée. Vous savez désormais relier deux réseaux distants de façon sûre et, surtout, diagnostiquer méthodiquement un tunnel récalcitrant en comparant les paramètres des deux côtés. C’est une compétence directement transposable à n’importe quel équipement supportant IPsec.

🧾 Aide-mémoire

💪 À vous de jouer

Resserrez les politiques générées par l’assistant pour n’autoriser, depuis le siège, que l’accès à un unique serveur de l’agence (10.2.0.10) sur le seul port de partage de fichiers, et bloquez le reste.

Tutoriels de la même série

• MikroTik : VPN WireGuard site à site — la même interconnexion avec un protocole plus léger.
• pfSense : accès distant avec OpenVPN — connecter des utilisateurs nomades plutôt que des sites.

Pour aller plus loin

• 🔝 Retour au guide principal : Réseau d’entreprise : MikroTik, pfSense, OPNsense, FortiGate
• Documentation officielle : docs.fortinet.com, section « IPsec VPN » de FortiOS 7.6.
• Tutoriel suivant suggéré : WireGuard sur MikroTik, pour comparer les approches VPN.

FAQ

IPsec ou WireGuard pour relier deux sites ?
IPsec est le standard universel, supporté par tout équipement professionnel, idéal en environnement hétérogène ou réglementé. WireGuard est plus simple et souvent plus rapide, mais suppose que les deux extrémités le supportent. Pour relier deux FortiGate à du matériel tiers, IPsec reste le choix sûr.

Que faire si un site a une adresse IP dynamique ?
On configure ce côté en mode « dial-up » et on utilise un nom DNS dynamique pour le joindre, ou on s’assure qu’au moins l’extrémité initiatrice a une adresse stable. Le tunnel s’établit alors depuis le site à IP variable vers le site à IP fixe.

La clé pré-partagée est-elle assez sûre ?
Une clé pré-partagée longue et aléatoire offre un bon niveau pour la plupart des usages. Pour des exigences plus élevées, FortiGate supporte l’authentification par certificats, plus robuste à grande échelle.

Pourquoi mon tunnel monte puis retombe ?
Souvent un désaccord sur les durées de vie des associations de sécurité entre les deux extrémités, ou une IP qui change d’un côté. Alignez les durées de vie de phase 1 et 2 et stabilisez l’adressage public.

Mots-clés : FortiGate, FortiOS 7.6, VPN IPsec site à site, IPsec Wizard, phase 1 phase 2, tunnel chiffré, réseau multi-sites, clé pré-partagée.