Cloudflare adds BGP import and export filtering to its IPsec and GRE tunnels
On 15 October 2026, Cloudflare added reusable BGP filter profiles to Cloudflare WAN and Magic Transit IPsec and GRE tunnels, applied without resetting the BGP session. If you announce prefixes through Cloudflare, build an allow-list export filter now to prevent route leaks.
15 October 2026. Cloudflare added BGP filter profiles to the IPsec and GRE tunnels of Cloudflare WAN and Magic Transit. 5 October 2026. BGP peering over those same tunnels reached general availability. 18 September 2026. Unified Routing became the recommendation for every new account. Why it matters: for the first time, a Cloudflare customer can control exactly which prefixes they import and export over BGP — and do it without resetting the session, which is the missing link for routing cleanly in production.
The missing piece of managed BGP
On a conventional router, filtering BGP is second nature: a prefix-list, a route-map, or an AS-path filter lets you accept only the routes you want and announce only the prefixes you actually own. Those filters are the first line of defense against two well-documented incidents: a route leak — announcing a prefix you do not own, which then cascades into the global routing table — and accepting an unwanted route, whether a bogon prefix, an unsolicited default route, or a more-specific prefix that steals traffic.
Until now, Cloudflare’s managed BGP offered no equivalent level of control. Magic Transit, which announces your prefixes from Cloudflare’s points of presence to absorb traffic and DDoS attacks, imposed a simpler model: you declare a set of prefixes and Cloudflare relays them. The operator had no native equivalent of the prefix-lists on their own router — they had to trust the aggregate configuration, or compensate with scripts and manual checks.
The consequences of a route leak are not theoretical. In 2008, a more-specific announcement from Pakistan Telecom toward its transit PCCW diverted most of the world’s YouTube traffic for several hours. In 2019, a faulty reconfiguration between Cloudflare and Verizon leaked tens of thousands of prefixes, saturating routing tables at many operators. In both cases, a simple allow-list export filter — only announcing the prefixes you actually own — would have stopped the incident at the source.
On 15 October 2026, that gap closed. Cloudflare WAN and Magic Transit now accept BGP filter profiles on their IPsec and GRE tunnels.
What the filters actually do
A filter profile is a reusable object that combines an action — allow or deny — with a list of CIDR targets. Three matching modes are available: exact (the announced prefix must equal the target), more-specific (the prefix is more specific than the target), and prefix-length (matching by prefix length). It is the same semantics as a classic prefix-list, transposed into the Cloudflare interface.
Each tunnel carries one import filter and one export filter:
- The import filter decides which routes announced by your router Cloudflare accepts into its virtual routing table.
- The export filter decides which prefixes Cloudflare announces toward your router — or, on the Magic Transit side, toward the Internet.
Profiles are created and attached through the dashboard, the API, or Terraform. The decisive point: changing a profile applies without resetting the BGP session.
Concretely, an export profile can reduce to a single-prefix allow-list — for example 203.0.113.0/24 in exact mode — which stops any other route from leaving through that tunnel. An import profile can, in turn, block the 10.0.0.0/8 range in more-specific mode to prevent your router from injecting internal routes into Cloudflare’s virtual routing table.
Filtering also plays a role in DDoS protection. On the Magic Transit side, the import filter avoids accepting a more-specific prefix from your router that would divert part of your announcement onto an unmonitored path — the prefix hijack technique attackers use to intercept traffic bound for one of your ranges. On the export side, the allow-list guarantees that only your prefixes go through Cloudflare’s scrubbing, without a rogue prefix being broadcast behind your back.
Why “no reset” changes everything
In BGP, a session resets when its configuration changes: the router tears down the TCP 179 session, flushes the learned routes, then re-negotiates and re-learns. In the meantime, traffic can be blackholed or re-routed unpredictably — which is why network teams schedule BGP changes into overnight maintenance windows.
The fact that Cloudflare applies a new filter hot changes the calculus: you can tighten your routing policy gradually, in the middle of the day, with no outage. You add a restrictive export filter, watch it, remove it if it blocks a legitimate route, without ever interrupting the session or the traffic. That is the difference between a tool you actually use and a tool you keep deferring.
A BGP that only just reached GA
The filtering lands in the middle of a rapid availability sequence. On 5 October 2026, Cloudflare announced general availability of BGP peering over IPsec and GRE tunnels for Cloudflare WAN and Magic Transit: routes now exchange dynamically between your hardware and Cloudflare’s virtual routing table, instead of maintaining static routes by hand. On 18 September 2026, Unified Routing went GA with automatic return routing and BGP support. On 25 September 2026, the advanced network firewall Managed Rulesets became available in Unified Routing mode.
In other words, the 15 October filtering is the piece that makes this BGP genuinely usable: the 5 October GA let you exchange routes, and the filtering finally lets you control what gets exchanged — so you can use it without shooting yourself in the foot.
What to configure now
The priority is not import; it is export. An export filter that only permits the prefixes you actually own is the simplest measure against route leaks: if a misconfiguration tries to announce a neighbor’s prefix, Cloudflare blocks it before it reaches the Internet.
Here is the sequence to follow:
- Inventory the prefixes you actually announce over each tunnel, then create an export profile that allow-lists only those prefixes.
- Block bogon prefixes (RFC 1918, link-local, reserved ranges) and any unsolicited default route on the import side.
- Test each profile on a non-critical tunnel before rolling it out, taking advantage of the reset-free application.
Because a profile is a reusable object, the same allow-list can be attached to several tunnels at once — which matters for fleets that run many IPsec or GRE on-ramps. A single change to the profile propagates to every attached tunnel, still without resetting any session. That makes policy drift far less likely than maintaining per-tunnel route maps by hand.
One caveat: the export filter also applies on the Magic Transit side, where Cloudflare announces your prefixes to the Internet. An allow-list that is too narrow would cut off the announcement of your services — another reason to test before applying in production.
Verdict
If you operate Cloudflare WAN or Magic Transit over BGP, create an allow-list export profile for your prefixes right now: it is the cheapest protection against route leaks, and it no longer costs you any service interruption. If you were still using static routes, the 5 October GA relieves you of that manual work, and the 15 October filtering gives you the control you were missing to make the switch safely.