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.
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.
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.
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.
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.
Cloudflare IPsec now supports post-quantum key agreement with compatible third-party devices. Cisco ↗︎ and Fortinet ↗︎ are the first third-party vendors validated to interoperate with Cloudflare IPsec using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).
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.
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.
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.
In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all replicas of that tunnel and supports streaming logs from multiple replicas at once.
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 ↗︎ and go to Networks > Connectors > Cloudflare Tunnels. Select View logs next to the tunnel you want to monitor.
You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.
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.
Wrangler handles downloading and managing the cloudflared 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.
Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗︎, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.
This new experience provides everything you need to manage Tunnels for public applications, 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 and Workers VPC — no more copy-pasting UUIDs.
Real-time visibility: Monitor replicas and Tunnel health status directly in the dashboard.
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.
Cloudflare WAN now displays your Anycast IP addresses directly in the dashboard when you configure IPsec or GRE tunnels.
Previously, customers received their Anycast IPs during onboarding or had to retrieve them with an API call. The dashboard now pre-loads these addresses, reducing setup friction and preventing configuration errors.
No action is required. All Cloudflare WAN customers can see their Anycast IPs in the tunnel configuration form automatically.
Cloudflare One Appliance version 2026.2.0 adds post-quantum encryption support using hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).
The appliance now uses TLS 1.3 with hybrid ML-KEM for its connection to the Cloudflare edge. During the TLS handshake, the appliance and the edge share a symmetric secret over the TLS connection and inject it into the ESP layer of IPsec. This protects IPsec data plane traffic against harvest-now, decrypt-later attacks.
This upgrade deploys automatically to all appliances during their configured interrupt windows with no manual action required.
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.
Cloudflare source IPs are the IP addresses used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks.
For customers using legacy mode routing, traffic to private networks is sourced from public Cloudflare IPs, which may cause IP conflicts. For customers using Unified Routing mode (beta), traffic to private networks is sourced from dedicated, non-Internet-routable private IPv4 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 Unified Routing (beta) and the Cloudflare One Networks Write permission.
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.
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.
You can now ping the WARP Connector host directly on its LAN IP address immediately after installation. This provides a fast, familiar way to confirm that the Connector is online and reachable within your network before testing access to downstream services.
Starting with version 2025.10.186.0, WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability.
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.
This feature allows you to:
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.
Starting February 2, 2026, the cloudflared proxy-dns command will be removed from all new cloudflaredreleases.
This change is being made to enhance security and address a potential vulnerability in an underlying DNS library. This vulnerability is specific to the proxy-dns command and does not affect any other cloudflared features, such as the core Cloudflare Tunnel service.
The proxy-dns command, which runs a client-side DNS-over-HTTPS (DoH) proxy, has been an officially undocumented feature for several years. This functionality is fully and securely supported by our actively developed products.
Versions of cloudflared released before this date will not be affected and will continue to operate. However, note that our official support policy for any cloudflared release is one year from its release date.
Migration paths
We strongly advise users of this undocumented feature to migrate to one of the following officially supported solutions before February 2, 2026, to continue benefiting from secure DNS-over-HTTPS.
End-user devices
The preferred method for enabling DNS-over-HTTPS on user devices is the Cloudflare WARP client. The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization's Zero Trust policies and posture checks.
Servers, routers, and IoT devices
For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using the WARP Connector.
Instead of running cloudflared proxy-dns on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your entire subnet to Cloudflare for filtering and logging.
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 (beta).
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.
With this feature, you can:
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.
You can now route private traffic to Cloudflare Tunnel based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability is free for all Cloudflare One customers.
Previously, Tunnel routes could only be defined by IP address or CIDR range. This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists.
What’s new:
Hostname & Domain Routing: Create routes for individual hostnames (e.g., payroll.acme.local) or entire domains (e.g., *.acme.local) and direct their traffic to a specific Tunnel.
Simplified Zero Trust Policies: Build resilient policies in Cloudflare Access and Gateway using stable hostnames, making it dramatically easier to apply per-resource authorization for your private applications.
Precise Egress Control: Route traffic for public hostnames (e.g., bank.example.com) through a specific Tunnel to enforce a dedicated source IP, solving the IP allowlist problem for third-party services.
No More IP Lists: This feature makes the workaround of maintaining dynamic IP Lists for Tunnel connections obsolete.
Magic WAN and WARP Connector users can now securely route their DNS traffic to the Gateway resolver without exposing traffic to the public Internet.
Routing DNS traffic to the Gateway resolver allows DNS resolution and filtering for traffic coming from private networks while preserving source internal IP visibility. This ensures Magic WAN users have full integration with our Cloudflare One features, including Internal DNS and hostname-based policies.
To configure DNS filtering, change your Magic WAN or WARP Connector DNS settings to use Cloudflare's shared resolver IPs, 172.64.36.1 and 172.64.36.2. Once you configure DNS resolution and filtering, you can use Source Internal IP as a traffic selector in your resolver policies for routing private DNS traffic to your Internal DNS.
Now, Magic WAN customers can configure a custom IKE ID for their IPsec tunnels. Customers that are using Magic WAN and a VeloCloud SD-WAN device together can utilize this new feature to create a high availability configuration.
