Changelog

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

You can now restrict who can access a Quick Tunnel. Use the new --allowed-mail flag in cloudflared to require visitors to authenticate with a one-time PIN sent to their email before they reach your local service.

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

Previously, anyone with a trycloudflare.com URL could access the service behind it. Protected Quick Tunnels let you share a local development server, webhook receiver, or demo with specific people without creating a Cloudflare account or configuring a domain.

You can allow:

• A single email address: --allowed-mail alice@example.com
• Multiple email addresses, by repeating the flag or using a comma-separated list: --allowed-mail 'alice@example.com,bob@example.com'
• Every address on a domain: --allowed-mail '*@example.com'

Visitors do not need a Cloudflare account. Access ends for everyone when you stop the cloudflared process.

To get started, update cloudflared to the latest version and refer to Restrict access by email.

You can now tell a person on a laptop apart from a Mesh node or an AI agent running on Workers, without matching on connector email addresses or Mesh IP ranges — and see exactly which Cloudflare Tunnel and cloudflared replica received each session.

Gateway network logs and Zero Trust Network Session Logs now identify two new kinds of traffic:

• Mesh — Traffic sent from or delivered to a Cloudflare Mesh node. Previously, Mesh nodes were logged the same way as devices running the Cloudflare One Client, because Mesh nodes run the client in headless mode.
• Workers VPC — Traffic sent by a Worker through a Workers VPC binding. Previously, Workers VPC sessions were not recorded in Network Session Logs.

To view these values in the dashboard, go to Zero Trust > Insights & Logs > Logs > Network logs, select Columns, and turn on Traffic Source and Traffic Destination. Both values also appear under Network query details when you open a log entry.

The zero_trust_network_sessions dataset, available through Logpush, includes the following fields:

For example, OnrampType = 'WORKERS_VPC' AND Offramp = 'MESH' returns every session where a Worker reached a service behind a Mesh node, and SourceName tells you which Worker it was.

With DestinationReplicaID, you can now confirm which Cloudflare Tunnel and which cloudflared replica received traffic for a specific session. Combine it with the existing DestinationTunnelID field to trace a session to an exact tunnel replica — or Mesh node replica — when you run multiple replicas for high availability. The replica ID matches the Connector ID shown in the dashboard, so you can stream that replica's logs with cloudflared tail --connector-id.

Sessions logged before this change are not backfilled. For all available fields, refer to Zero Trust Network Session Logs.

Cloudflare Advanced Network Firewall Managed Rulesets are now supported for accounts using Unified Routing mode.

For the full list of feature availability, refer to Check feature availability before upgrading.

Unified Routing is generally available for Cloudflare WAN and Magic Transit.

Unified Routing improves the integration between Cloudflare One and the standard connectivity onramps supported by Cloudflare WAN. It is capable of many new features including Automatic Return Routing, BGP and custom client subnets.

We recommend Unified Routing for all new accounts.

For details, refer to Cloudflare WAN traffic steering and Magic Transit traffic steering.

Starting in 2027, Cloudflare will deprecate 32-bit Windows and Intel-based macOS builds of cloudflared. After the deprecation takes effect, Cloudflare will no longer publish new cloudflared releases for either architecture.

Windows 10, the last Windows release to support 32-bit systems, reached end of support in October 2025. Apple has also deprecated Intel-based Mac computers. macOS 26 Tahoe, released in September 2025, was the final macOS release to support Intel-based Macs. macOS 27, released in September 2026, no longer supports them.

Focusing development on currently supported architectures allows cloudflared to align with operating system support and continue receiving updates on supported platforms. For available downloads and supported platforms, refer to the Cloudflare Tunnel downloads documentation.

You can now define custom applications for breakout and prioritized traffic on the Cloudflare One Appliance directly from the dashboard, without calling the API.

• In Traffic Steering > Breakout traffic or Prioritized traffic, select Assign application traffic > Add to create a custom application matched by Hostnames, IP subnets, and/or the new Source subnets field, alongside Cloudflare-managed applications.
• Edit or delete an existing custom application from the same panel, no API round-trip required.
• Source subnets lets you match traffic by its source IP range, complementing the existing source LAN interface breakout criteria.

This complements the existing API and Terraform workflow for managing applications.

For details, refer to Breakout traffic and Prioritized traffic.

You can now configure custom DHCP options directly from the dashboard when the Cloudflare One Appliance is acting as the DHCP server for a LAN.

• In LAN configuration, under DHCP server options, select Add DHCP option to choose from common options for PXE / iPXE boot, VoIP phone provisioning, and vendor-specific configuration, or select Add custom option to enter your own option code, type, and value.
• This complements the existing API and Terraform workflow for configuring DHCP options.

For details, refer to DHCP server options.

You can now create multiple Cloudflare Tunnel and Cloudflare Mesh routes from the Routes page in a single action, instead of submitting one route at a time.

