Migrer le pare-feu de production en une heure de coupure
Le pare-feu de toute l'entreprise, remplacé de bout en bout : préparer le nouveau sans jamais gêner le réseau qui travaille, puis basculer entre 13 h et 14 h, parce que le travail devait reprendre après la pause.
En bref
La licence FortiGate coûtait trop cher pour une PME d'une vingtaine de personnes. Or ce pare-feu portait tout le trafic de l'entreprise, sur deux accès Internet.
J'ai préparé le nouveau pare-feu, un boîtier à quatre ports, sur un LAN privé sans conflit avec le réseau en service, repris interfaces, règles et NAT, puis basculé le jour J.
Bascule tenue dans l'heure du déjeuner, de 13 h à 14 h, et travail repris à l'heure. Un pare-feu plus simple à administrer, pour un coût bien plus faible.
Contexte
Toute l'entreprise sortait sur Internet par un pare-feu FortiGate, relié à deux opérateurs. Sa licence coûtait trop cher pour une PME d'une vingtaine de personnes. Il fallait donc le remplacer, sans perdre ce qu'il faisait chaque jour : filtrer, traduire les adresses, publier les services.
Deux contraintes. Le réseau était en service : rien de ce que je préparais ne devait entrer en conflit avec lui. Et la bascule, elle, coupe forcément tout le monde : il fallait qu'elle tienne dans un créneau court.
Ce que j'ai fait
- Choisir le remplaçantUn pare-feu open source, pfSense, sans licence à renouveler, qui couvre ce dont la PME avait besoin : filtrage, NAT, deux accès Internet. Installé sur un boîtier dédié à quatre ports.
- Répartir les portsUn port par opérateur, un pour le réseau interne, et un quatrième laissé libre : il a accueilli en 2026 la DMZ du portail B2B.
- Préparer à l'écart du réseau qui travailleJ'ai créé sur le nouveau pare-feu un LAN privé, avec un adressage différent de celui de l'entreprise. Je pouvais tout configurer et tout tester sans qu'aucune adresse, aucune passerelle, n'entre en conflit avec le réseau en service.
- Reprendre la configurationInterfaces, les deux accès Internet, règles de filtrage, NAT et redirections de ports. Ne sont pas passés sur pfSense : le DNS et le DHCP, qui restent sur les serveurs internes, et le VPN, traité à part.
- Basculer le jour JÀ 13 h, le LAN privé prend l'adressage de production et la place de l'ancienne passerelle, les câbles passent de l'ancien au nouveau pare-feu, puis je vérifie que tout fonctionne. À 14 h, le travail reprend.
Voir les détails techniques
| Fonction | Avant | Après |
|---|---|---|
| Filtrage et NAT | FortiGate | pfSense |
| Deux accès Internet | FortiGate | pfSense, un port par opérateur |
| DNS et DHCP | Serveurs internes | Inchangés : serveurs internes |
| VPN des salariés | FortiGate | Traité à part, hors de la bascule |
| DMZ | — | Quatrième port, utilisé en 2026 pour le portail B2B |
Pourquoi un LAN privé plutôt que l'adressage final. Brancher un second équipement qui revendique l'adresse de la passerelle sur un réseau en service, c'est créer un conflit : une partie des postes enverrait son trafic au mauvais endroit. Préparer sur un autre adressage permet de tout tester à l'avance, et de ne changer qu'un seul réglage le jour J.
Pourquoi garder le DNS et le DHCP sur les serveurs. Dans un domaine Active Directory, les postes doivent interroger les contrôleurs de domaine pour trouver l'annuaire. Déplacer ces rôles sur le pare-feu aurait ajouté un risque à la bascule, sans rien apporter.
Résultats
La bascule a tenu dans le créneau : à 14 h, les salariés reprenaient le travail sur le nouveau pare-feu, avec leurs deux accès Internet, leurs règles et leurs redirections. Le gain se lit au quotidien : une console plus simple, qui fait l'essentiel, et un coût bien plus faible qu'un abonnement à renouveler.
Ce que le projet ne mesure pas : je n'ai pas chiffré l'économie réalisée, ni chronométré chaque étape de la bascule.
Ce que j'améliorerais
- J'écrirais un plan de retour arrière : l'ancien pare-feu prêt à être rebranché, et l'heure limite à laquelle on le rebranche si un flux critique ne passe pas.
- Je ferais l'inventaire des flux avant de partir : chaque règle et chaque redirection, avec son propriétaire, pour supprimer ce qui ne sert plus au lieu de tout reprendre.
- Je sauvegarderais la configuration du pare-feu après chaque modification, horodatée et hors du boîtier, pour pouvoir reconstruire le pare-feu en quelques minutes.
La suite : ce même pare-feu a ensuite porté l'accès distant, avant que je sorte le VPN du pare-feu vers WireGuard, puis la DMZ du portail B2B, en 2026.