Network Security Updates & Release Notes

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 and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta).

Using BGP peering allows customers to:

• Automate the process of adding or removing networks and subnets.
• Take advantage of failure detection and session recovery features.

With this functionality, customers can:

• Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps.
• Secure the session by MD5 authentication to prevent misconfigurations.
• Exchange routes dynamically between their devices and their Magic routing table.

For configuration details, refer to:

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

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

Cloudflare Rulesets

Cloudflare Rulesets now include new functions that enable advanced expression logic for evaluating arrays and maps. These functions allow you to build rules that match against lists of values in request or response headers, enabling use cases like country-based blocking using custom headers.

New functions

Function Description split(source, delimiter) Splits a string into an array of strings using the specified delimiter. join(array, delimiter) Joins an array of strings into a single string using the specified delimiter. has_key(map, key) Returns true if the specified key exists in the map. has_value(map, value) Returns true if the specified value exists in the map.

Example use cases

Check if a country code exists in a header list:

has_value(split(http.response.headers["x-allow-country"][0], ","), ip.src.country)

Check if a specific header key exists:

has_key(http.request.headers, "x-custom-header")

Join array values for logging or comparison:

join(http.request.headers.names, ", ")

For more information, refer to the Functions reference.

Original source

The Network Services menu structure in Cloudflare's dashboard has been updated to reflect solutions and capabilities instead of product names. This will make it easier for you to find what you need and better reflects how our services work together.

Your existing configurations will remain the same, and you will have access to all of the same features and functionality.

The changes visible in your dashboard may vary based on the products you use. Overall, changes relate to Magic Transit, Magic WAN, and Magic Firewall.

Summary of changes

• A new Overview page provides access to the most common tasks across Magic Transit and Magic WAN.
• Product names have been removed from top-level navigation.
• Magic Transit and Magic WAN configuration is now organized under Routes and Connectors. For example, you will find IP Prefixes under Routes, and your GRE/IPsec Tunnels under Connectors.
• Magic Firewall policies are now called Firewall Policies.
• Magic WAN Connectors and Connector On-Ramps are now referenced in the dashboard as Appliances and Appliance profiles. They can be found under Connectors > Appliances.
• Network analytics, network health, and real-time analytics are now available under Insights.
• Packet Captures are found under Insights > Diagnostics.
• You can manage your Sites from Insights > Network health.
• You can find Magic Network Monitoring under Insights > Network flow.

If you would like to provide feedback, complete this form. You can also find these details in the January 7, 2026 email titled [FYI] Upcoming Network Services Dashboard Navigation Update.

Original source

The ip.src.metro_code field in the Ruleset Engine is now populated with DMA (Designated Market Area) data. You can use this field to build rules that target traffic based on geographic market areas, enabling more granular location-based policies for your applications.

Field details

• Field: ip.src.metro_code
• Type: String | null
• Description: The metro code (DMA) of the incoming request's IP address. Returns the designated market area code for the client's location.

Example filter expression:

ip.src.metro_code eq "501"

For more information, refer to the Fields reference.

Original source

NetFlow export for Magic WAN Connector

Magic WAN Connector now exports NetFlow data for breakout traffic to Magic Network Monitoring (MNM), providing visibility into traffic that bypasses Cloudflare's security filtering.

• Monitor breakout traffic statistics in the Cloudflare dashboard.
• View traffic patterns for applications configured to bypass Cloudflare.
• Maintain visibility across all traffic passing through your Magic WAN Connector.

For more information, refer to NetFlow statistics.

Original source

Magic WAN Connector

Magic WAN Connector now allows you to designate a specific WAN port for breakout traffic, giving you deterministic control over the egress path for latency-sensitive applications.

• Pin breakout traffic for specific applications to a preferred WAN port.
• Ensure critical traffic (such as Zoom or Teams) always uses your fastest or most reliable connection.
• Benefit from automatic failover to standard WAN port priority if the preferred port goes down.

This is useful for organizations with multiple ISP uplinks who need predictable egress behavior for performance-sensitive traffic.

For configuration details, refer to Designate WAN ports for breakout apps.

Original source

Magic WAN now supports Automatic Return Routing (ARR)

Magic WAN now supports Automatic Return Routing (ARR), allowing customers to configure Magic on-ramps (IPsec/GRE/CNI) to learn the return path for traffic flows without requiring static routes.

Key benefits

• Route-less mode: Static or dynamic routes are optional when using ARR.
• Overlapping IP space support: Traffic originating from customer sites can use overlapping private IP ranges.
• Symmetric routing: Return traffic is guaranteed to use the same connection as the original on-ramp.

This feature is currently in Beta and requires the new Unified Routing mode.

For configuration details, refer to Configure Automatic Return Routing.

Original source

Cloudflare now provides two new request fields in the Ruleset engine that let you make decisions based on whether a request used TCP and the measured TCP round-trip time between the client and Cloudflare. These fields help you understand protocol usage across your traffic and build policies that respond to network performance. For example, you can distinguish TCP from QUIC traffic or route high latency requests to alternative origins when needed.

New fields

| Field | Type | Description |
| cf.edge.client_tcp | Boolean | Indicates whether the request used TCP. A value of true means the client connected using TCP instead of QUIC. |
| cf.timings.client_tcp_rtt_msec | Number | Reports the smoothed TCP round-trip time between the client and Cloudflare in milliseconds. For example, a value of 20 indicates roughly twenty milliseconds of RTT. |

Example filter expression:

cf.edge.client_tcp && cf.timings.client_tcp_rtt_msec < 100

More information can be found in the Rules language fields reference.

Original source