{"id":1258,"date":"2025-09-09T17:15:46","date_gmt":"2025-09-09T15:15:46","guid":{"rendered":"https:\/\/dyb.fr\/?p=1258"},"modified":"2025-09-09T17:15:46","modified_gmt":"2025-09-09T15:15:46","slug":"le-bug-invisible-qui-bloque-votre-migration-de-vpn-ipsec-vers-wireguard","status":"publish","type":"post","link":"https:\/\/dyb.eu\/blog\/le-bug-invisible-qui-bloque-votre-migration-de-vpn-ipsec-vers-wireguard\/","title":{"rendered":"Le bug invisible qui bloque votre migration de VPN IPsec vers WireGuard"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\"><strong>\ud83c\udf10 Contexte : d\u2019un VPN IPsec classique vers un SD-WAN moderne<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Dans beaucoup de PME, l\u2019interconnexion des sites distants s\u2019est longtemps faite avec des tunnels <strong>IPsec policy-based<\/strong>. C\u2019\u00e9tait simple \u00e0 mettre en place : chaque site avait ses Phase 2 couvrant ses r\u00e9seaux internes (172.16.x.x\/16, 192.168.x.x\/16\u2026), et la connectivit\u00e9 fonctionnait.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Mais \u00e0 mesure que l\u2019infrastructure grandit, ce mod\u00e8le montre vite ses limites :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Pas de routage dynamique<\/strong> : chaque nouveau VLAN doit \u00eatre ajout\u00e9 manuellement.<\/li>\n\n\n\n<li><strong>Administration lourde<\/strong> : plusieurs dizaines de Phase 2 deviennent vite ing\u00e9rables.<\/li>\n\n\n\n<li><strong>R\u00e9silience limit\u00e9e<\/strong> : pas de vraie notion de co\u00fbts ou de bascule automatique.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">D\u2019o\u00f9 la d\u00e9cision de migrer vers une logique de <strong>SD-WAN interne<\/strong> :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Des tunnels <strong>WireGuard<\/strong> multipli\u00e9s entre les sites.<\/li>\n\n\n\n<li><strong>OSPF via FRR<\/strong> pour \u00e9changer les routes dynamiquement.<\/li>\n\n\n\n<li><strong>Pas de NAT<\/strong> inter-sites : chaque VLAN reste joignable en direct.<\/li>\n\n\n\n<li>Gestion de la r\u00e9silience via les <strong>co\u00fbts OSPF<\/strong>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u2699\ufe0f La migration : tout est en place\u2026 en th\u00e9orie<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">La migration d\u2019un site pilote a \u00e9t\u00e9 r\u00e9alis\u00e9e avec succ\u00e8s sur le papier :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Les tunnels WireGuard montaient bien.<\/li>\n\n\n\n<li>OSPF annon\u00e7ait correctement le r\u00e9seau local (10.200.0.0\/16).<\/li>\n\n\n\n<li>Les routes \u00e9taient pr\u00e9sentes dans la table de routage.<\/li>\n\n\n\n<li>Le firewall laissait passer le trafic (pass any sur les interfaces WG).<\/li>\n\n\n\n<li>Le mode <em>Floating States<\/em> \u00e9vitait les probl\u00e8mes d\u2019asym\u00e9trie.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Bref, tout semblait correct. Pourtant, les postes du LAN (10.200.20.x) n\u2019arrivaient pas \u00e0 joindre les serveurs applicatifs du site principal (10.100.110.x).<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u274c Le sympt\u00f4me : des SYN qui se perdent<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Les tests montraient :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Depuis le site secondaire, <strong>les SYN sortaient bien<\/strong> via WireGuard (visibles en tcpdump).<\/li>\n\n\n\n<li>Mais c\u00f4t\u00e9 hub, <strong>rien n\u2019arrivait sur le VLAN applicatif<\/strong>.<\/li>\n\n\n\n<li>Aucune r\u00e8gle firewall ne bloquait le flux (pflog montrait un <em>pass<\/em>).<\/li>\n\n\n\n<li>R\u00e9sultat : pas de SYN-ACK \u2192 connexion impossible.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Encore plus \u00e9trange :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Depuis d\u2019autres sites migr\u00e9s, \u00e7a fonctionnait.<\/li>\n\n\n\n<li>En IPsec (ancienne config), \u00e7a fonctionnait aussi.<\/li>\n\n\n\n<li>Depuis le firewall lui-m\u00eame en source = IP du tunnel WG, \u00e7a marchait.<\/li>\n\n\n\n<li>Mais depuis une IP du LAN, syst\u00e9matiquement KO.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\ud83d\udd0d L\u2019origine : une \u201croute fant\u00f4me\u201d IPsec<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Le paquet <strong>arrivait sur l\u2019interface WireGuard du hub<\/strong>, mais n\u2019\u00e9tait jamais inject\u00e9 vers le VLAN interne.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">En r\u00e9alit\u00e9, une <strong>ancienne Phase 2 IPsec<\/strong> \u00e9tait encore active.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">M\u00eame si la <strong>Phase 1<\/strong> avait \u00e9t\u00e9 d\u00e9sactiv\u00e9e, la Phase 2 avait laiss\u00e9 des <strong>policies dans la SPD (Security Policy Database)<\/strong> du noyau. R\u00e9sultat :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Tout trafic 10.200.0.0\/16 \u2194 10.100.0.0\/16 \u00e9tait <strong>aspir\u00e9 vers IPsec<\/strong>.<\/li>\n\n\n\n<li>Comme le tunnel IPsec n\u2019\u00e9tait plus mont\u00e9, les paquets disparaissaient dans un trou noir.<\/li>\n\n\n\n<li>WireGuard ne voyait donc jamais les r\u00e9ponses.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Un simple \"ipsec statusall\" a r\u00e9v\u00e9l\u00e9 la v\u00e9rit\u00e9 :<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>Routed Connections:\n  conX{7}: ROUTED, TUNNEL\n  conX{7}: 10.200.0.0\/16 === 10.100.0.0\/16<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">\ud83d\udc49 Tant que cette \u201crouted connection\u201d existait, le trafic WireGuard \u00e9tait court-circuit\u00e9.<\/p>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\u2705 La r\u00e9solution<\/strong><\/h2>\n\n\n\n<ol start=\"1\" class=\"wp-block-list\">\n<li><strong>Suppression des anciennes Phase 2<\/strong> IPsec couvrant ces r\u00e9seaux.<\/li>\n\n\n\n<li><strong>Flush du SPD\/SAD<\/strong> pour repartir propre :<\/li>\n<\/ol>\n\n\n\n<pre class=\"wp-block-code\"><code>setkey -F\nsetkey -FP<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\"><br>3. <strong>Contr\u00f4le<\/strong><\/p>\n\n\n\n<pre class=\"wp-block-code\"><code>ipsec statusall   # plus de \"Routed Connections\"\nsetkey -DP        # plus de policies pour 10.200\/16 et 10.100\/16\ntcpdump -i enc0   # aucun trafic aspir\u00e9 vers IPsec<\/code><\/pre>\n\n\n\n<ol start=\"4\" class=\"wp-block-list\">\n<li>Retest depuis un poste utilisateur : <strong>SYN \u2192 SYN-ACK \u2192 ESTABLISHED<\/strong> \ud83c\udf89<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\ud83d\udccc Le\u00e7ons apprises<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Lors d\u2019une migration <strong>IPsec \u2192 WireGuard<\/strong>, <strong>d\u00e9sactivez\/supprimez toutes les Phase 2 IPsec<\/strong> correspondantes d\u00e8s qu\u2019un site bascule.<\/li>\n\n\n\n<li>Tant qu\u2019une P2 existe, le noyau installe des policies qui peuvent <strong>court-circuiter WireGuard<\/strong>.<\/li>\n\n\n\n<li>Un simple red\u00e9marrage du service IPsec peut suffire \u00e0 tout casser si ces policies restent pr\u00e9sentes.<\/li>\n\n\n\n<li>Moralit\u00e9 : <strong>IPsec et WireGuard ne doivent pas couvrir les m\u00eames sous-r\u00e9seaux simultan\u00e9ment<\/strong>.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator has-alpha-channel-opacity\"\/>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>\ud83d\ude80 Conclusion<\/strong><\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Ce cas montre que le probl\u00e8me n\u2019est pas toujours dans le VPN qu\u2019on soup\u00e7onne :<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Les tunnels WireGuard \u00e9taient op\u00e9rationnels.<\/li>\n\n\n\n<li>OSPF annon\u00e7ait correctement les routes.<\/li>\n\n\n\n<li>Le firewall n\u2019avait pas bloqu\u00e9.<\/li>\n\n\n\n<li>Mais une <strong>politique IPsec fant\u00f4me<\/strong> a suffi \u00e0 bloquer tout le trafic.<\/li>\n<\/ul>\n\n\n\n<p class=\"wp-block-paragraph\">Depuis que ces Phase 2 r\u00e9siduelles ont \u00e9t\u00e9 supprim\u00e9es, la migration SD-WAN fonctionne parfaitement. Les sites communiquent d\u00e9sormais en <strong>WireGuard + OSPF<\/strong>, avec une r\u00e9silience et une souplesse incomparables par rapport \u00e0 l\u2019ancien mod\u00e8le IPsec.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>\ud83c\udf10 Contexte : d\u2019un VPN IPsec classique vers un SD-WAN moderne Dans beaucoup de PME, l\u2019interconnexion des sites distants s\u2019est longtemps faite avec des tunnels IPsec policy-based. C\u2019\u00e9tait simple \u00e0 mettre en place : chaque site avait ses Phase 2 couvrant ses r\u00e9seaux internes (172.16.x.x\/16, 192.168.x.x\/16\u2026), et la connectivit\u00e9 fonctionnait. Mais \u00e0 mesure que l\u2019infrastructure [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":1259,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[26,24],"tags":[23],"class_list":["post-1258","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-adminsys","category-reseaux","tag-pfsense"],"_links":{"self":[{"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/posts\/1258","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/comments?post=1258"}],"version-history":[{"count":0,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/posts\/1258\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/media\/1259"}],"wp:attachment":[{"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/media?parent=1258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/categories?post=1258"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/dyb.eu\/blog\/wp-json\/wp\/v2\/tags?post=1258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}