Network Security Updates & Release Notes

Cloudflare WAN and Magic Transit IPsec and GRE tunnels now support BGP import and export filtering.

Create reusable filter profiles that specify an allow or deny action and a list of Classless Inter-Domain Routing (CIDR) targets with exact, more-specific, or prefix-length matching. Each tunnel supports one import filter and one export filter.

You can create and assign profiles through the dashboard, API, or Terraform. Profile changes apply without resetting the BGP session.

For configuration details, refer to:

• Filter BGP routes for Cloudflare WAN
• Filter BGP routes for Magic Transit

Original source

Cloudflare now preserves Workers context when a subrequest targets a Cloudflare-proxied hostname using Bring Your Own IP (BYOIP). These requests are identified as Cloudflare-to-Cloudflare traffic instead of external Internet traffic.

Previously, some BYOIP subrequests could lose Workers context and original client signals. This could cause security rules to behave unexpectedly, Bot Management to evaluate an internal Cloudflare connection instead of the original client, or affected requests to return false 403 responses.

Workers subrequests to BYOIP destinations now preserve the CF-Worker header and cf.worker.upstream_zone field. This supports consistent security rule evaluation across same-zone and cross-zone subrequests.

Bot Management fields on the destination zone now represent the original end-user connection for affected BYOIP subrequests. Bot scores, verified bot status, and JA3/JA4 fingerprints no longer represent the internal connection between Cloudflare services.

Customers benefit from consistent security rule evaluation, accurate Bot Management results, and fewer unexpected failures when Workers access BYOIP-backed hostnames. The improvement is automatic and requires no configuration changes.

For more information, refer to Cloudflare BYOIP and Workers subrequests.

Original source

BGP peering over IPsec and GRE tunnels is generally available for Cloudflare WAN and Magic Transit. You can use it for production workloads.

BGP peering exchanges routes dynamically between your devices and your Cloudflare virtual network routing table. You no longer need to update static routes manually as your network changes.

BGP over IPsec and GRE tunnels is available to all accounts that use Unified Routing. No enablement is required. BGP over CNI remains in closed beta.

For configuration details, refer to:

• Configure BGP routes for Cloudflare WAN
• Configure BGP routes for Magic Transit

Original source

Network Analytics is now fully supported for accounts using Unified Routing mode. Traffic that traverses Unified Routing onramps and offramps is now visible in Network Analytics with the same dimensions and filters as traffic on the standard data plane.

This closes a parity gap for customers who had moved tunnels onto Unified Routing and lost visibility into their dataplane traffic in the Network Analytics dashboard. No configuration change is required — analytics data is collected automatically for all accounts with Unified Routing enabled.

For the remaining beta limitations, refer to Traffic steering beta limitations.

Original source

New Magic Transit and Cloudflare WAN accounts are now assigned a single IPv4 anycast address by default.

Cloudflare handles failures on its network automatically by advertising your endpoint IP from multiple nodes across many globally distributed data centers. To handle failures on your network, configure two tunnels from separate routers.

To request additional anycast IP addresses for your account, contact your account team.

For tunnel configuration guidance, refer to Configure tunnel endpoints for Cloudflare WAN or Configure tunnel endpoints for Magic Transit.

Original source

Cloudflare IPsec now supports the standard NAT traversal (NAT-T) flow, where IKE begins on UDP port 500 and switches to UDP port 4500 after NAT is detected.

Previously, devices behind NAT had to be configured to initiate IKE on UDP port 4500 directly. Devices that started on UDP port 500 could not complete the IKE handshake when NAT was in the path. This required custom configuration on devices such as VeloCloud SD-WAN edges, Cisco IOS-XE routers, and Juniper SRX firewalls, and was not possible on every platform.

What changed

Devices behind NAT can now initiate IKE on either UDP port 500 or UDP port 4500.

Devices that start IKE on UDP port 500 and switch to UDP port 4500 after NAT detection now complete the handshake successfully.

No configuration change is required on Cloudflare. The change is available for all IPsec tunnels on Cloudflare WAN and Magic Transit.

This change does not affect existing tunnels:

Tunnels using UDP port 500 with no NAT detected continue to operate as before.

Tunnels configured to start IKE on UDP port 4500 continue to operate as before.

NAT detection logic is unchanged.

For configuration details, refer to GRE and IPsec tunnels.

Original source

Cloudflare Advanced Network Firewall Country rules are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

You can create firewall rules that match traffic based on source or destination country to enforce geographic access policies across your network.

