What a BGP Tunnel Filter Actually Does
Key takeaways
- A tunnel BGP filter controls route exchange on a specific GRE or IPsec session, not Internet-wide route authorization.
- An allow profile implicitly rejects unmatched prefixes, while a deny profile implicitly accepts everything outside its matches.
- Explicitly configured tunnel prefixes such as extra_prefixes can bypass export filtering and still be advertised.
- Inbound RIB-in limits (such as 5,000 routes) are enforced before import filtering, so rejected routes still count toward the session cap.
A BGP tunnel filter controls which route prefixes are accepted from or advertised to a peer across a specific GRE or IPsec session. It sets a local policy boundary between your router and a cloud or edge virtual network, without changing Internet-wide route origin authorization or BYOIP ownership checks.
When dynamic BGP replaces static routes on a cloud interconnect or scrubbing tunnel, both sides need an explicit rule for which prefixes belong on that link. Understanding what a tunnel filter evaluates, what bypasses it, and where route limits are enforced prevents unexpected blackholes and session drops.
Tunnel BGP filtering vs Internet route authorization
Operators working with Bring Your Own IP manage two different routing boundaries that are easy to conflate:
- Public Internet origin authorization: proving to the global routing table (and to your provider during onboarding) that an ASN is permitted to originate your public prefix, using RPKI Route Origin Authorizations (ROAs) and registry records.
- Tunnel session route exchange: controlling which routes your customer premises equipment (CPE) or data-center router exchanges with a provider's virtual routing table over GRE or IPsec tunnels.
For example, Cloudflare's BGP route filter profiles for GRE and IPsec tunnels govern routes exchanged with Magic Transit and Cloudflare WAN virtual networks. A tunnel filter stops a stray internal subnet or default route from crossing the tunnel session, while RPKI and provider onboarding rules govern what the provider announces to the wider Internet.
How import and export filter profiles work
Tunnel route filters are directional, and the direction is named from the perspective of the platform enforcing the profile:
| Direction | What it evaluates | Operational purpose |
|---|---|---|
| Import filter | Routes advertised by your router into the provider's tunnel endpoint | Prevents your equipment from injecting unintended LAN subnets, overlapping RFC 1918 ranges, or overly specific routes into the virtual network |
| Export filter | Routes selected from the provider's virtual routing table to advertise back to your router | Controls which learned or return prefixes your equipment receives over that specific tunnel |
Each filter entry matches prefixes using one of three scopes: an exact prefix (such as 203.0.113.0/24 only), a prefix and its more-specific routes (such as 10.20.0.0/16 down to /32), or a prefix-length range (for example /24 through /28 inside a parent block). See our CIDR notation guide for how prefix lengths define block boundaries.
Why allow and deny profiles are complements
A filter profile is not just a list of prefixes; its default action on unmatched routes determines how the policy behaves when your network changes.
| Profile type | Matching prefixes | Everything outside the matches | Best fit |
|---|---|---|---|
| Allow profile | Accepted | Implicitly rejected | Strict production boundaries where only an explicit inventory of prefixes may cross the tunnel |
| Deny profile | Rejected | Implicitly accepted | Carving out specific overlapping or local prefixes while accepting all other dynamic routes |
Because an allow profile rejects every route outside its match list, attaching an incomplete allow profile to a live tunnel immediately suppresses any unalisted failover or management prefix. Conversely, a deny profile accepts newly added subnets automatically unless they fall inside a denied range.
Two operational exceptions that catch teams out
Reading the filter profile alone does not tell the whole story of what happens on the wire. Two documented behaviors in Cloudflare WAN and Magic Transit route configuration illustrate why you must check the surrounding tunnel settings alongside the filter:
1. Explicit tunnel prefixes can bypass export filtering. On Cloudflare GRE and IPsec tunnels, prefixes configured directly in a tunnel's extra_prefixes field bypass the tunnel's export filter profile. If you attach an export filter expecting it to silence every outbound prefix on a backup tunnel, any prefix listed in extra_prefixes will still be advertised to the peer.
2. Inbound RIB-in limits are enforced before import filtering. A GRE or IPsec BGP session on Magic Transit and Cloudflare WAN enforces a 5,000-route inbound routing-information-base (RIB-in) limit before the import filter runs. Routes rejected by your import filter still consume that 5,000-route allowance. An import filter therefore cannot rescue a session where a peer accidentally leaks a full routing table or tens of thousands of internal host routes; the router must filter its outbound advertisement before putting the routes on the session.
Keep this tunnel BGP RIB-in limit distinct from overlay route capacities such as Cloudflare Tunnel and Mesh's 50,000 CIDR/hostname route limit, which applies to account-level Zero Trust tunnel routing rather than GRE or IPsec BGP sessions.
Step-by-step process for auditing a tunnel BGP filter
Before attaching or modifying an import or export filter profile on a production tunnel, walk through this four-step verification process.
Inventory
Document intended prefixes and length bounds
List every prefix each tunnel should carry during normal operation and failover, including the exact prefix length (such as 203.0.113.0/24) and any permitted more-specific range.
- Separate public BYOIP prefixes from private RFC 1918 WAN ranges.
- Record which application or return path depends on each route.
FAQ
Related resources
Ready to see where BYOIP is supported?
Continue the series
When a Valid ROA Still Leaves a Hole
A covering ROA with a permissive maxLength can make a forged-origin sub-prefix announcement evaluate as RPKI-valid. See why 16.2% of RPKI-covered IPv4 routes remain exposed and how minimal-length ROAs close the gap.
10 min read · Updated 19 October 2026
Read articleASPA After You Already Publish ROAs
ROAs verify which ASN may originate a prefix, but they cannot detect route leaks or forged upstream paths. Learn how Autonomous System Provider Authorization (ASPA) validates Customer-to-Provider hops and how to prepare your records.
10 min read · Updated 19 October 2026
Read article