When creating a route, you can now:

• Add multiple destinations at once — Enter a comma-separated list of CIDR ranges or hostnames to create several routes of the same type and connector together.
• Queue up multiple routes — Select Add another to stage additional routes, including different types or connectors, before creating them all in one action.
• Retry only what failed — If some routes in a batch fail (for example, an invalid CIDR), the routes that were created successfully are removed from the form automatically, so you only need to fix and resubmit the ones that failed.

The same Routes UI already supports bulk creation for Cloudflare WAN static routes, so you can add multiple WAN destinations or queue up several WAN routes before creating them together as well.

For setup steps, refer to Add routes.

When you register a Cloudflare One Virtual Appliance, you can now select your hypervisor and download the appliance directly from the dashboard — no need to look up asset URLs.

• On the Connectors page, select Add an appliance, choose Virtual appliance, then select your hypervisor: VMware ESXi, Proxmox, or libvirt/KVM.
• Download the OVA image (VMware ESXi) or the install script (Proxmox and libvirt/KVM) for the selected hypervisor.
• Use View setup guide to open deployment instructions for your platform.

This complements the existing self-serve registration and license key generation in the dashboard.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Cloudflare Advanced Network Firewall Threat Intel Lists are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Rate Limiting and Managed Rulesets - is planned.

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

You can now configure origin application settings directly in the Cloudflare dashboard when adding or editing a published application route for a Cloudflare Tunnel. These settings control how cloudflared connects to your origin server and were previously only available in the Cloudflare One dashboard or via local configuration files.

When editing a published application, expand Additional application settings to configure parameters organized into three categories:

• HTTP — Set a custom HTTP Host header or disable chunked encoding.
• TLS — Configure origin server name, CA pool, TLS timeout, disable TLS verification, match SNI to host, or enable HTTP/2 to origin.
• Connection — Tune connect timeout, keep-alive timeout, keep-alive connections, TCP keep-alive interval, proxy type, or disable Happy Eyeballs.

For the full list of origin parameters, refer to Origin parameters.

Hostname routing ↗︎ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

• Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
• Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗︎, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

• Private and public hostname routing for Cloudflare Tunnel
• Hostname routes for Cloudflare Mesh
• Access private applications on non-HTTPS ports
• Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Networking > IP addresses > Address space > Custom IPs, or using the Initial Resolved IP Subnet API.

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

The default IPv4 range, and all Cloudflare One IPv6 ranges, are automatically routed through the Cloudflare One Client and do not require any Split Tunnel configuration. Refer to Automatically managed ranges for details.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

• Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
• Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

For more information, refer to Tunnel observability and Tunnel log streams.

You can now restart, reboot, or shut down a Cloudflare One Appliance directly from the dashboard or via API.

• Restart — Restart managed services. Purges temporary and (optionally) persistent state.
• Reboot — Power cycle the appliance. Optionally, purge persistent state. Re-applies configuration starting from scratch.
• Shutdown — Power off the appliance. Optionally, purge persistent state. The machine will be offline until manually powered on again.

In the dashboard, go to Networking > Connectors > Appliances, select an appliance, then Edit > Operations to send an operation. Via API, POST to the /accounts/{account_id}/magic/connectors/{connector_id}/interrupts endpoint.

For details, refer to Appliance operations.

On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

Deprecated endpoints (removed October 5, 2026):

• Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Update a tunnel route (CIDR Endpoint): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
• Delete a tunnel route (CIDR Endpoint): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

Replacement endpoints:

• Create a tunnel route: POST /accounts/{account_id}/teamnet/routes
• Update a tunnel route: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
• Delete a tunnel route: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

1. Capture each route's route_id by calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint.
2. Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
3. If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗︎.
4. If you manage routes with Terraform, make sure you are on a current version of the cloudflare_zero_trust_tunnel_cloudflared_route ↗︎ resource and the Cloudflare Terraform provider ↗︎.

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"comment": "Updated comment for this route."}'

curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.

This affects:

• GET /accounts/{account_id}/cfd_tunnel — connections removed from each item in result
• GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
• GET /accounts/{account_id}/warp_connector — connections removed from each item in result
• GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Update any dashboards, monitoring scripts, or automation that parses connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

• Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.
• A single way to identify a route. Consolidating on route_id removes the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed.
• Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.

To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.

Cloudflare IPsec now supports the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗︎ IKEv2 extension to protect against downgrade attacks on IPsec tunnels.

IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗︎ can exploit this to bypass post-quantum key exchange by downgrading the connection to classical cryptography. The IKE_SA_INIT_FULL_TRANSCRIPT_AUTH extension addresses this by having both peers sign the entire handshake transcript during the authentication exchange, preventing an attacker from manipulating the negotiation without detection.

Key details:

