CAS CLIENT : Refonte du maillage VPN IPsec multi-sites
IPsec multi-sites · FortiGate · Migration datacenter · Wi-Fi / RADIUS · BGP & BFD (réflexion)
Contexte anonymisé : une organisation multi-sites (4 sites distants) est interconnectée en IPsec vers un site historique hébergeant l'ensemble de l'infrastructure serveur, le stockage et l'authentification Wi-Fi. Suite à une reconstruction de l'infrastructure côté datacenter, le maillage VPN doit évoluer pour couvrir un second hub, sans interrompre les services existants sur les sites distants.
Schéma avant migration
4 sites distants interconnectés en IPsec vers le site historique, hébergeant infrastructure, stockage et Wi-Fi.
Chaque site distant dispose d'un tunnel IPsec unique vers le FortiGate du site historique. L'ensemble du trafic (applicatif, stockage, authentification Wi-Fi/RADIUS) transite par ce tunnel unique.
Contraintes du projet
- L'infrastructure serveur et le stockage ont été reconstruits/migrés côté datacenter (nouveau subnet réseau), y compris le serveur RADIUS, qui n'est donc plus colocalisé avec le contrôleur Wi-Fi.
- Les bornes Wi-Fi des 4 sites distants doivent conserver leurs SSID existants, rattachés au FortiGate du site historique, pour éviter toute rupture de service ou re-provisionnement des équipements radio.
- Conséquence directe : chaque authentification Wi-Fi remonte d'abord vers le site historique (contrôleur), qui doit ensuite relayer la requête RADIUS vers le datacenter. Un tunnel IPsec permanent entre les deux hubs existe donc déjà, dédié à ce relais d'authentification.
- Le trafic applicatif et stockage doit désormais rejoindre le datacenter directement depuis chaque site distant.
Actions menées
- Cartographie des flux par site : séparation du trafic Wi-Fi/SSID (vers le site historique, avec relais RADIUS vers le datacenter) et du trafic applicatif/stockage (directement vers le datacenter).
- Déploiement de nouveaux tunnels IPsec site-à-site entre chaque site distant et le FortiGate du datacenter.
- Migration du subnet réseau serveur vers le datacenter, avec réadressage et ajustement des tables de routage.
- Refonte des politiques de pare-feu et du routage sur chaque site pour distinguer les flux selon leur destination (site historique vs datacenter), en conservant deux tunnels actifs par site.
- Tests de bascule et validation de la continuité de service Wi-Fi pendant toute la phase de migration.
Architecture réseau par site
Chaque site distant combine deux catégories de réseaux : un sous-réseau local unique (propre à ce site, sans vocation à transiter vers les hubs) et un VLAN de services partagés, dont le trafic est systématiquement destiné aux ressources centralisées : authentification RADIUS/LDAP, accès aux lecteurs réseau, applications web auto-hébergées, et la solution SLNX de gestion des impressions. Ce sont ces flux de services partagés qui empruntent les tunnels vers le site historique et le datacenter, selon la localisation de la ressource visée.
Chaque site dispose également de deux liens internet (opérateur primaire + secours), chacun avec ses propres tunnels IPsec vers les deux hubs — soit jusqu'à quatre chemins possibles par site pour atteindre une même ressource distante.
Schéma après migration
Chaque site dispose de deux tunnels fonctionnels (Wi-Fi/SSID vers le site historique, services vers le datacenter), chacun dupliqué sur les deux liens WAN du site.
Résultat
Les 4 sites distants disposent chacun de deux tunnels IPsec actifs et fonctionnellement séparés. La migration de l'infrastructure et du stockage vers le datacenter s'est faite sans interruption de service pour les utilisateurs, le Wi-Fi restant totalement transparent pendant toute l'opération.
Réflexion complémentaire : BGP sur les tunnels IPsec ?
Piste à l'étude — non mise en œuvre actuellement. Aujourd'hui, l'approche SD-WAN en place nécessite deux liens internet par FortiGate et la déclaration explicite, pour chaque destination, de l'interface VPN à emprunter : chaque route est une décision statique maintenue manuellement, y compris pour la logique de bascule en cas de coupure.
Une évolution envisageable serait de passer les tunnels IPsec en mode route-based avec du peering BGP par site, chaque site annonçant son subnet local vers les deux hubs. La différence fondamentale avec l'existant : la propagation des routes devient automatique. Il reste une configuration initiale par tunnel (interface de tunnel, voisin BGP, ce qui est annoncé), mais un nouveau subnet ou un nouveau site n'exige plus de retoucher la table de routage de chaque équipement distant — la route se propage seule. En cas de coupure d'un tunnel, la session BGP tombe et la route est automatiquement retirée, sans intervention manuelle : c'est le même mécanisme que celui utilisé par AWS ou Azure pour leurs VPN redondants.
Piste à l'étude : en cas de coupure du lien direct site → site historique, le trafic emprunte automatiquement le chemin de secours via le datacenter, en réutilisant le tunnel IPsec déjà existant pour le relais RADIUS.
Point clé de cette piste : le lien inter-hub nécessaire au failover existe déjà, puisque le tunnel Site historique ↔ Datacenter est monté en permanence pour le relais des authentifications RADIUS. Il n'y a donc pas de nouvelle infrastructure réseau à créer — seulement une session BGP à établir sur ce lien existant pour qu'il serve aussi de transit de secours entre les deux hubs. En comportement natif eBGP, une route apprise d'un voisin est réannoncée aux autres voisins sans configuration supplémentaire ; un site qui perd son tunnel direct vers le site historique atteindrait donc celui-ci via le datacenter, sans intervention manuelle.
Deux points de vigilance à creuser avant d'aller plus loin sur cette piste : ce tunnel porte déjà du trafic RADIUS sensible en temps normal, donc son dimensionnement devrait être revu s'il doit aussi absorber du trafic de secours en cas de bascule ; et la préférence de chemin par défaut de BGP (AS-path le plus court) fait que le trajet direct reste privilégié tant qu'il est disponible — le transit par le datacenter n'intervient qu'en cas de coupure réelle.
Vérification de faisabilité avec le double lien WAN par site
Le nombre de préfixes à annoncer (sous-réseau local + VLAN services par site) reste trivial pour BGP, même multiplié par 4 sites — aucun problème de passage à l'échelle à ce niveau.
Le vrai changement porte sur le nombre de sessions BGP par site : avec deux liens WAN et deux hubs, un site peut avoir jusqu'à quatre voisins BGP (WAN1→site historique, WAN1→datacenter, WAN2→site historique, WAN2→datacenter). C'est supporté par FortiGate, mais cela impose de hiérarchiser explicitement les quatre chemins avec de la local-preference et de l'AS-path prepend par route-map, pour que le trafic emprunte en priorité le lien direct sur l'opérateur primaire, puis bascule dans un ordre maîtrisé plutôt qu'arbitraire.
À cette échelle de complexité, l'ADVPN de Fortinet (Auto Discovery VPN) serait une piste native à évaluer en complément : il établit les tunnels à la demande plutôt que de figer une topologie complète, et s'appuie justement sur BGP pour la propagation des routes — verdict : la faisabilité technique est confirmée, mais l'effort de conception (hiérarchisation des chemins, dimensionnement du lien de transit RADIUS) est proportionnel au nombre de liens redondants ajoutés.
Pour une topologie à 4 sites et 2 hubs, le SD-WAN natif FortiGate avec health-check SLA reste toutefois une alternative plus simple à exploiter au quotidien. BGP devient réellement pertinent si le nombre de sites croît significativement, si un traffic engineering fin par préfixe est nécessaire, ou si l'environnement s'ouvre à du multi-vendeur. Dans tous les cas, coupler BGP avec BFD (Bidirectional Forwarding Detection) est recommandé pour obtenir une détection de lien mort rapide, les timers BGP par défaut étant trop lents pour un failover réactif. À noter aussi que le double lien internet par site (protection contre une coupure FAI) et le double tunnel BGP vers deux hubs (protection contre l'indisponibilité d'un hub) couvrent deux risques différents et restent complémentaires plutôt que substituables.
Contexte anonymisé : une organisation multi-sites (4 sites distants) est interconnectée en IPsec vers un site historique hébergeant l'ensemble de l'infrastructure serveur, le stockage et l'authentification Wi-Fi. Suite à une reconstruction de l'infrastructure côté datacenter, le maillage VPN doit évoluer pour couvrir un second hub, sans interrompre les services existants sur les sites distants.
Schéma avant migration
4 sites distants interconnectés en IPsec vers le site historique, hébergeant infrastructure, stockage et Wi-Fi.
Chaque site distant dispose d'un tunnel IPsec unique vers le FortiGate du site historique. L'ensemble du trafic (applicatif, stockage, authentification Wi-Fi/RADIUS) transite par ce tunnel unique.
Contraintes du projet
- L'infrastructure serveur et le stockage ont été reconstruits/migrés côté datacenter (nouveau subnet réseau), y compris le serveur RADIUS, qui n'est donc plus colocalisé avec le contrôleur Wi-Fi.
- Les bornes Wi-Fi des 4 sites distants doivent conserver leurs SSID existants, rattachés au FortiGate du site historique, pour éviter toute rupture de service ou re-provisionnement des équipements radio.
- Conséquence directe : chaque authentification Wi-Fi remonte d'abord vers le site historique (contrôleur), qui doit ensuite relayer la requête RADIUS vers le datacenter. Un tunnel IPsec permanent entre les deux hubs existe donc déjà, dédié à ce relais d'authentification.
- Le trafic applicatif et stockage doit désormais rejoindre le datacenter directement depuis chaque site distant.
Actions menées
- Cartographie des flux par site : séparation du trafic Wi-Fi/SSID (vers le site historique, avec relais RADIUS vers le datacenter) et du trafic applicatif/stockage (directement vers le datacenter).
- Déploiement de nouveaux tunnels IPsec site-à-site entre chaque site distant et le FortiGate du datacenter.
- Migration du subnet réseau serveur vers le datacenter, avec réadressage et ajustement des tables de routage.
- Refonte des politiques de pare-feu et du routage sur chaque site pour distinguer les flux selon leur destination (site historique vs datacenter), en conservant deux tunnels actifs par site.
- Tests de bascule et validation de la continuité de service Wi-Fi pendant toute la phase de migration.
Architecture réseau par site
Chaque site distant combine deux catégories de réseaux : un sous-réseau local unique (propre à ce site, sans vocation à transiter vers les hubs) et un VLAN de services partagés, dont le trafic est systématiquement destiné aux ressources centralisées : authentification RADIUS/LDAP, accès aux lecteurs réseau, applications web auto-hébergées, et la solution SLNX de gestion des impressions. Ce sont ces flux de services partagés qui empruntent les tunnels vers le site historique et le datacenter, selon la localisation de la ressource visée.
Chaque site dispose également de deux liens internet (opérateur primaire + secours), chacun avec ses propres tunnels IPsec vers les deux hubs — soit jusqu'à quatre chemins possibles par site pour atteindre une même ressource distante.
Schéma après migration
Chaque site dispose de deux tunnels fonctionnels (Wi-Fi/SSID vers le site historique, services vers le datacenter), chacun dupliqué sur les deux liens WAN du site.
Résultat
Les 4 sites distants disposent chacun de deux tunnels IPsec actifs et fonctionnellement séparés. La migration de l'infrastructure et du stockage vers le datacenter s'est faite sans interruption de service pour les utilisateurs, le Wi-Fi restant totalement transparent pendant toute l'opération.
Réflexion complémentaire : BGP sur les tunnels IPsec ?
Piste à l'étude — non mise en œuvre actuellement. Aujourd'hui, l'approche SD-WAN en place nécessite deux liens internet par FortiGate et la déclaration explicite, pour chaque destination, de l'interface VPN à emprunter : chaque route est une décision statique maintenue manuellement, y compris pour la logique de bascule en cas de coupure.
Une évolution envisageable serait de passer les tunnels IPsec en mode route-based avec du peering BGP par site, chaque site annonçant son subnet local vers les deux hubs. La différence fondamentale avec l'existant : la propagation des routes devient automatique. Il reste une configuration initiale par tunnel (interface de tunnel, voisin BGP, ce qui est annoncé), mais un nouveau subnet ou un nouveau site n'exige plus de retoucher la table de routage de chaque équipement distant — la route se propage seule. En cas de coupure d'un tunnel, la session BGP tombe et la route est automatiquement retirée, sans intervention manuelle : c'est le même mécanisme que celui utilisé par AWS ou Azure pour leurs VPN redondants.
Piste à l'étude : en cas de coupure du lien direct site → site historique, le trafic emprunte automatiquement le chemin de secours via le datacenter, en réutilisant le tunnel IPsec déjà existant pour le relais RADIUS.
Point clé de cette piste : le lien inter-hub nécessaire au failover existe déjà, puisque le tunnel Site historique ↔ Datacenter est monté en permanence pour le relais des authentifications RADIUS. Il n'y a donc pas de nouvelle infrastructure réseau à créer — seulement une session BGP à établir sur ce lien existant pour qu'il serve aussi de transit de secours entre les deux hubs. En comportement natif eBGP, une route apprise d'un voisin est réannoncée aux autres voisins sans configuration supplémentaire ; un site qui perd son tunnel direct vers le site historique atteindrait donc celui-ci via le datacenter, sans intervention manuelle.
Deux points de vigilance à creuser avant d'aller plus loin sur cette piste : ce tunnel porte déjà du trafic RADIUS sensible en temps normal, donc son dimensionnement devrait être revu s'il doit aussi absorber du trafic de secours en cas de bascule ; et la préférence de chemin par défaut de BGP (AS-path le plus court) fait que le trajet direct reste privilégié tant qu'il est disponible — le transit par le datacenter n'intervient qu'en cas de coupure réelle.
Vérification de faisabilité avec le double lien WAN par site
Le nombre de préfixes à annoncer (sous-réseau local + VLAN services par site) reste trivial pour BGP, même multiplié par 4 sites — aucun problème de passage à l'échelle à ce niveau.
Le vrai changement porte sur le nombre de sessions BGP par site : avec deux liens WAN et deux hubs, un site peut avoir jusqu'à quatre voisins BGP (WAN1→site historique, WAN1→datacenter, WAN2→site historique, WAN2→datacenter). C'est supporté par FortiGate, mais cela impose de hiérarchiser explicitement les quatre chemins avec de la local-preference et de l'AS-path prepend par route-map, pour que le trafic emprunte en priorité le lien direct sur l'opérateur primaire, puis bascule dans un ordre maîtrisé plutôt qu'arbitraire.
À cette échelle de complexité, l'ADVPN de Fortinet (Auto Discovery VPN) serait une piste native à évaluer en complément : il établit les tunnels à la demande plutôt que de figer une topologie complète, et s'appuie justement sur BGP pour la propagation des routes — verdict : la faisabilité technique est confirmée, mais l'effort de conception (hiérarchisation des chemins, dimensionnement du lien de transit RADIUS) est proportionnel au nombre de liens redondants ajoutés.
Pour une topologie à 4 sites et 2 hubs, le SD-WAN natif FortiGate avec health-check SLA reste toutefois une alternative plus simple à exploiter au quotidien. BGP devient réellement pertinent si le nombre de sites croît significativement, si un traffic engineering fin par préfixe est nécessaire, ou si l'environnement s'ouvre à du multi-vendeur. Dans tous les cas, coupler BGP avec BFD (Bidirectional Forwarding Detection) est recommandé pour obtenir une détection de lien mort rapide, les timers BGP par défaut étant trop lents pour un failover réactif. À noter aussi que le double lien internet par site (protection contre une coupure FAI) et le double tunnel BGP vers deux hubs (protection contre l'indisponibilité d'un hub) couvrent deux risques différents et restent complémentaires plutôt que substituables.