This is the first of the Cloudflare Advanced Network Firewall features to become available in Unified Routing. Support for additional features - IP Lists, ASN Lists, Threat Intel Lists, IDS, Rate Limiting, SIP, and Managed Rulesets - is planned.

For the full list of current beta limitations, refer to Traffic steering beta limitations.

Original source

We are updating naming related to some of our Networking products to better clarify their place in the Zero Trust and Secure Access Service Edge (SASE) journey.
We are retiring some older brand names in favor of names that describe exactly what the products do within your network. We are doing this to help customers build better, clearer mental models for comprehensive SASE architecture delivered on Cloudflare.

What's changing

• Magic WAN → Cloudflare WAN
• Magic WAN IPsec → Cloudflare IPsec
• Magic WAN GRE → Cloudflare GRE
• Magic WAN Connector → Cloudflare One Appliance
• Magic Firewall → Cloudflare Network Firewall
• Magic Network Monitoring → Network Flow

No action is required by you — all functionality, existing configurations, and billing will remain exactly the same.

For more information, visit the Cloudflare One documentation.

Original source

Magic WAN now allows you to configure the source IP address range used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks. Previously, traffic to private networks was sourced from public Cloudflare IPs, which may have caused IP conflicts. With this feature, you can now configure a dedicated, non-Internet-routable private IP range to ensure:

• Symmetric routing over private network connections
• Proper firewall state preservation
• Private traffic stays on secure paths

Key details

• IPv4: Sourced from 100.64.0.0/12 by default, configurable to any /12 CIDR
• IPv6: Sourced from 2606:4700:cf1:5000::/64 (not configurable)
• Affected connectors: GRE, IPsec, CNI, WARP Connector, and WARP Client (Cloudflare Tunnel is not affected)

Configuring Cloudflare source IPs requires Cloudflare One Unified Routing (beta) and the "Cloudflare One Networks Write" permission.
For configuration details, refer to Configure Cloudflare source IPs.

Original source

You can now control how Cloudflare buffers HTTP request and response bodies using two new settings in Configuration Rules.

Request body buffering

Controls how Cloudflare buffers HTTP request bodies before forwarding them to your origin server:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the request body for enabled functionality such as WAF and Bot Management. Full Buffers the entire request body before sending to origin. None No buffering. The request body streams directly to origin without inspection.

Response body buffering

Controls how Cloudflare buffers HTTP response bodies before forwarding them to the client:

Mode Behavior Standard (default) Cloudflare can inspect a prefix of the response body for enabled functionality. None No buffering. The response body streams directly to the client without inspection.

Warning

Setting body buffering to None may break security functionality that requires body inspection, including the Web Application Firewall (WAF) and Bot Management. Ensure that any paths where you disable buffering do not require security inspection.

Availability

These settings only take effect on zones running Cloudflare's latest CDN proxy. Enterprise customers can contact their account team to enable the latest proxy on their zones.

API example

{
  "action": "set_config",
  "action_parameters": {
    "request_body_buffering": "standard",
    "response_body_buffering": "none"
  }
}

For more information, refer to Configuration Rules.

Original source

New functions

Cloudflare Rulesets now includes encode_base64() and sha256() functions, enabling you to generate signed request headers directly in rule expressions. These functions support common patterns like constructing a canonical string from request attributes, computing a SHA256 digest, and Base64-encoding the result.

Function Description Availability

Function Description Availability encode_base64(input, flags) Encodes a string to Base64 format. Optional flags parameter: u for URL-safe encoding, p for padding (adds = characters to make the output length a multiple of 4, as required by some systems). By default, output is standard Base64 without padding. All plans (in header transform rules) sha256(input) Computes a SHA256 hash of the input string. Requires enablement

Note

The sha256() function is available as an Enterprise add-on and requires a specific entitlement. Contact your account team to enable it.

Examples

Encode a string to Base64 format:

encode_base64("hello world")

Returns:

aGVsbG8gd29ybGQ

Encode a string to Base64 format with padding:

encode_base64("hello world", "p")

Returns:

aGVsbG8gd29ybGQ=

Perform a URL-safe Base64 encoding of a string:

encode_base64("hello world", "u")

Returns:

aGVsbG8gd29ybGQ

Compute the SHA256 hash of a secret token:

sha256("my-token")

Returns a hash that your origin can validate to authenticate requests.

Compute the SHA256 hash of a string and encode the result to Base64 format:

encode_base64(sha256("my-token"))

Combines hashing and encoding for systems that expect Base64-encoded signatures.

For more information, refer to the Functions reference.

Original source