La fin du support de FortiOS 7.2, prévue pour le 30 septembre 2026, oblige les administrateurs qui utilisent encore cette version à planifier leur prochaine étape. La mise à jour vers FortiOS 7.4 constitue une transition raisonnable dans certains environnements, notamment lorsque la dépendance à SSL VPN est encore présente. Toutefois, cette migration constitue également une opportunité pour réévaluer la pertinence de continuer avec FortiGate ou d’envisager des alternatives logicielles et open source telles qu’OPNsense, pfSense, OpenWrt, IPsec, OpenVPN ou WireGuard.
Les clés pour migrer de FortiOS 7.2 en 20 secondes
- FortiOS 7.2 atteindra sa fin de vie (EOS) le 30/09/2026.
- FortiOS 7.4 peut servir de transition, selon le modèle et la configuration.
- FortiOS 7.6.3 supprime le mode Tunnel SSL VPN et Fortinet recommande de migrer vers IPsec.
- Avant toute mise à jour, il faut vérifier le Security Fabric, la compatibilité et suivre la documentation officielle.
- C’est aussi le bon moment pour évaluer des pare-feux logiciels ou des solutions open source.
Il ne faut pas réduire cette migration à une simple mise à jour du firmware. Un FortiGate regroupe souvent un pare-feu, NAT, VPN, segmentation, routage, authentification et, en fonction des licences, des fonctions de sécurité avancées.
Il est donc essentiel de faire un inventaire précis de ce que fait réellement l’appareil avant de choisir la version à installer. Deux décisions ne sont pas forcément liées : que faire de FortiOS 7.2 et quelle architecture de pare-feu et d’accès à distance la gouvernance souhaite maintenir dans les années à venir.
Première décision : utiliser 7.4 comme étape intermédiaire ou évoluer directement vers 7.6
Pour un FortiGate utilisant encore le mode Tunnel SSL VPN, la mise à jour directe vers une version récente de FortiOS 7.6 peut entraîner un changement notable.
Fortinet indique que le mode Tunnel SSL VPN n’est plus supporté à partir de FortiOS 7.6.3. Après une mise à jour depuis une version antérieure, la configuration de ce mode n’est pas conservée et cette fonctionnalité cesse de fonctionner.
La recommandation est de migrer d’abord vers une autre solution d’accès à distance, comme IPsec VPN.
Cela permet, selon le matériel et la version, une migration progressive :
7.2 → 7.4 → stabiliser → migrer SSL VPN → IPsec → 7.6.x
L’intérêt opérationnel est évident : séparer la mise à jour du pare-feu de celle de l’accès à distance et diagnostiquer plus facilement les éventuels dysfonctionnements après chaque étape.
Mais 7.4 n’est pas une étape intermédiaire universelle.
La disponibilité de SSL VPN dépend aussi du modèle. Par exemple, Fortinet indique que les FortiGate 90G/91G et versions antérieures de la série G ont des restrictions supplémentaires. Sur un 90G/91G, cette fonction peut exister avec FortiOS 7.4.7 et disparaître en 7.4.8.
Les modèles 70G et variantes peuvent utiliser cette fonction sous FortiOS 7.2, mais elle n’est plus supportée à partir de FortiOS 7.4.8.
Il y a aussi des limitations pour certains appareils de la famille F lors du passage à FortiOS 7.6.
Dès lors, la règle simple serait : ne pas choisir la version en premier, puis vérifier le matériel. Il faut partir du modèle précis, des fonctions utilisées et de la compatibilité avec les versions supportées.
Checklist avant d’actualiser FortiOS 7.2
| Vérification | Ce qu’il faut examiner |
|---|---|
| FortiGate | Modèle et état du matériel |
| Firmware | Version exacte installée |
| Chemin de mise à jour | Séquence officielle jusqu’à la cible |
| SSL VPN | Mode Tunnel, Web et utilisateurs |
| IPsec | Tunnels existants et accès à distance |
| FortiClient | Versions déployées |
| Security Fabric | FortiAP, FortiSwitch et autres composants |
| Gestion | FortiManager et FortiAnalyzer |
| NAT et routage | Hairpin NAT, boucle locale et routes spéciales |
| Notes de version | Modifications et problèmes connus |
| Sauvegarde | Configuration et procédure de restauration |
| Tests | Services à valider après redémarrage |
Il existe aussi des changements moins visibles susceptibles de provoquer des problèmes.
Par exemple, dans FortiOS 7.4.10, allow-traffic-redirect et ipv6-allow-traffic-redirect sont désactivés lors de certaines mises à jour. Cela peut impacter les configurations Hairpin NAT, NAT Loopback et le trafic entrant/sortant sur la même interface.
De plus, il arrive que le SSL VPN disparaisse apparemment après une mise à jour vers 7.4, mais qu’il ne soit en réalité que caché dans l’interface graphique. Depuis FortiOS 7.4.1, Fortinet a modifié cette visibilité par défaut.
Tout cela renforce la nécessité de lire attentivement les Release Notes de la version précise à installer, et pas uniquement les nouveautés générales de FortiOS 7.4 ou 7.6.
Deuxième décision : ce n’est peut-être pas seulement la version de FortiOS qui pose problème
Une refonte importante peut aussi conduire à revoir l’architecture.
FortiGate est une appliance de sécurité intégrée : matériel, FortiOS, services de sécurité, support et composants du Security Fabric forment une plateforme conçue pour fonctionner de concert.
Cela offre des avantages, notamment pour les organisations utilisant l’inspection avancée, la gestion centralisée, le SD-WAN, la protection contre les menaces, etc.
Mais toutes les entreprises n’en ont pas besoin.
Un pare-feu principalement dédié à NAT, VLAN, routage, règles L3/L4, IPsec et accès à distance offre plus de souplesse.
Des alternatives logicielles peuvent fonctionner sur du matériel standard, des machines virtuelles ou certains appliances spécifiques.
Parmi ces options, on trouve OPNsense, pfSense et OpenWrt, qui ne sont pas des produits interchangeables ni des remplacements automatiques de toutes les fonctions de FortiGate.
OPNsense est particulièrement adapté pour les réseaux d’entreprise ou les labs exigeant un pare-feu basé sur FreeBSD avec gestion web, routage, VPN et haute disponibilité.
pfSense couvre un champ similaire, avec VLAN, NAT, multi-WAN, haute disponibilité et VPN via IPsec, OpenVPN ou WireGuard, déployable aussi en virtualisation, notamment avec Proxmox VE.
OpenWrt se concentre davantage sur l’univers des routeurs et appareils réseau, mais peut s’intégrer à des architectures plus complexes.
La comparaison doit se faire en fonction des fonctionnalités et besoins, et pas uniquement par le coût des licences.
| Besoin | FortiGate | OPNsense/pfSense | OpenWrt |
|---|---|---|---|
| Firewall et NAT | Oui | Oui | Oui |
| VLAN | Oui | Oui | Oui |
| IPsec | Oui | Oui | Disponible |
| OpenVPN | Selon architecture | Oui | Disponible |
| WireGuard | Selon plateforme/utilisation | Oui | Disponible |
| Matériel dédié | Oui | Optionnel | Optionnel |
| Virtualisation | FortiGate-VM | Oui | Oui |
| Environnement sécurisé intégré | Étendu | Modulaire/différent | Plus modulaire |
| Gestion centralisée d’entreprise | Fortinet | Variable selon solution/édition | Plus d’intégration requise |
| Liberté matérielle | Limitée à la gamme commerciale | Élevée | Élevée |
Il ne faut pas limiter la réflexion à « logiciel libre contre firewall commercial ».
Ce qui compte, c’est qui intègre, teste, met à jour et assure la maintenance en cas de panne.
Un pare-feu open source peut réduire la dépendance à un fournisseur, utiliser du matériel x86 maison, mais quelqu’un doit prendre en charge la sélection matérielle, la redondance, les bonnes pratiques de mise à jour, la surveillance, la sauvegarde, le support et la gestion des incidents.
L’open source ne signifie pas une infrastructure sans coûts.
IPsec, OpenVPN ou WireGuard : autres points à étudier
La fin du mode Tunnel SSL VPN offre aussi une occasion de dissocier l’accès à distance de la responsabilité du fabricant du pare-feu.
Fortinet recommande IPsec pour ses clients, ce qui est souvent pertinent dans un contexte d’entreprise. Son principal avantage est l’interopérabilité : IPsec est compatible avec une grande variété de pare-feux, routeurs et systèmes d’exploitation.
PfSense, entre autres, conseille souvent IPsec pour les connexions multi-fournisseurs, précisant qu’elle évite d’être dépendant d’une solution unique de VPN ou pare-feu.
Il existe par ailleurs deux autres options open sources particulièrement populaires.
OpenVPN est utilisé depuis longtemps pour l’accès à distance et interconnecter des réseaux. Il gère les certificats, l’authentification des utilisateurs, et dispose de clients pour de nombreux OS. Sur pfSense, il peut être combiné avec des règles spécifiques, RADIUS et gestion de certificats.
WireGuard privilégie un design simple et léger. Son fonctionnement repose sur des paires de clés et il offre de bonnes performances. Cependant, cette simplicité implique moins de fonctionnalités de gestion des identités des utilisateurs.
Par exemple, Netgate indique que WireGuard ne fournit pas d’authentification utilisateur en lui-même, ce qui peut compliquer la gestion quand le nombre de pairs augmente considérablement.
Voici une synthèse des options :
| Technologie | Points forts | À étudier |
|---|---|---|
| IPsec/IKEv2 | Interopérabilité et compatibilité avec les clients d’entreprise | Configuration plus complexe |
| OpenVPN | Maturation, gestion des certificats et authentification | Require un client dédié |
| WireGuard | Simplicité et performance | Gestion des identités externe |
| SSL VPN propriétaire | Intégration avec le fournisseur | Dépendance au produit et à son cycle de vie |
Il n’existe pas d’option universelle adaptée à toutes les situations.
Pour une grande entreprise avec des centaines ou des milliers d’employés, un annuaire d’entreprise, une authentification à plusieurs facteurs, des politiques par utilisateur et des appareils gérés, remplacer FortiClient par WireGuard déployé manuellement sur chaque poste est peu probable d’être une migration équivalente.
Dans une petite structure avec une vingtaine d’administrateurs, des serveurs Linux et des besoins d’accès très spécifiques, WireGuard peut être beaucoup plus attrayant.
Pour des connexions site-à-site entre fournisseurs différents, IPsec reste souvent une option particulièrement raisonnable.
Ce changement peut aussi servir à questionner si tous les utilisateurs ont vraiment besoin d’un VPN donnant accès à un réseau complet. Pour certaines applications internes, il peut être plus pertinent d’appliquer une stratégie d’accès par application ou de mise en œuvre du Zero Trust Network Access (ZTNA), en réduisant le périmètre accessible après authentification.
L’objectif n’est pas de migrer parce que la technologie VPN devient obsolète, mais de réévaluer ce que chaque utilisateur doit pouvoir faire et avec quels dispositifs.
Une stratégie de migration possible
Pour une entreprise disposant de FortiOS 7.2 et SSL VPN, au moins trois scénarios raisonnables existent.
Poursuivre avec Fortinet consiste à suivre la voie de l’upgrade conforme, utiliser 7.4 comme étape intermédiaire si besoin, migrer SSL VPN vers IPsec ou leur alternative adaptée, puis évoluer vers une branche supportée ultérieurement.
Maintenir FortiGate tout en séparant la VPN permet de garder le pare-feu en place pendant que l’accès distant repose sur une plateforme indépendante. Cela permet de réduire les dépendances pour la prochaine mise à jour du firewall.
Enfin, l’option consiste à évaluer la substitution du firewall par une solution logicielle comme OPNsense ou pfSense, si l’essentiel de l’usage concerne le pare-feu, le routage, VLAN, NAT et VPN.
Cette dernière doit faire l’objet d’un proof of concept sérieux. Il ne suffit pas d’importer quelques règles, il faut tester la performance réelle, les interfaces, la haute disponibilité, le routage dynamique, la gestion VPN, l’authentification, la journalisation, la surveillance, la détection d’intrusions, les mises à jour et la récupération.
Il faut aussi estimer le coût opérationnel : une licence abandonnée peut se traduire par des heures de travail supplémentaire.
L’EOS de FortiOS 7.2 est une étape technique, mais aussi une occasion d’un regard plus large. Certaines entreprises préféreront simplement mettre à jour leur FortiGate. D’autres envisageront de dissocier VPN et pare-feu. Et celles qui exploitent une partie limitée des capacités de Fortinet auront tout intérêt à tester jusqu’où peuvent aller aujourd’hui les alternatives open source avant d’investir dans la nouvelle génération d’appliances.
Questions fréquentes
Faut-il obligatoirement passer de FortiOS 7.2 à FortiOS 7.4 ?
Ce n’est pas une obligation. Le choix de la route dépend du modèle de FortiGate, de la version initiale, des fonctions utilisées et du futur. Fortinet propose un outil, la Upgrade Path Tool, pour identifier la séquence compatible.
Quelles alternatives à SSL VPN de Fortinet existe-t-il ?
IPsec/IKEv2 est la solution recommandée par Fortinet dans certains scénarios. Les technologies open source comme OpenVPN ou WireGuard offrent aussi des solutions, avec des différences en termes d’authentification, déploiement et gestion.
OPNsense ou pfSense peuvent-ils remplacer un FortiGate ?
Cela est possible dans certains cas, mais il n’y a pas d’équivalence automatique. Il faut comparer pare-feu, VPN, routage, haute disponibilité, inspection, gestion, support, performance et sécurité pratiquée par l’organisation.
WireGuard est-il supérieur à IPsec pour remplacer SSL VPN ?
Cela dépend. WireGuard est simple et performant mais ne propose pas nativement d’authentification utilisateur, contrairement à IPsec. IPsec offre une interopérabilité plus large, notamment dans le cadre d’infrastructures d’entreprise ; WireGuard privilégie la simplicité et la rapidité, mais peut nécessiter une gestion externe des identités.
Source : Open Security