Retour d’expérience DYB sur la haute disponibilité WAN avec pfSense, WireGuard et OSPF
Dans les architectures réseau professionnelles multi-sites, la haute disponibilité est devenue un prérequis :
double lien Internet (FTTO + FTTH), tunnels inter-sites, routage dynamique, continuité de service.
Sur le papier, les briques sont connues :
- pfSense pour la sécurité et le routage,
- WireGuard pour les interconnexions chiffrées,
- OSPF pour le routage dynamique entre sites.
Pourtant, dans la réalité terrain, une panne opérateur ne provoque pas toujours la bascule attendue, même avec une architecture apparemment “propre”.
Chez DYB, nous avons rencontré ce cas très concret lors d’une panne FTTO sur un site client multi-sites.
Ce retour d’expérience illustre pourquoi OSPF ne réagit pas toujours à une dégradation de lien, et comment corriger proprement ce comportement dans un contexte professionnel.
🎯 Le besoin métier initial
Le besoin côté client était clair et parfaitement légitime :
- Plusieurs sites interconnectés
- Deux accès Internet par site (FTTO prioritaire + FTTH de secours)
- Tunnels WireGuard redondés
- Routage dynamique via OSPF
- Objectif :
👉 si le lien principal devient lent ou inutilisable, le trafic doit automatiquement passer par le lien secondaire
Dans un contexte B2B, cela concerne directement :
- ERP
- téléphonie IP
- accès RDP / VPN
- flux métiers critiques
Une latence excessive (1 à 2 secondes) est fonctionnellement équivalente à une panne.
🧠 L’hypothèse logique (mais fausse)
L’hypothèse initiale est très répandue :
« Si la passerelle principale devient rouge dans pfSense, OSPF devrait automatiquement basculer sur l’autre route. »
C’est logique…
mais ce n’est pas ainsi que fonctionnent OSPF ni pfSense.
⚙️ Ce que fait réellement OSPF (et ce qu’il ne fait pas)
OSPF est un protocole de routage topologique, pas qualitatif.
Il prend ses décisions uniquement sur :
- l’état des interfaces (UP / DOWN)
- la présence des voisins OSPF
- des coûts statiques
❌ OSPF ne prend pas en compte :
- la latence
- la perte de paquets
- la qualité Internet
- l’état des gateways pfSense
- les pings ou probes applicatives
Autrement dit :
Un lien OSPF “UP mais lent” reste préférable à un lien plus rapide si son coût est inférieur.
🔍 Le piège WireGuard + multi-WAN
Dans notre cas, chaque site disposait de :
- deux tunnels WireGuard (FTTO / FTTH)
- deux routes OSPF avec des coûts différents (ex : 10 et 20)
Pourtant, lors de la panne FTTO :
- la route OSPF prioritaire est restée active
- aucune bascule n’a eu lieu
Pourquoi ?
Parce que WireGuard est stateless.
Si le lien FTTO tombe :
- pfSense peut décider de joindre l’endpoint WireGuard via la FTTH
- le tunnel reste UP
- le voisin OSPF reste FULL
- la route OSPF reste annoncée
➡️ OSPF n’a aucune raison de retirer la route, même si la qualité du lien est désastreuse.
🚨 Le point clé souvent ignoré
Dans pfSense :
- une gateway est une abstraction interne
- son état (UP / DOWN / LATENCY) est géré par
dpinger - OSPF n’a absolument aucune connaissance de cet état
Il n’existe aucun lien natif entre :
gateway pfSense dégradée ≠ décision OSPF
🛠️ La solution professionnelle mise en place par DYB
Pour répondre au besoin métier réel (qualité de service), nous avons mis en place une logique de corrélation entre la qualité du lien et le routage OSPF.
Principe retenu
- pfSense surveille activement la qualité du lien (latence / perte)
- Lorsqu’un seuil critique est dépassé :
- un script est déclenché
- le coût OSPF du tunnel concerné est augmenté
- OSPF recalcule les routes et privilégie le chemin sain
➡️ La bascule est automatique, déterministe et réversible
Le principe à connaitre :
C’est quoi un hysteresis anti-flap ? | DYB
🔗 Le mécanisme technique (sans rentrer dans le code)
pfSense dispose d’un hook natif peu connu mais extrêmement puissant :
/etc/rc.gateway_alarm
Ce script est exécuté automatiquement lorsque :
- une gateway passe UP / DOWN
- ou devient fortement dégradée
Nous l’utilisons pour :
- dialoguer avec FRR (OSPF)
- ajuster dynamiquement les coûts OSPF
- introduire une hystérésis (anti-flapping)
🏗️ Pourquoi cette approche est adaptée au monde pro
✔️ Avantages
- Aucun équipement propriétaire
- Aucun “SD-WAN magique”
- Maîtrise totale du comportement réseau
- Décisions basées sur la réalité terrain
- Compatible multi-sites, multi-opérateurs
⚠️ Points d’attention
- nécessite une vraie compréhension réseau
- demande un design propre (1 tunnel = 1 lien)
- doit être documentée et maintenue
🧩 Conclusion : OSPF n’est pas cassé, il est juste fidèle à son rôle
Ce retour d’expérience met en évidence une réalité importante :
OSPF n’est pas conçu pour faire du routage basé sur la qualité du lien.
Dans un contexte professionnel moderne :
- multi-opérateurs
- inter-sites chiffrés
- applications sensibles à la latence
👉 Il est indispensable d’ajouter une couche d’intelligence autour du routage dynamique.
C’est précisément ce que nous faisons chez DYB :
- architectures sur mesure
- compréhension fine des protocoles
- solutions robustes, explicables et maîtrisées
📌 Chez DYB, nous concevons des infrastructures réseau résilientes, lisibles et adaptées aux usages réels, pas seulement “fonctionnelles sur le papier”.
Si vous souhaitez auditer ou fiabiliser une architecture multi-sites,
nous savons exactement où regarder.