• Available in beta for Cloudflare WAN and Magic Transit IPsec tunnels.
• Cloudflare sends the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification unconditionally as a responder when the feature flag is enabled.
• Both the initiator (your device) and responder (Cloudflare) must support the extension for downgrade protection to be effective.
• This feature is currently gated by a per-account feature flag. Contact your account team to turn it on.

Refer to Downgrade protection for more details.

Cloudflare Advanced Network Firewall IP lists, IDS, and SIP rules are now supported for accounts using Unified Routing mode. These features require a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Threat Intel Lists, Rate Limiting, and Managed Rulesets - is planned.

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

You can now register a Cloudflare One Virtual Appliance and generate its license key directly from the dashboard, without contacting your account team.

• On the Connectors page, select Add an appliance and choose Virtual appliance to register a virtual appliance and generate its authentication key.
• Use Regenerate authentication key from a virtual appliance connector's menu to rotate its key. The previous key is immediately and irrevocably revoked.
• The authentication key is shown only once — copy and store it securely.

This complements the existing API and Terraform self-serve workflow for provisioning virtual appliances. Hardware appliances continue to use the existing account-team fulfillment workflow.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Regional Services now supports Regionalized IP Bindings, letting you regionalize traffic at the IP layer for prefixes you bring to Cloudflare through Bring Your Own IP (BYOIP).

Where Regional Hostnames regionalize traffic by hostname, Regionalized IP Bindings let you bind a CIDR from one of your prefixes to a region — ideal for address-map deployments and any service you address by IP rather than hostname. Cloudflare then terminates TLS and processes traffic to those addresses only within the data centers in that region.

Regionalized IP Bindings requires the Regional Services and Regional Services for BYOIP entitlements. Contact your account team to enable them.

To get started, refer to Regionalized IP Bindings.

The Routes page in the Cloudflare dashboard now shows the routes across all of your connectors — Cloudflare Mesh and Cloudflare Tunnel routes alongside Cloudflare WAN and Magic Transit static routes — in a single table, instead of a separate routes view per product.

From the unified Routes page you can:

• Visualize your network with an interactive map that shows how your destinations flow through to your connectors — including equal-cost multi-path (ECMP) routes where the same prefix is served by several connectors. Select a node to filter the table down to the routes behind it.
• See every route in one table, with its destination, type, connector, priority, and source, and filter or sort to find what you need.
• Create, edit, and delete routes of any supported type without leaving the page. When adding a Cloudflare WAN or Magic Transit static route, you now pick the next hop by connector name instead of typing its IP.
• Manage virtual networks from a dedicated tab.
• Test a route to see which connector and next hop a destination resolves to before you commit a change.

To find it, go to Networking > Routes in the dashboard sidebar.

Your existing routes, APIs, and configurations are unchanged — this is a dashboard experience that brings them together in one place. Learn how to add routes and manage virtual networks.

The Cisco IOS XE third-party integration guide for Cloudflare WAN has been updated to include:

• Post Quantum Cryptography (PQC)
• Policy-Based Routing (PBR)
• IP Service Level Agreement (IP SLA)

This link will take you directly to the updated Cisco IOS XE guide.

Starting with cloudflared version 2026.5.2 ↗︎, Cloudflare Tunnel automates the entire connectivity pre-checks workflow directly inside the binary. Previously, customers had to install dig and netcat and run those commands by hand to verify their environment. Now cloudflared does it natively at startup — and surfaces actionable remediation when something is blocked.

On every cloudflared tunnel run (and cloudflared tunnel diag), the binary now natively checks:

• DNS resolution — region1.v2.argotunnel.com and region2.v2.argotunnel.com resolve to valid Cloudflare IPs.
• Transport connectivity — outbound UDP (QUIC) and TCP (HTTP/2) on port 7844.
• Management API — outbound TCP/443 to api.cloudflare.com for software updates.

Results are printed in a scannable CLI table with three states:

• ✅ Pass — the check succeeded.
• ⚠️ Warn — a non-blocking issue, for example the Management API is unreachable so automatic updates will not work, but the tunnel will still come up.
• ❌ Fail — a blocking issue, with a specific remediation hint (for example, Allow outbound UDP on port 7844).

If DNS is unresolvable, or both UDP and TCP fail on port 7844, cloudflared exits early with the failure rather than looping on opaque failed to dial errors.

Pre-checks now run automatically on every start, which also catches regressions like overnight firewall policy changes — no need to remember to rerun the troubleshooting guide.

To get the new behavior, upgrade cloudflared to version 2026.5.2 or later. For more details, refer to the Connectivity pre-checks documentation.

You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

• Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
• Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
• Scope a single policy to one or many Tunnels and Mesh nodes at once.

Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

• Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.
• Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.
• Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

• Configure granular permissions for Cloudflare Tunnel.
• Configure granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One.
• Review the resource-scoped roles on the Cloudflare role reference.

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.