--- title: Network security Changelog image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png --- > Documentation Index > Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt > Use this file to discover all available pages before exploring further. [Skip to content](#%5Ftop) # Changelog New updates and improvements at Cloudflare. [ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) Network security ![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) Jul 09, 2026 1. ### [Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-09-tunnel-routes-and-connections-api-changes/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare Tunnel for SASE ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/)[ Cloudflare Mesh ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/) On **October 5, 2026**, two changes take effect across the [Zero Trust Networks API](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/) and [Cloudflare Tunnel API](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/): 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. #### Route endpoints 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) or [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/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}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/subresources/networks/methods/create/) * Update a tunnel route (CIDR Endpoint): [PATCH /accounts/{account\_id}/teamnet/routes/network/{ip\_network\_encoded}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/subresources/networks/methods/edit/) * Delete a tunnel route (CIDR Endpoint): [DELETE /accounts/{account\_id}/teamnet/routes/network/{ip\_network\_encoded}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/subresources/networks/methods/delete/) **Replacement endpoints:** * Create a tunnel route: [POST /accounts/{account\_id}/teamnet/routes](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/methods/create/) * Update a tunnel route: [PATCH /accounts/{account\_id}/teamnet/routes/{route\_id}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/methods/edit/) * Delete a tunnel route: [DELETE /accounts/{account\_id}/teamnet/routes/{route\_id}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/methods/delete/) #### What is changing | | Deprecated (CIDR-encoded path) | Replacement | | ---------------- | -------------------------------------------------------------- | ------------------------------------------------------------------- | | Route identifier | URL-encoded CIDR in the path (/network/{ip\_network\_encoded}) | route\_id in the path (network moves to the request body on create) | | Create | POST .../teamnet/routes/network/{ip\_network\_encoded} | POST .../teamnet/routes with network and tunnel\_id in the body | | Update | PATCH .../teamnet/routes/network/{ip\_network\_encoded} | PATCH .../teamnet/routes/{route\_id} | | Delete | DELETE .../teamnet/routes/network/{ip\_network\_encoded} | DELETE .../teamnet/routes/{route\_id} | #### Action required 1. Capture each route's `route_id` by calling [List tunnel routes](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/subresources/routes/methods/list/), 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 ↗](https://github.com/cloudflare/cloudflared/releases). 4. If you manage routes with Terraform, make sure you are on a current version of the [cloudflare\_zero\_trust\_tunnel\_cloudflared\_route ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/resources/zero%5Ftrust%5Ftunnel%5Fcloudflared%5Froute) resource and the [Cloudflare Terraform provider ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs). ```bash # 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" ``` #### Cloudflare Tunnel and Cloudflare Mesh connections Starting the same day, the `connections` array is removed from list and get responses for [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) and [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/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](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/cloudflared/methods/list/) — `connections` removed from each item in `result` * [GET /accounts/{account\_id}/cfd\_tunnel/{tunnel\_id}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/cloudflared/methods/get/) — `connections` removed from `result` * [GET /accounts/{account\_id}/warp\_connector](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/warp%5Fconnector/methods/list/) — `connections` removed from each item in `result` * [GET /accounts/{account\_id}/warp\_connector/{tunnel\_id}](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/warp%5Fconnector/methods/get/) — `connections` removed from `result` #### Action required 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](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/cloudflared/subresources/connections/methods/get/). For Cloudflare Mesh, call [GET /accounts/{account\_id}/warp\_connector/{tunnel\_id}/connections](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/subresources/warp%5Fconnector/subresources/connections/methods/get/). ```bash # 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. #### Why we are making these changes * **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](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/networks/), the [Cloudflare Tunnel API](https://edgetunnel-b2h.pages.dev/api/resources/zero%5Ftrust/subresources/tunnels/), and [Routes](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/routes/) documentation. Jul 08, 2026 1. ### [IPsec downgrade protection (beta)](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-08-ipsec-downgrade-protection/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) Cloudflare IPsec now supports the [IKE\_SA\_INIT\_FULL\_TRANSCRIPT\_AUTH ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-downgrade-prevention/) 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 ↗](https://www.cloudflare.com/learning/security/threats/on-path-attack/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/gre-ipsec-tunnels/#improved-downgrade-protection-beta) for more details. Jul 06, 2026 1. ### [Self-serve registration of Cloudflare One Virtual Appliance in the dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-07-06-virtual-appliance-self-serve-ui/) [ Cloudflare One Appliance ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) You can now register a [Cloudflare One Virtual Appliance](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/) and generate its license key directly from the dashboard, without contacting your account team. ![Registering a Cloudflare One Virtual Appliance and generating its authentication key from the Connectors page](https://edgetunnel-b2h.pages.dev/_astro/2026-07-06-virtual-appliance-self-serve-ui.Dn2NC_ql_1WdiRS.webp) * 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/configure-virtual-appliance/#register-a-virtual-appliance-and-generate-a-license-key) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/configure-virtual-appliance/). Jun 23, 2026 1. ### [Regionalized IP Bindings for Regional Services](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-23-regionalized-ip-bindings/) [ Data Localization Suite ](https://edgetunnel-b2h.pages.dev/data-localization/) 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)](https://edgetunnel-b2h.pages.dev/byoip/). Where [Regional Hostnames](https://edgetunnel-b2h.pages.dev/data-localization/regional-services/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](https://edgetunnel-b2h.pages.dev/data-localization/regional-services/ip-bindings/). Jun 19, 2026 1. ### [Manage all your routes from one page in the dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-19-unified-routes-page/) [ Cloudflare Mesh ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/)[ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/) The **Routes** page in the Cloudflare dashboard now shows the routes across all of your connectors — [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/) and [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/) routes alongside [Cloudflare WAN](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) and [Magic Transit](https://edgetunnel-b2h.pages.dev/magic-transit/) static routes — in a single table, instead of a separate routes view per product. ![The unified Routes page in the Cloudflare dashboard, showing routes across connectors in a single table](https://edgetunnel-b2h.pages.dev/_astro/2026-06-19-unified-routes.B3igBY20_Z1awHp.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/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. [ Go to **Routes** ](https://dash.cloudflare.com/?to=/:account/magic-networks/routes) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/routes/add-routes/) and [manage virtual networks](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/virtual-networks/). Jun 02, 2026 1. ### [Cisco IOS XE](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-02-cisco-ios-xe/) [ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/third-party/cisco-ios-xe/) guide. May 27, 2026 1. ### [Cloudflare Tunnel now runs connectivity pre-checks at startup](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-27-cloudflared-connectivity-prechecks/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare Tunnel for SASE ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) Starting with [cloudflared version 2026.5.2 ↗](https://github.com/cloudflare/cloudflared/releases), [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/) automates the entire [connectivity pre-checks workflow](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/connectivity-prechecks/) 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. ![cloudflared connectivity pre-checks output](https://edgetunnel-b2h.pages.dev/_astro/cloudflared-connectivity-prechecks.DRwN6tGe_c1XGu.webp) 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](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/connectivity-prechecks/). May 21, 2026 1. ### [Granular permissions for Cloudflare Tunnel and Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-21-tunnel-mesh-granular-permissions/) [ Cloudflare Fundamentals ](https://edgetunnel-b2h.pages.dev/fundamentals/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare Tunnel for SASE ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/)[ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare Mesh ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/) You can now scope Cloudflare permissions to individual [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/) instances and [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/) nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking. #### What is new When you [add a member](https://edgetunnel-b2h.pages.dev/fundamentals/manage-members/manage/) or create a [permission policy](https://edgetunnel-b2h.pages.dev/fundamentals/manage-members/policies/), the resource picker now lists [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/) instances and [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/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. #### How it works 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. #### Get started * Configure [granular permissions for Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/tunnel/advanced/granular-permissions/). * Configure [granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/granular-permissions/). * Review the [resource-scoped roles](https://edgetunnel-b2h.pages.dev/fundamentals/manage-members/roles/#resource-scoped-roles) on the Cloudflare role reference. May 18, 2026 1. ### [Network Analytics support for Unified Routing](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-18-unified-routing-network-analytics/) [ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Magic Transit ](https://edgetunnel-b2h.pages.dev/magic-transit/) [Network Analytics](https://edgetunnel-b2h.pages.dev/analytics/network-analytics/) is now fully supported for accounts using [Unified Routing](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/traffic-steering/#unified-routing-mode-beta) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/traffic-steering/#beta-limitations). May 12, 2026 1. ### [New accounts assigned a single IPv4 anycast address](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-12-single-anycast-ip-default/) [ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Magic Transit ](https://edgetunnel-b2h.pages.dev/magic-transit/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/how-to/configure-tunnel-endpoints/) for Cloudflare WAN or [Configure tunnel endpoints](https://edgetunnel-b2h.pages.dev/magic-transit/how-to/configure-tunnel-endpoints/) for Magic Transit. May 11, 2026 1. ### [NAT-T support for IKE on UDP port 500](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-11-nat-t-port-500/) [ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Magic Transit ](https://edgetunnel-b2h.pages.dev/magic-transit/) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/gre-ipsec-tunnels/). May 07, 2026 1. ### [Custom DHCP options on Cloudflare One Appliance](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-07-appliance-dhcp-options/) [ Cloudflare One Appliance ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) When the Cloudflare One Appliance is acting as the DHCP server for a LAN, you can now configure custom DHCP options on the leases it issues. This unlocks workflows such as PXE / iPXE boot, VoIP phone provisioning, and vendor-specific client configuration. Each option is defined by `option_number`, `value`, and one of four value types: `text`, `integer`, `hex`, or `ip`. Configurations are validated on the appliance before being applied — invalid configurations are rejected and the underlying error is returned to the API caller, so a bad option will not disrupt the live DHCP service. For details, refer to [DHCP server options](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/network-options/dhcp/dhcp-options/). May 07, 2026 1. ### [Source-based breakout and prioritization on Cloudflare One Appliance](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-07-appliance-source-based-breakout/) [ Cloudflare One Appliance ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) Breakout and traffic prioritization rules on the Cloudflare One Appliance can now match by **source** in addition to destination application. You can pin breakout or priority behavior to: * A source LAN interface — VLANs attached to that LAN are included automatically. * A source IP address, range, or CIDR block. This is the natural way to break out a guest VLAN to the local Internet, or to prioritize traffic from a specific subnet, without enumerating destination applications. For details, refer to [Breakout traffic](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/network-options/application-based-policies/breakout-traffic/#breakout-by-source). May 07, 2026 1. ### [Self-serve provisioning of Cloudflare One Virtual Appliance via API](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-07-virtual-appliance-self-serve-api/) [ Cloudflare One Appliance ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) You can now create, rotate, and delete Cloudflare One Virtual Appliance instances and their license keys directly via the API and Terraform. * Create a virtual appliance and receive a license key: `POST /accounts/{account_id}/magic/connectors` with `device.provision_license: true`. * Rotate the license key for an existing virtual appliance: `PATCH /accounts/{account_id}/magic/connectors/{connector_id}` with `provision_license: true`. The previous key is immediately and irrevocably revoked. * Delete a virtual appliance to release the associated licensed device. The license key is returned in the response only once, at create or rotate time. Copy and store it securely. For details, refer to [Configure a Cloudflare One Virtual Appliance](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/configure-virtual-appliance/). Apr 30, 2026 1. ### [Post-quantum IPsec interoperability with third-party devices](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-30-ipsec-post-quantum-third-party/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) Cloudflare IPsec now supports post-quantum key agreement with compatible third-party devices. [Cisco ↗](https://www.cisco.com/) and [Fortinet ↗](https://www.fortinet.com/) are the first third-party vendors validated to interoperate with Cloudflare IPsec using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). Post-quantum IPsec uses [RFC 9370 ↗](https://datatracker.ietf.org/doc/rfc9370/) and [draft-ietf-ipsecme-ikev2-mlkem ↗](https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-mlkem/) to negotiate hybrid key agreement during the IKEv2 `IKE_INTERMEDIATE` phase. This combines classical Diffie-Hellman (Group 20) with ML-KEM-768 or ML-KEM-1024 to protect against [harvest-now, decrypt-later ↗](https://en.wikipedia.org/wiki/Harvest%5Fnow,%5Fdecrypt%5Flater) attacks. Key details: * Compatible with Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1 and Fortinet FortiOS 7.6.6 and later. * Uses ML-KEM-768 or ML-KEM-1024 as an additional Key Exchange to DH Group 20. * Follows RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem standards. * No additional licensing required. Post-quantum IPsec with third-party devices is now generally available with confirmed interoperability for the platforms listed above. Cloudflare intends to support interoperability with more vendors as they build out support for draft-ietf-ipsecme-ikev2-mlkem. Contact your account team to discuss support for additional vendors. For supported key exchange methods and the list of validated platforms, refer to [GRE and IPsec tunnels](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/gre-ipsec-tunnels/#tested-third-party-vendor-interoperability). Apr 21, 2026 1. ### [Country rules supported in Unified Routing](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-21-unified-routing-geoip-country-rules/) [ Cloudflare Network Firewall ](https://edgetunnel-b2h.pages.dev/cloudflare-network-firewall/)[ Magic Transit ](https://edgetunnel-b2h.pages.dev/magic-transit/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) [Cloudflare Advanced Network Firewall](https://edgetunnel-b2h.pages.dev/cloudflare-network-firewall/) Country rules are now supported for accounts using [Unified Routing](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/traffic-steering/#unified-routing-mode-beta) 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](https://edgetunnel-b2h.pages.dev/cloudflare-wan/reference/traffic-steering/#beta-limitations). Apr 07, 2026 1. ### [Link aggregation (LACP) support for Cloudflare One Appliance](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-07-link-aggregation-lacp-appliance/) [ Cloudflare One Appliance ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/)[ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/) Cloudflare One Appliance now supports Link Aggregation Control Protocol (LACP), allowing you to bundle up to six physical LAN ports into a single logical interface. Link aggregation increases available bandwidth and eliminates single points of failure on the LAN side of the appliance. This feature is available in beta on physical appliance hardware with the latest OS. No entitlement is required. To configure a Link Aggregation Group, refer to [Configure link aggregation groups](https://edgetunnel-b2h.pages.dev/cloudflare-wan/configuration/appliance/network-options/link-aggregation/). Apr 01, 2026 1. ### [New QUIC RTT and delivery rate fields](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-01-l4-transport-telemetry-fields/) [ Rules ](https://edgetunnel-b2h.pages.dev/rules/) Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing [cf.timings.client\_tcp\_rtt\_msec](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/) field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes. Previously, QUIC RTT and delivery rate data was only available via the `Server-Timing: cfL4` response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields. #### New fields | Field | Type | Description | | ---------------------------------- | ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | cf.timings.client\_quic\_rtt\_msec | Integer | The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections. | | cf.edge.l4.delivery\_rate | Integer | The most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request. | #### Example: Route slow connections to a lightweight origin Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant: **Rule expression:** ```txt cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200 ``` **Header modifications:** | Operation | Header name | Value | | --------- | -------------- | ----- | | Set | X-High-Latency | true | #### Example: Match low-bandwidth connections ```txt cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000 ``` For more information, refer to [Request Header Transform Rules](https://edgetunnel-b2h.pages.dev/rules/transform/request-header-modification/) and the [fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/). Mar 25, 2026 1. ### [New mTLS certificate fields for Transform Rules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-25-rfc9440-mtls-fields/) [ Rules ](https://edgetunnel-b2h.pages.dev/rules/) Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in [RFC 9440 ↗](https://www.rfc-editor.org/rfc/rfc9440) format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized `Client-Cert` and `Client-Cert-Chain` header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic. Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, `:MIIDsT...Vw==:`. A chain of intermediates is expressed as a comma-separated list of such values. #### New fields | Field | Type | Description | | ----------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | | cf.tls\_client\_auth.cert\_rfc9440 | String | The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented. | | cf.tls\_client\_auth.cert\_rfc9440\_too\_large | Boolean | true if the leaf certificate exceeded 10 KB and was omitted. In practice this will almost always be false. | | cf.tls\_client\_auth.cert\_chain\_rfc9440 | String | The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB. | | cf.tls\_client\_auth.cert\_chain\_rfc9440\_too\_large | Boolean | true if the intermediate chain exceeded 16 KB and was omitted. | The chain encoding follows the same ordering as the TLS handshake: the certificate closest to the leaf appears first, working up toward the trust anchor. The root certificate is not included. #### Example: Forwarding client certificate headers to your origin server Add a request header transform rule to set the `Client-Cert` and `Client-Cert-Chain` headers on requests forwarded to your origin server. For example, to forward headers for verified, non-revoked certificates: **Rule expression:** ```txt cf.tls_client_auth.cert_verified and not cf.tls_client_auth.cert_revoked ``` **Header modifications:** | Operation | Header name | Value | | --------- | ----------------- | ----------------------------------------- | | Set | Client-Cert | cf.tls\_client\_auth.cert\_rfc9440 | | Set | Client-Cert-Chain | cf.tls\_client\_auth.cert\_chain\_rfc9440 | To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates `cf.tls_client_auth.cert_verified` and `cf.tls_client_auth.cert_revoked`. Prevent header injection You should ensure that `Client-Cert` and `Client-Cert-Chain` headers received by your origin server can only originate from this transform rule — any client could send these headers directly. * **If you use WAF custom rules to block requests with invalid mTLS connections:** The transform rule is sufficient. For all requests that reach your origin server, the rule will overwrite any existing `Client-Cert` and `Client-Cert-Chain` headers. * **If you do not enforce mTLS at the WAF:** Add another transform rule that removes any incoming `Client-Cert` and `Client-Cert-Chain` headers from all requests (use expression `true`), ordered before the rule above. This ensures your origin server cannot receive client-supplied values for these HTTP headers. For more information, refer to [Mutual TLS authentication](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/service-credentials/mutual-tls-authentication/), [Request Header Transform Rules](https://edgetunnel-b2h.pages.dev/rules/transform/request-header-modification/), and the [fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/). Mar 24, 2026 1. ### [Interconnects moved to Connectors](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-24-interconnects-navigation-update/) [ Network Interconnect ](https://edgetunnel-b2h.pages.dev/network-interconnect/) The top-level **Interconnects** page in the Cloudflare dashboard has been removed. Interconnects are now located under **Connectors** \> **Interconnects**. Your existing configurations and functionality remain the same. Mar 20, 2026 1. ### [Stream logs from multiple replicas of Cloudflare Tunnel simultaneously](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-20-tunnel-replica-overview-and-multi-log-streaming/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare Tunnel for SASE ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all [replicas](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) of that tunnel and supports streaming logs from multiple replicas at once. ![View replicas and stream logs from multiple connectors](https://edgetunnel-b2h.pages.dev/_astro/tunnel-multiconn.DEOEaLlu_ZDxArh.webp) Previously, you could only stream logs from one replica at a time. With this update: * **Replicas on the tunnel overview** — All active replicas for the selected tunnel now appear on that tunnel's overview page under **Connectors**. Select any replica to stream its logs. * **Multi-connector log streaming** — Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to [Cloudflare One ↗](https://one.dash.cloudflare.com/) and go to **Networks** \> **Connectors** \> **Cloudflare Tunnels**. Select **View logs** next to the tunnel you want to monitor. For more information, refer to [Tunnel log streams](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/monitor-tunnels/logs/) and [Deploy replicas](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/deploy-replicas/). Mar 19, 2026 1. ### [Manage Cloudflare Tunnels with Wrangler](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-19-wrangler-tunnel-commands/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/) You can now manage [Cloudflare Tunnels](https://edgetunnel-b2h.pages.dev/tunnel/) directly from [Wrangler](https://edgetunnel-b2h.pages.dev/workers/wrangler/), the CLI for the Cloudflare Developer Platform. The new [wrangler tunnel](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/tunnel/) commands let you create, run, and manage tunnels without leaving your terminal. ![Wrangler tunnel commands demo](https://edgetunnel-b2h.pages.dev/_astro/wrangler-tunnel.DOqrtGGg_7EDX0.webp) Available commands: * `wrangler tunnel create` — Create a new remotely managed tunnel. * `wrangler tunnel list` — List all tunnels in your account. * `wrangler tunnel info` — Display details about a specific tunnel. * `wrangler tunnel delete` — Delete a tunnel. * `wrangler tunnel run` — Run a tunnel using the cloudflared daemon. * `wrangler tunnel quick-start` — Start a free, temporary tunnel without an account using [Quick Tunnels](https://edgetunnel-b2h.pages.dev/tunnel/setup/#quick-tunnels-development). Wrangler handles downloading and managing the [cloudflared](https://edgetunnel-b2h.pages.dev/tunnel/downloads/) binary automatically. On first use, you will be prompted to download `cloudflared` to a local cache directory. These commands are currently experimental and may change without notice. To get started, refer to the [Wrangler tunnel commands documentation](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/tunnel/). Mar 18, 2026 1. ### [Worker execution timing field now available in Rules](https://edgetunnel-b2h.pages.dev/changelog/post/2026-03-18-worker-timing-field/) [ Rules ](https://edgetunnel-b2h.pages.dev/rules/) The `cf.timings.worker_msec` field is now available in the Ruleset Engine. This field reports the wall-clock time that a Cloudflare Worker spent handling a request, measured in milliseconds. You can use this field to identify slow Worker executions, detect performance regressions, or build rules that respond differently based on Worker processing time, such as logging requests that exceed a latency threshold. #### Field details | Field | Type | Description | | ----------------------- | ------- | ------------------------------------------------------------------------------------------------- | | cf.timings.worker\_msec | Integer | The time spent executing a Cloudflare Worker in milliseconds. Returns 0 if no Worker was invoked. | Example filter expression: ```plaintext cf.timings.worker_msec > 500 ``` For more information, refer to the [Fields reference](https://edgetunnel-b2h.pages.dev/ruleset-engine/rules-language/fields/reference/cf.timings.worker%5Fmsec/). Feb 20, 2026 1. ### [Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-20-tunnel-core-dashboard/) [ Cloudflare Tunnel ](https://edgetunnel-b2h.pages.dev/tunnel/)[ Cloudflare Tunnel for SASE ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) is now available in the main Cloudflare Dashboard at [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels), bringing first-class Tunnel management to developers using Tunnel for securing origin servers. ![Manage Tunnels in the Core Dashboard](https://edgetunnel-b2h.pages.dev/_astro/tunnel-core-dashboard.BGPqaHfo_Pi6HO.webp) This new experience provides everything you need to manage Tunnels for [public applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), including: * **Full Tunnel lifecycle management**: Create, configure, delete, and monitor all your Tunnels in one place. * **Native integrations**: View Tunnels by name when configuring [DNS records](https://edgetunnel-b2h.pages.dev/dns/manage-dns-records/how-to/create-dns-records/) and [Workers VPC](https://edgetunnel-b2h.pages.dev/workers-vpc/) — no more copy-pasting UUIDs. * **Real-time visibility**: Monitor [replicas](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/) and Tunnel [health status](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/troubleshoot-tunnels/common-errors/#tunnel-status) directly in the dashboard. * **Routing map**: Manage all ingress routes for your Tunnel, including [public applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/), [private hostnames](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-private-hostname/), [private CIDRs](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/connect-cidr/), and [Workers VPC services](https://edgetunnel-b2h.pages.dev/workers-vpc/), from a single interactive interface. #### Choose the right dashboard for your use case **Core Dashboard**: Navigate to [Networking > Tunnels ↗](https://dash.cloudflare.com/?to=/:account/tunnels) to manage Tunnels for: * Securing origin servers and [public applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/) with CDN, WAF, Load Balancing, and DDoS protection * Connecting [Workers to private services](https://edgetunnel-b2h.pages.dev/workers-vpc/) via Workers VPC **Cloudflare One Dashboard**: Navigate to [Zero Trust > Networks > Connectors ↗](https://one.dash.cloudflare.com/?to=/:account/networks/connectors) to manage Tunnels for: * Securing your public applications with [Zero Trust access policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/http-apps/self-hosted-public-app/) * Connecting users to [private applications](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/applications/non-http/self-hosted-private-app/) * Building a [private mesh network](https://edgetunnel-b2h.pages.dev/reference-architecture/architectures/sase/#connecting-networks) Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow. #### Get started New to Tunnel? Learn how to [get started with Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/get-started/create-remote-tunnel/) or explore advanced use cases like [securing SSH servers](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/use-cases/ssh/) or [running Tunnels in Kubernetes](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/deployment-guides/kubernetes/). Feb 17, 2026 1. ### [Cloudflare One Product Name Updates](https://edgetunnel-b2h.pages.dev/changelog/post/2026-02-17-product-name-updates/) [ Cloudflare One ](https://edgetunnel-b2h.pages.dev/cloudflare-one/)[ Cloudflare WAN ](https://edgetunnel-b2h.pages.dev/cloudflare-wan/)[ Cloudflare Network Firewall ](https://edgetunnel-b2h.pages.dev/cloudflare-network-firewall/)[ Network Flow ](https://edgetunnel-b2h.pages.dev/network-flow/) 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** * **Magic Cloud Networking** → **Cloudflare One Multi-cloud Networking** **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](https://edgetunnel-b2h.pages.dev/cloudflare-one/). ```json {"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product-group/network-security/#page","headline":"Network security Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product-group/network-security/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}} ```