Cloudflare ajoute des filtres BGP d’import et d’export à ses tunnels IPsec et GRE
Le 15 octobre 2026, Cloudflare ajoute des profils de filtrage BGP réutilisables aux tunnels IPsec et GRE de Cloudflare WAN et Magic Transit, appliqués sans réinitialiser la session. Si vous annoncez des préfixes via Cloudflare, configurez dès maintenant un filtre d’export en allow-list pour empêcher toute fuite de routes.
15 octobre 2026. Cloudflare ajoute des profils de filtrage BGP aux tunnels IPsec et GRE de Cloudflare WAN et Magic Transit. 5 octobre 2026. Le peering BGP sur ces mêmes tunnels passait en disponibilité générale. 18 septembre 2026. Unified Routing devenait la recommandation pour tous les nouveaux comptes. Pourquoi c’est important : c’est la première fois qu’un client Cloudflare peut contrôler précisément quels préfixes il importe et exporte via BGP, et le faire sans réinitialiser la session — le chaînon qui manquait pour router proprement en production.
Le chaînon manquant du BGP managé
Sur un routeur classique, filtrer du BGP est un réflexe de base : une prefix-list, une route-map ou un filtre AS-path suffisent à n’accepter que les routes que l’on veut et à n’annoncer que les préfixes que l’on possède réellement. Ces filtres sont la première ligne de défense contre deux incidents bien documentés : la fuite de routes — annoncer un préfixe que l’on ne possède pas, qui part alors en cascade dans la table de routage mondiale — et l’acceptation d’une route indésirable, qu’il s’agisse d’un préfixe bogon, d’une route par défaut non sollicitée ou d’un préfixe plus spécifique qui détourne du trafic.
Jusqu’ici, le BGP managé de Cloudflare n’offrait pas ce niveau de contrôle. Magic Transit, qui annonce vos préfixes depuis les points de présence Cloudflare pour absorber le trafic et les attaques DDoS, imposait une logique plus simple : on déclare un ensemble de préfixes, et Cloudflare les relaie. L’administrateur n’avait pas d’équivalent natif des prefix-lists de son routeur — il devait faire confiance à la configuration d’ensemble, ou compenser par des scripts et des vérifications manuelles.
Les conséquences d’une fuite de routes ne sont pas théoriques. En 2008, une annonce plus spécifique émise par Pakistan Telecom vers son transit PCCW a détourné l’essentiel du trafic YouTube mondial pendant plusieurs heures. En 2019, une reconfiguration fautive entre Cloudflare et Verizon a laissé fuir des dizaines de milliers de préfixes, saturant les tables de routage de nombreux opérateurs. Dans les deux cas, un simple filtre d’export en allow-list — n’autoriser que les préfixes réellement possédés — aurait stoppé l’incident à la source.
Le 15 octobre 2026, ce chaînon manquant est comblé. Cloudflare WAN et Magic Transit acceptent désormais des profils de filtrage BGP sur leurs tunnels IPsec et GRE.
Ce que font exactement les filtres
Un profil de filtre est un objet réutilisable qui combine une action — allow ou deny — et une liste de cibles CIDR. Trois modes de correspondance sont proposés : exact (le préfixe annoncé doit être identique à la cible), more-specific (le préfixe est plus spécifique que la cible) et prefix-length (correspondance par longueur de préfixe). C’est la même sémantique qu’une prefix-list classique, transposée dans l’interface Cloudflare.
Chaque tunnel porte un filtre d’import et un filtre d’export :
- Le filtre d’import décide quelles routes, annoncées par votre routeur, Cloudflare accepte dans sa table de routage virtuelle.
- Le filtre d’export décide quels préfixes Cloudflare annonce vers votre routeur — ou, côté Magic Transit, vers l’Internet.
Les profils se créent et s’attachent via le dashboard, l’API ou Terraform. Le point décisif : une modification de profil s’applique sans réinitialiser la session BGP.
Concrètement, un profil d’export peut se réduire à une allow-list d’un seul préfixe — par exemple 203.0.113.0/24 en mode exact — ce qui interdit à toute autre route de sortir par ce tunnel. Un profil d’import peut, lui, bloquer la plage 10.0.0.0/8 en mode more-specific pour empêcher votre routeur d’injecter des routes internes dans la table de routage virtuelle de Cloudflare.
Le filtrage a aussi un rôle dans la protection DDoS. Côté Magic Transit, le filtre d’import évite d’accepter depuis votre routeur un préfixe plus spécifique qui détournerait une partie de votre annonce vers un chemin non surveillé — la technique du hijack de préfixe, que les attaquants utilisent pour intercepter du trafic destiné à l’une de vos plages. Côté export, l’allow-list garantit que seuls vos préfixes passent par le scrubbing de Cloudflare, sans qu’un préfixe parasite ne soit diffusé à votre insu.
Pourquoi « sans reset » change tout
En BGP, une session se réinitialise quand sa configuration change : le routeur ferme la session TCP 179, efface les routes apprises, puis re-négocie et ré-apprend. Pendant ce temps, le trafic peut être noir-troué ou re-routeré de façon imprévisible — c’est pourquoi les équipes réseau planifient leurs changements BGP dans des fenêtres de maintenance nocturnes.
Le fait que Cloudflare applique un nouveau filtre à chaud change la donne : on peut durcir progressivement sa politique de routage en pleine journée, sans coupure. On ajoute un filtre d’export restrictif, on l’observe, on le retire s’il bloque une route légitime, sans jamais interrompre la session ni le trafic. C’est la différence entre un outil que l’on utilise réellement et un outil que l’on remet indéfiniment à plus tard.
Un BGP tout juste passé en GA
Ce filtrage s’inscrit dans une séquence rapide de mises en disponibilité. Le 5 octobre 2026, Cloudflare annonçait la disponibilité générale du peering BGP sur les tunnels IPsec et GRE : les routes s’échangent dynamiquement entre votre matériel et la table de routage virtuelle de Cloudflare, au lieu de maintenir des routes statiques à la main. Le 18 septembre 2026, Unified Routing passait en GA avec le routage retour automatique et le support BGP. Le 25 septembre 2026, les Managed Rulesets du pare-feu réseau avancé devenaient disponibles en mode Unified Routing.
Autrement dit, le filtrage du 15 octobre est la pièce qui rend ce BGP réellement exploitable : la GA du 5 octobre permettait d’échanger des routes, le filtrage permet enfin de contrôler ce qui s’échange — et donc de l’utiliser sans se tirer une balle dans le pied.
Ce qu’il faut configurer maintenant
La priorité n’est pas l’import, c’est l’export. Un filtre d’export qui n’autorise que les préfixes que vous possédez réellement est la mesure la plus simple contre la fuite de routes : si une mauvaise configuration tente d’annoncer un préfixe voisin, Cloudflare le bloque avant qu’il n’atteigne l’Internet.
Voici la marche à suivre :
- Inventorier les préfixes réellement annoncés via chaque tunnel, puis créer un profil d’export en allow-list sur ces seuls préfixes.
- Bloquer à l’import les préfixes bogon (RFC 1918, liens locaux, plages réservées) et toute route par défaut non sollicitée.
- Tester chaque profil sur un tunnel non critique avant de l’étendre, en profitant de l’application sans reset.
Un point d’attention : le filtre d’export s’applique aussi côté Magic Transit, où c’est Cloudflare qui annonce vos préfixes à l’Internet. Une allow-list trop étroite y couperait l’annonce de vos services — d’où l’importance de tester avant d’appliquer en production.
Verdict
Si vous opérez Cloudflare WAN ou Magic Transit avec du BGP, créez immédiatement un profil d’export en allow-list sur vos préfixes : c’est la protection la plus rentable contre la fuite de routes, et elle ne coûte désormais aucune interruption de service. Si vous utilisiez encore des routes statiques, la GA du 5 octobre vous dispense de ce travail manuel, et le filtrage du 15 octobre vous donne le contrôle qui manquait pour franchir le pas sans risque.