Chez DYB, nous concevons et opérons des infrastructures réseau multi-sites pour nos clients. Dans beaucoup d’environnements, on retrouve le même triptyque :
- plusieurs liens WAN (ex. fibre FTTH pour la bande passante, fibre dédiée FTTO pour la stabilité),
- un routage dynamique (OSPF) pour échanger automatiquement les sous-réseaux,
- des tunnels WireGuard pour sécuriser le trafic inter-sites,
- et pfSense comme pare-feu et routeur principal.
C’est une architecture très robuste, mais elle peut révéler un écueil subtil : le problème d’asymétrie de routage, qui bloque certains flux applicatifs.
Le symptôme
Le réseau semble fonctionner normalement :
- Les tunnels WireGuard montent,
- OSPF diffuse bien les routes,
- Les pings passent entre les sites.
Mais certaines applications échouent, typiquement SMB (partages de fichiers) ou RDP :
- On observe bien le paquet de départ (SYN),
- mais la réponse (SYN-ACK) n’arrive jamais au poste client.
L’explication
Le problème vient d’une asymétrie entre l’aller et le retour.
- À l’aller, une règle de Policy Based Routing (PBR) force le flux à emprunter un lien spécifique (par ex. la fibre FTTH).
- Au retour, OSPF choisit automatiquement le chemin le plus court… qui est souvent un autre lien (par ex. la FTTO).
Résultat : pfSense considère la réponse comme hors-state (puisqu’elle n’arrive pas par la même gateway que l’aller) et la bloque.
La solution
La clé consiste à gérer le reply-to directement sur les interfaces WireGuard, afin que pfSense force le retour à utiliser le même tunnel que l’aller, même si OSPF propose un autre chemin.
Étapes pratiques :
- Sur le site émetteur
- Créer une règle sur le VLAN utilisateur pour forcer le trafic applicatif (ex. SMB, RDP) à utiliser la gateway FTTH.
- Sur le site récepteur
- Aller dans Firewall > Rules > [Interface WireGuard] correspondant au tunnel FTTH.
- Ajouter une règle Pass ciblant le sous-réseau distant.
- Laisser le champ Gateway vide : pfSense y applique automatiquement un reply-to, ce qui garantit que la réponse repartira bien par le même tunnel.
- Conserver en dessous une règle “allow any” sur l’interface WireGuard pour le reste du trafic.
Pourquoi c’est important
- Cette approche permet de combiner routage dynamique (OSPF) et Policy Routing ciblé sans créer de conflits.
- Elle évite de recourir à des routes statiques ou à du NAT forcé, qui rigidifient l’architecture.
- Elle assure que certains flux sensibles (sauvegardes, impressions, VoIP…) utilisent toujours le lien le plus adapté, tout en maintenant la tolérance de panne automatique grâce à OSPF.
Un point clé : les Floating States
Pour que cette solution fonctionne, il faut adapter un réglage global dans pfSense : le Firewall State Policy.
- Par défaut, pfSense utilise les Interface Bound States : chaque connexion TCP/UDP est liée strictement à l’interface par laquelle elle a été créée.
→ Si le trafic de retour emprunte une autre interface, pfSense le bloque. - Dans un environnement multi-WAN + OSPF + VPN, cette approche trop stricte provoque des échecs (comme ceux observés sur SMB/RDP).
La solution est de passer en Floating States :
- Les connexions ne sont plus limitées à une seule interface,
- pfSense autorise le retour si les IP/ports correspondent, même si l’interface n’est pas la même,
- Cela supprime les blocages liés à l’asymétrie.
⚠️ Attention
Ce mode est moins strict en sécurité :
- Un paquet “retour” inattendu mais valide au niveau IP/port pourrait, en théorie, être accepté sur une autre interface.
- Dans la pratique, le risque est faible sur une infra bien cloisonnée, mais il faut en avoir conscience.
On vous recommande de changer en Floating States uniquement lorsqu’un routage dynamique (ex. OSPF) est combiné avec du multi-WAN/VPN.
C’est un compromis nécessaire pour la résilience, mais il doit s’accompagner d’un cloisonnement rigoureux des VLANs et d’une politique de firewall stricte sur les interfaces LAN/VPN.
Conclusion
L’asymétrie de routage est un phénomène classique dans les environnements multi-WAN + OSPF + VPN.
Comprendre la logique des états TCP dans pfSense, et savoir utiliser correctement le reply-to sur les interfaces VPN, permet de résoudre ce problème sans casser la dynamique du routage.
👉 En clair : si vous forcez l’aller, assurez-vous de forcer le retour au bon endroit.