Changelog

All bidirectional tunnel health check return packets are accepted by any Magic on-ramp.

Previously, when a Magic tunnel had a bidirectional health check configured, the bidirectional health check would pass when the return packets came back to Cloudflare over the same tunnel that was traversed by the forward packets.

There are SD-WAN devices, like VeloCloud, that do not offer controls to steer traffic over one tunnel versus another in a high availability tunnel configuration.

Now, when a Magic tunnel has a bidirectional health check configured, the bidirectional health check will pass when the return packet traverses over any tunnel in a high availability configuration.

Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.

No action is required if you already explicitly set is_deleted=false or if you only need to list active resources.

This change affects the following API endpoints:

• List all tunnels: GET /accounts/{account_id}/tunnels
• List Cloudflare Tunnels: GET /accounts/{account_id}/cfd_tunnel
• List WARP Connector tunnels: GET /accounts/{account_id}/warp_connector
• List tunnel routes: GET /accounts/{account_id}/teamnet/routes
• List subnets: GET /accounts/{account_id}/zerotrust/subnets
• List virtual networks: GET /accounts/{account_id}/teamnet/virtual_networks

The default behavior of the is_deleted query parameter will be updated.

If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.

To get a list of only deleted resources, you must now explicitly add the is_deleted=true query parameter to your request:

# Example: Get ONLY deleted Tunnels
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \
     -H "Authorization: Bearer $API_TOKEN"

# Example: Get ONLY deleted Virtual Networks
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \
     -H "Authorization: Bearer $API_TOKEN"

Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using is_deleted=false) and one to get deleted items (is_deleted=true).

This update is based on user feedback and aims to:

• Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
• Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
• Improve performance: For most users, the default query result will now be smaller and more relevant.

To learn more, please visit the Cloudflare Tunnel API and Zero Trust Networks API documentation.

The Cloudflare Terraform provider resources for Cloudflare WAN tunnels and routes now support Terraform provider version 5. Customers using infrastructure-as-code workflows can manage their tunnel and route configuration with the latest provider version.

For more information, refer to the Cloudflare Terraform provider documentation ↗︎.

Today, we are excited to announce that all Magic Transit and Magic WAN customers with CMB EU (Customer Metadata Boundary - Europe) enabled in their account will be able to access GRE, IPsec, and CNI health check and traffic volume data in the Cloudflare dashboard and via API.

This ensures that all Magic Transit and Magic WAN customers with CMB EU enabled will be able to access all Magic Transit and Magic WAN features.

Specifically, these two GraphQL endpoints are now compatible with CMB EU:

• magicTransitTunnelHealthChecksAdaptiveGroups
• magicTransitTunnelTrafficAdaptiveGroups

The KVM-based virtual Cloudflare One Appliance is now in open beta with official support for Proxmox VE.

Customers can deploy the virtual appliance on KVM hypervisors to connect branch or data center networks to Cloudflare WAN without dedicated hardware.

For setup instructions, refer to Configure a virtual Cloudflare One Appliance.

Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.

This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.

What’s new:

• Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
• Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.

Learn more about running TCP or UDP applications and private networks through Cloudflare Tunnel.

Cloudflare One Appliance DHCP server settings now support specifying multiple DNS server IP addresses in the DHCP pool.

Previously, customers could only configure a single DNS server per DHCP pool. With this update, you can specify multiple DNS servers to provide redundancy for clients at branch locations.

For configuration details, refer to DHCP server.

Magic Firewall now supports a new managed list of Cloudflare IP ranges. This list is available as an option when creating a Magic Firewall policy based on IP source/destination addresses. When selecting "is in list" or "is not in list", the option "Cloudflare IP Ranges" will appear in the dropdown menu.

This list is based on the IPs listed in the Cloudflare IP ranges ↗︎. Updates to this managed list are applied automatically.

Note: IP Lists require a Cloudflare Advanced Network Firewall subscription. For more details about Cloudflare Network Firewall plans, refer to Plans.

You can now locally configure your Magic WAN Connector to work in a static IP configuration.

This local method does not require having access to a DHCP Internet connection. However, it does require being comfortable with using tools to access the serial port on Magic WAN Connector as well as using a serial terminal client to access the Connector's environment.

For more details, refer to WAN with a static IP address.

The latest cloudflared build 2024.12.2 ↗︎ introduces the ability to collect all the diagnostic logs needed to troubleshoot a cloudflared instance.

A diagnostic report collects data from a single instance of cloudflared running on the local machine and outputs it to a cloudflared-diag file.

For more information, refer to Diagnostic logs.

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 a Direct CNI on-ramp.

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 CNI.
• Secure the session by MD5 authentication to prevent misconfigurations.
• Exchange routes dynamically between their devices and their Magic routing table.

Refer to Magic WAN BGP peering or Magic Transit BGP peering to learn more about this feature and how to set it up.

You can now generate customized terraform files for building cloud network on-ramps to Magic WAN.

Magic Cloud can scan and discover existing network resources and generate the required terraform files to automate cloud resource deployment using their existing infrastructure-as-code workflows for cloud automation.

You might want to do this to:

• Review the proposed configuration for an on-ramp before deploying it with Cloudflare.
• Deploy the on-ramp using your own infrastructure-as-code pipeline instead of deploying it with Cloudflare.

For more details, refer to Set up with Terraform.

The Magic Firewall dashboard now allows you to search custom rules using the rule name and/or ID.

1. Log into the Cloudflare dashboard ↗︎ and select your account.
2. Go to Analytics & Logs > Network Analytics.
3. Select Magic Firewall.
4. Add a filter for Rule ID.

Additionally, the rule ID URL link has been added to Network Analytics.

Welcome to your new home for product updates on Cloudflare One.

Our new changelog lets you read about changes in much more depth, offering in-depth examples, images, code samples, and even gifs.

If you are looking for older product updates, refer to the following locations.