Le bug invisible qui bloque votre migration de VPN IPsec vers WireGuard

par | Sep 9, 2025 | AdminSys, Réseaux

🌐 Contexte : d’un VPN IPsec classique vers un SD-WAN moderne

Dans beaucoup de PME, l’interconnexion des sites distants s’est longtemps faite avec des tunnels IPsec policy-based. C’était simple à mettre en place : chaque site avait ses Phase 2 couvrant ses réseaux internes (172.16.x.x/16, 192.168.x.x/16…), et la connectivité fonctionnait.

Mais à mesure que l’infrastructure grandit, ce modèle montre vite ses limites :

  • Pas de routage dynamique : chaque nouveau VLAN doit être ajouté manuellement.
  • Administration lourde : plusieurs dizaines de Phase 2 deviennent vite ingérables.
  • Résilience limitée : pas de vraie notion de coûts ou de bascule automatique.

D’où la décision de migrer vers une logique de SD-WAN interne :

  • Des tunnels WireGuard multipliés entre les sites.
  • OSPF via FRR pour échanger les routes dynamiquement.
  • Pas de NAT inter-sites : chaque VLAN reste joignable en direct.
  • Gestion de la résilience via les coûts OSPF.

⚙️ La migration : tout est en place… en théorie

La migration d’un site pilote a été réalisée avec succès sur le papier :

  • Les tunnels WireGuard montaient bien.
  • OSPF annonçait correctement le réseau local (10.200.0.0/16).
  • Les routes étaient présentes dans la table de routage.
  • Le firewall laissait passer le trafic (pass any sur les interfaces WG).
  • Le mode Floating States évitait les problèmes d’asymétrie.

Bref, tout semblait correct. Pourtant, les postes du LAN (10.200.20.x) n’arrivaient pas à joindre les serveurs applicatifs du site principal (10.100.110.x).

❌ Le symptôme : des SYN qui se perdent

Les tests montraient :

  • Depuis le site secondaire, les SYN sortaient bien via WireGuard (visibles en tcpdump).
  • Mais côté hub, rien n’arrivait sur le VLAN applicatif.
  • Aucune règle firewall ne bloquait le flux (pflog montrait un pass).
  • Résultat : pas de SYN-ACK → connexion impossible.

Encore plus étrange :

  • Depuis d’autres sites migrés, ça fonctionnait.
  • En IPsec (ancienne config), ça fonctionnait aussi.
  • Depuis le firewall lui-même en source = IP du tunnel WG, ça marchait.
  • Mais depuis une IP du LAN, systématiquement KO.

🔍 L’origine : une “route fantôme” IPsec

Le paquet arrivait sur l’interface WireGuard du hub, mais n’était jamais injecté vers le VLAN interne.

En réalité, une ancienne Phase 2 IPsec était encore active.

Même si la Phase 1 avait été désactivée, la Phase 2 avait laissé des policies dans la SPD (Security Policy Database) du noyau. Résultat :

  • Tout trafic 10.200.0.0/16 ↔ 10.100.0.0/16 était aspiré vers IPsec.
  • Comme le tunnel IPsec n’était plus monté, les paquets disparaissaient dans un trou noir.
  • WireGuard ne voyait donc jamais les réponses.

Un simple « ipsec statusall » a révélé la vérité :

Routed Connections:
  conX{7}: ROUTED, TUNNEL
  conX{7}: 10.200.0.0/16 === 10.100.0.0/16

👉 Tant que cette “routed connection” existait, le trafic WireGuard était court-circuité.

✅ La résolution

  1. Suppression des anciennes Phase 2 IPsec couvrant ces réseaux.
  2. Flush du SPD/SAD pour repartir propre :
setkey -F
setkey -FP


3. Contrôle

ipsec statusall   # plus de "Routed Connections"
setkey -DP        # plus de policies pour 10.200/16 et 10.100/16
tcpdump -i enc0   # aucun trafic aspiré vers IPsec
  1. Retest depuis un poste utilisateur : SYN → SYN-ACK → ESTABLISHED 🎉

📌 Leçons apprises

  • Lors d’une migration IPsec → WireGuard, désactivez/supprimez toutes les Phase 2 IPsec correspondantes dès qu’un site bascule.
  • Tant qu’une P2 existe, le noyau installe des policies qui peuvent court-circuiter WireGuard.
  • Un simple redémarrage du service IPsec peut suffire à tout casser si ces policies restent présentes.
  • Moralité : IPsec et WireGuard ne doivent pas couvrir les mêmes sous-réseaux simultanément.

🚀 Conclusion

Ce cas montre que le problème n’est pas toujours dans le VPN qu’on soupçonne :

  • Les tunnels WireGuard étaient opérationnels.
  • OSPF annonçait correctement les routes.
  • Le firewall n’avait pas bloqué.
  • Mais une politique IPsec fantôme a suffi à bloquer tout le trafic.

Depuis que ces Phase 2 résiduelles ont été supprimées, la migration SD-WAN fonctionne parfaitement. Les sites communiquent désormais en WireGuard + OSPF, avec une résilience et une souplesse incomparables par rapport à l’ancien modèle IPsec.