Cloudflare built our global network to be programmable by design, so we can help organizations unlock this flexibility and freedom. In this post, we’ll go deeper into what programmability means, and how Cloudflare One, our SASE platform, helps customers architect their security and networking with our building blocks to meet their unique and custom needs.

The term programmability has become diluted by the industry. Most security vendors claim programmability because they have public APIs, documented Terraform providers, webhooks, and alerting. That’s great, and Cloudflare offers all of those things too.

These foundational capabilities provide customization, infrastructure-as-code, and security operations automation, but they're table stakes. With traditional programmability, you can configure a webhook to send an alert to Slack when a policy triggers.

But the true value of programmability is something different. It is the ability to intercept a security event, enrich it with external context, and act on it in real time. Say a user attempts to access a regulated application containing sensitive financial data. Before the request completes, you query your learning management system to verify the user has completed the required compliance training. If their certification has expired, or they never completed it, access is denied, and they are redirected to the training portal. The policy did not just trigger an alert — it made the decision. 

The Cloudflare global network spans more than 330 cities across the globe and operates within approximately 50 milliseconds of 95% of the Internet-connected population. This network runs every service on every server in every data center. That means our industry-leading SASE platform and Developer Platform run side by side, on the same metal, making our Cloudflare services both composable and programmable. 

When you use Cloudflare to protect your external web properties, you are using the same network, the same tools, and the same primitives as when you secure your users, devices, and private networks with Cloudflare One. Those are also the same primitives you use when you build and deploy full-stack applications on our Developer Platform. They are designed to work together — not because they were integrated after the fact, but because they were never separate to begin with.

By design, this allows customers to extend policy decisions with custom logic in real time. You can call an external risk API, inject dynamic headers, or validate browser attributes. You can route traffic based on your business logic without adding latency or standing up separate infrastructure. Standalone SASE providers without their own compute platform require you to deploy automation in a separate cloud, manually configure webhooks, and accept the round-trip latency and management overhead of stitching together disconnected systems. With Cloudflare, your Worker augments inline SASE services like Access to enforce custom policies, at the edge, in milliseconds.

At its core, every security gateway operates on the same fundamental model. Traffic flows from sources, through policies, to destinations. The policies are where things get interesting, but in most platforms, your options are limited to predefined actions: allow, block, isolate, or quarantine.

We think there is a better way. What if you could invoke custom logic instead? 

Rather than predefined actions, you could: 

• Dynamically inject headers based on user identity claims

• Call external risk engines for a real-time verdict before allowing access

• Enforce access controls based on location and working hours

Today, customers can already do many of these things with Cloudflare. And we are strengthening the integration between our SASE and Developer Platform to make this even easier. Programmability extensions, like the ones listed above, will be natively integrated into Cloudflare One, enabling customers to build real-time, custom logic into their security and networking policies. Inspect a request and make a decision in milliseconds. Or run a Worker on a schedule to analyze user activity and update policies accordingly, such as adding users to a high-risk list based on signals from an external system.

We are building this around the concept of actions: both managed and custom. Managed actions will provide templates for common scenarios like IT service management integrations, redirects, and compliance automation. Custom actions allow you to define your own logic entirely. When a Gateway HTTP policy matches, instead of being limited to allow, block, or isolate, you can invoke a Cloudflare Worker directly. Your code runs at the edge, in real time, with full access to the request context. 

While we are improving this experience, many customers are already using Cloudflare One and Developer Platform this way today. Here is a simple example that illustrates what you can do with this programmability. 

The problem: A customer wanted to enforce periodic re-authentication for their Cloudflare One Client users, similar to how traditional VPNs require users to re-authenticate every few hours. Cloudflare's pre-defined session controls are designed around per-application policies, not global time-based expiration.

The solution: A scheduled Cloudflare Worker that queries the Devices API, identifies devices that have been inactive longer than a specified threshold, and revokes their registrations, forcing users to re-authenticate via their identity provider.

export default {
  async scheduled(event, env, ctx) {
    const API_TOKEN = env.API_TOKEN;
    const ACCOUNT_ID = env.ACCOUNT_ID;
    const REVOKE_INTERVAL_MINUTES = parseInt(env.REVOKE_INTERVAL_MINUTES); // Reuse for inactivity threshold
    const DRY_RUN = env.DRY_RUN === 'true';

    const headers = {
      'Authorization': `Bearer ${API_TOKEN}`,
      'Content-Type': 'application/json'
    };

    let cursor = '';
    let allDevices = [];

    // Fetch all registrations with cursor-based pagination
    while (true) {
      let url = `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/devices/registrations?per_page=100`;
      if (cursor) {
        url += `&cursor=${cursor}`;
      }

      const devicesResponse = await fetch(url, { headers });
      const devicesData = await devicesResponse.json();
      if (!devicesData.success) {
        console.error('Failed to fetch registrations:', devicesData.errors);
        return;
      }

      allDevices = allDevices.concat(devicesData.result);

      // Extract next cursor (adjust if your response uses a different field, e.g., devicesData.result_info.cursor)
      cursor = devicesData.cursor || '';
      if (!cursor) break;
    }

    const now = new Date();

    for (const device of allDevices) {
      const lastSeen = new Date(device.last_seen_at);
      const minutesInactive = (now - lastSeen) / (1000 * 60);

      if (minutesInactive > REVOKE_INTERVAL_MINUTES) {
        console.log(`Registration ${device.id} inactive for ${minutesInactive} minutes.`);

        if (DRY_RUN) {
          console.log(`Dry run: Would delete registration ${device.id}`);
        } else {
          const deleteResponse = await fetch(
            `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/devices/registrations/${device.id}`,
            { method: 'DELETE', headers }
          );
          const deleteData = await deleteResponse.json();
          if (deleteData.success) {
            console.log(`Deleted registration ${device.id}`);
          } else {
            console.error(`Failed to delete ${device.id}:`, deleteData.errors);
          }
        }
      }
    }
  }
};

Configure the Worker with environment secrets (API_TOKEN, ACCOUNT_ID, REVOKE_INTERVAL_MINUTES) and a cron trigger (0 */4 * * * for every 4 hours), and you have automated session management. Just getting a simple feature like this into a vendor’s roadmap could take months, and even longer to move into a management interface.

But with automated device session revocation, our technical specialist deployed this policy with the customer in an afternoon. It's been running in production for months.

We’ve observed countless implementations like this across Cloudflare One deployments. We’ve seen users implement coaching pages and purpose justification workflows by using our existing redirect policies and Workers. Other users have built custom logic that evaluates browser attributes before making policy or routing decisions. Each solves a unique problem that would otherwise require waiting for a vendor to build a specific, niche integration with a third-party system. Instead, customers are building exactly what they need, on their timeline, with logic they own.

We believe the future of enterprise security isn't a monolithic platform that tries to do everything. It's a composable and programmable platform that gives customers the tools and flexibility to extend it in any direction.

For security teams, we expect our platform to change the conversation. Instead of filing a feature request and hoping it makes the roadmap, you can build a tailored solution that addresses your exact requirements today. 

For our partners and managed security service providers (MSSPs), our platform opens up their ability to build and deliver solutions for their specific customer base. That means industry-specific solutions, or capabilities for customers in a specific regulatory environment. Custom integrations become a competitive advantage, not a professional services engagement.

And for our customers, it means you're building on a platform that is easy to deploy and fundamentally adaptable to your most complex and changing needs. Your security platform grows with you — it doesn’t constrain you.

We're just getting started. Throughout 2026, you'll see us continue to deepen the integration between Cloudflare One and our Developer Platform. We plan to start by creating custom actions in Cloudflare Gateway that support dynamic policy enforcement. These actions can use auxiliary data stored in your organization's existing databases without the administrative or compliance challenges of migrating that data into Cloudflare. These same custom actions will also support request augmentation to pass along Cloudflare attributes to your internal systems, for better logging and access decisions in your downstream systems.  

In the meantime, the building blocks are already here. External evaluation rules, custom device posture checks, Gateway redirects, and the full power of Workers are available today. If you're not sure where to start, our developer documentation has guides and reference architectures for extending Cloudflare One.

We built Cloudflare on the belief that security should be ridiculously easy to use, but we also know that "easy" doesn't mean "one-size-fits-all." It means giving you the tools to build exactly what you need. We believe that’s the future of SASE.

We are thrilled to announce that Cloudflare has been named a Visionary in the 2025 Gartner® Magic Quadrant™ for Secure Access Service Edge (SASE) Platforms¹ report. We view this evaluation as a significant recognition of our strategy to help connect and secure workspace security and coffee shop networking through our unique connectivity cloud approach. You can read more about our position in the report here.

Since launching Cloudflare One, our SASE platform, we have delivered hundreds of features and capabilities from our lightweight branch connector and intuitive native Data Loss Prevention (DLP) service to our new secure infrastructure access tools. By operating the world’s most powerful, programmable network we’ve built an incredible foundation to deliver a comprehensive SASE platform. 

Today, we operate the world's most expansive SASE network in order to deliver connectivity and security close to where users and applications are, anywhere in the world. We’ve developed our services from the ground up to be fully integrated and run on every server across our network, delivering a unified experience to our customers. And we enable these services with a unified control plane, enabling end-to-end visibility and control anywhere in the world. Tens of thousands of customers trust Cloudflare with their network and security infrastructure.

We’re thrilled with our inclusion in this report and are even more excited that we’re only just getting started. Building on this foundation, we’re investing to move even faster to solve problems for our customers.

SASE (pronounced “sassy”) is an architectural model that delivers network connectivity and security functions, and delivers them through a single cloud platform and/or centralized policy control.

Given the extent of what organizations need for networking and security, not all SASE capabilities may be available from a single vendor. For example, the security-as-a-service model is sometimes consumed as a part of Security Service Edge (SSE).

The evolution of this architecture, where a vendor delivers key functionality across networking and security service in a single offering, is SASE. What’s important to note, however, is that convergence can mean many, many different things. For example, some vendors started with SSE capabilities and are building out infrastructure to support it. Some vendors are using public cloud for their infrastructure. Some are aggressively pursuing M&A to acquire functionality. These decisions have led to many problematic questions such as: how many interfaces do organizations need to manage their network and security needs? Why is security enforcement sometimes in the cloud and sometimes at the branch edge?

We believe that the market deserves more than a buffet of features. Convergence should be greater than the sum of the parts. The infrastructure/control plane/data plane for networking services should not be an independent entity from the security services. We believe that we are delivering SASE capabilities in a fundamentally different manner than the majority of vendors in the market: by building out the platform first, and layering services upon it.

We also believe that our efforts to focus on the underlying network delivers better solutions for simplifying your infrastructure, establishing control, and maintaining visibility to support branch connectivity, hybrid work, Zero Trust, and secure cloud access.

The Cloudflare Global network is one of the largest, most well-connected networks in the world, spanning more than 330 cities in over 125 countries. We are not a new vendor entering a new market, but rather one that has been delivering services upon a mature platform that’s been tested under the most extreme circumstances over the past 15+ years.

Our unified platform, Cloudflare’s connectivity cloud, is built upon a set of principles across our infrastructure, our control plane, and our data plane, that guides everything we do:

Infrastructure: The infrastructure that we build must be everywhere our customers do business. Users, applications, and data are everywhere, and therefore we build ahead of our customer’s needs to ensure that they can connect anything to anywhere, quickly and reliably.

Control Plane: To stay on top of operations, organizations want a single user interface for monitoring activity and enforcing policies, with changes pushed out globally in seconds. In addition, our customers want APIs to extend management into automation and infrastructure-as-code tools. We help organizations cut down on the tool sprawl, doing away with the drudgery and complexity that affects even the most basic administrative tasks with conventional tech stacks. And we restore observability across activity (again by virtue of facilitating any-to-any connectivity) to help with operations with troubleshooting, forensics, and insights across the application landscape.

Data Plane: The data plane is where services are delivered, and we constantly deliver innovations in how users connect, consistently enforce inspection and policy, and deliver traffic to the intended location securely. These services are composable, meaning that new functionality can be enabled from the Control Plane, without the headaches of network downtime normally associated with appliance insertion.

These principles are crucial for delivering a superior, end-to-end user experience. Your SASE environment is (or will be) processing packets from users across the globe. Latency damages the user experience, in ways that are similar to how a smoothly running engine becomes unreliable and inefficient as internal components become dirty. Our design principles establish the north star to ensure that everything we do and everything we build does not add grit to the engine. This is important because we are seeing a lot of confusion (and some obfuscation) about how to deliver performant SASE services.

To understand how our principles apply towards the delivery of SASE services:

Connecting users to a data center (last mile latency): With traditional on-prem networking, one of the major sources of latency is getting the traffic to the security stack. Both hub & spoke and VPN focus on taking traffic (from sometimes distant locations) to one of the organization’s security enforcement points such as a perimeter firewall. With SASE, the objective is to deliver the security closer to the user, using one of the SASE provider’s data centers. Cloudflare’s global coverage delivers service to within 50ms of 95% of the world’s population. This is something unique to Cloudflare, in that other vendors seldom discuss how much data center coverage is needed to deliver sufficient last mile performance, or sometimes use confusing metrics about the latency within their data centers (see next section) to infer what organizations might expect with end-to-end latency.

Delivering key networking and security services (processing latency): SASE data centers must deliver networking and security, but not all cloud data centers are designed the same. Some implementations in the market separate the SASE edge (the point of presence) from the actual compute (the data center itself). Some have disguised their single-pass processing with a series of daisy-chained proxies, which requires inefficiently decoding packets multiple times (From L3 to L7 and back to L3) to perform different security functions. As a result, there’s often a delta between the performance of a configuration that offers low latency and the configuration with the security features that customers want enabled. Cloudflare delivers full compute in every data center. There is no “next-hop” to compute; instead, there are fungible compute resources to ensure the fastest interface-to-interface possible with all the security features (including TLS decryption) enabled.

Connecting from the SASE to applications (Internet exchanges, private backbone, optimized routing and peering): Many vendors optimize their data centers to focus on egress to the Internet/cloud, typically by participating in Internet exchanges along with a handful of peering relationships. In other words, their networks were not designed for traffic between data centers, which is a suboptimal design for branch-to-branch or branch-to-data-center traffic.

Cloudflare’s network operates a private backbone for traffic destined to another Cloudflare data center, and we are one of the largest participants in Internet exchanges in the world for traffic destined to the Internet/cloud. We are connected to over 13,000 public and private networks, plus our open peering policy provides extensive access for networks of different sizes to participate as well. But user experience isn’t determinable solely by the number of interconnections. Not all Internet exchanges are the same, and in many cases there are variables that affect the quality and reliability of any given connection. That’s why Cloudflare further optimizes the connection to the user’s ultimate destination, whether destined to a public or private network, to make path selection more intelligent than simply counting hops over routing protocols.

We’ve discussed how we do what we do. Now let’s discuss the services we deliver. While customers have a number of different requirements that are specific to their organization, we do see centers of gravity that drive their use cases:

Network modernization initiatives: Enterprise networks are in ways more complicated than they need to be. To make the enterprise network suitable for today’s hybrid workspace, many organizations are looking for ways to converge the on-prem and remote user experience. The adoption of the coffee shop networking architecture is driving many projects towards single-vendor SASE. By using Cloudflare Access, users can access applications securely with identity and device-based contextual controls. Organizations use Magic WAN for network connectivity across branch offices, headquarters, regional campuses and the data center.

Security modernization initiatives: Security teams with concerns about enforcing more granular security controls to access critical resources are making efforts to adopt Zero Trust. These initiatives drive security-focused SASE use cases, which can both reduce the attack surface and centralize enforcement of adaptive access policies. Security teams need to both enable access to private applications while also securing access to the Internet. Use Cloudflare Access to implement Zero Trust Network Access, which accelerates the deployment of protections by layering granular, user-specific access controls on top of the existing network topology. Use Cloudflare Gateway to enforce content filtering policies to protect access to the Internet. Use Cloudflare Email Security to stop phishing attacks and disrupt the business email compromise attack lifecycle. 

Transformation initiatives: Most organizations have legacy investments in both networking and security infrastructure, and are embarking upon a transformation across their business to support their future needs. Organizations that are transforming need to tackle both networking and security modernization. Cloudflare One addresses comprehensive transformation by delivering networking services through Cloudflare Magic WAN, Cloudflare Access to implement ZTNA, Cloudflare Gateway to protect users from Internet threats, Cloudflare CASB to secure SaaS, and more.

We’re building new capabilities that extend beyond the traditional definition of SASE, all while leveraging our core Cloudflare network foundation. This includes addressing a broader spectrum of security concerns that organizations face, such as phishing and DDoS attacks.

We are expanding our networking capabilities to help organizations simplify and automate multi-cloud connectivity. As the boundaries between public and private networking blur, particularly with the widespread adoption of AI across various applications, customers are looking for a single set of controls for all their applications. This requires market-leading Web Application and API Protection (WAAP) services that natively support both positive and negative security models as part of SASE.

Furthermore, we are rapidly deploying Graphics Processing Units (GPUs) in our data centers to power AI protections and support customer applications. As the only SASE platform that also serves as a leading Edge Distribution Platform with AI primitives, we are uniquely positioned to help customers to understand the latest AI capabilities and secure their users, networks, applications, and data with a security-first approach across the entire application lifecycle. We provide holistic support for the age of AI, and many leading Generative AI platforms rely on our network as critical infrastructure to operate. With their traffic and often code on our network, we enable the safeguard of customers' AI usage.

We believe that these efforts will help the market evolve and address a broader range of customer concerns. We’re doing this incrementally, building integrated solutions on top of our foundation and accelerating our pace. We can’t wait to show you what we’ve got planned for the year ahead in SASE.

Are you interested in Cloudflare One? Contact us to learn more about how we can help.

***

¹_{Gartner, Magic Quadrant for SASE Platforms, Analyst(s): Jonathan Forest, Neil MacDonald, Dale Koeppen, July 9, 2025}

_{GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.}

_{Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.}

What’s more exciting is that we’re just getting started. Since 2018, starting with our Zero Trust Network Access (ZTNA) service Cloudflare Access, we’ve continued to push the boundaries of how quickly we can build and deliver a mature SSE platform. In that time, we’ve released multiple products each year, delivering hundreds of features across our platform. That’s not possible without our customers. Today, tens of thousands of customers have chosen to connect and protect their people, devices, applications, networks, and data with Cloudflare. They tell us our platform is faster and easier to deploy and provides a more consistent and reliable user experience, all on a more agile architecture for longer term modernization. We’ve made a commitment to those customers to continue to deliver innovative solutions with the velocity and resilience they have come to expect from us. If you want to join them on this journey today, contact us to discuss your own SSE journey. 

In general, a Security Service Edge (SSE) provides a helpful framing that gives teams guardrails as they adopt a Zero Trust architecture. The concept breaks down into a few typical buckets:

• Zero Trust access control: Protect applications that hold sensitive data by creating least privilege rules that check for identity, device posture, and other signals on each and every request or connection.

• Outbound filtering: Keep people and devices safe as they connect to the rest of the Internet by filtering and logging network traffic, DNS queries, and HTTP requests.

• Secure SaaS usage: Analyze traffic to SaaS applications and scan the data sitting inside of SaaS applications for potential Shadow IT policy violations, misconfigurations, or data mishandling.

• Data protection: Scan for data leaving your organization towards destinations that do not comply with your organization’s policies. Find data stored inside your organization, even in trusted tools, that should not be retained or that needs tighter access controls.

• Employee experience: Monitor and improve the experience that your team members have when using tools and applications on the Internet or hosted inside your own organization.

The SSE space is a component of the larger Secure Access Service Edge (SASE) market. You can think of the SSE capabilities as the security half of SASE, while the other half consists of the networking technologies that connect offices and data centers to each other along with everything that SSE connects. Some vendors only focus on the SSE side and rely on partners to connect customers to their security solutions. Other companies just provide the networking pieces. While today’s announcement highlights our SSE capabilities, Cloudflare offers both components as a unified SASE platform.

Cloudflare’s global network was built for this. We’ve developed a unified, programmable network in which every service runs in every data center, spanning more than 330 cities across the globe. Cloudflare operates within approximately 50 milliseconds of 95% of the Internet-connected population globally. That means that regardless of where your people, apps, and data are located, your Security Service Edge is not far away.

Our SSE services operate on the same infrastructure and locations that support many of the world's most prominent Internet platforms. We've integrated proven strengths including the world’s fastest DNS resolver, our robust serverless compute platform, intelligence from our leading Web Application and API Protection (WAAP) platform and advanced global traffic routing capabilities developed as a result of proxying and protecting approximately 20% of websites. Our architecture ensures single-pass inspection, regardless of how customers connect. We also consistently hear that this performance is core to why customers chose Cloudflare. When customers choose Cloudflare, they’re choosing a unified, resilient platform built for the future.

By building our SSE platform on top of our own network, it puts Cloudflare in the driver’s seat. Whether that’s implementing best practices like IPv6, incorporating new technologies like WireGuard or MASQUE, or safeguarding against the future with post-quantum encryption, by building on our own network we’re able to react quickly as new Internet security standards mature.

Customers can rely on Cloudflare to solve a broad range of security problems represented by the SSE category. They can also just start with a single component. We know that an entire modernization journey can be an overwhelming prospect for any organization. While all the use cases below are built to work better together, we make it simple for teams to start by just solving one problem at a time.

Traditional VPNs have been the backbone of enterprise remote access for decades. However, organizations are rapidly moving away from VPNs due to security vulnerabilities, performance bottlenecks, and poor user experience. As businesses adopt Zero Trust principles, they expect modern solutions that:

• Improve security posture by enforcing least privilege access and per-resource authorization, eliminating dependence on perimeter-based defenses

• Enhance user experience with seamless, high-performance connectivity.

• Reduce complexity and operational overhead by consolidating tools and automating access policies.

Cloudflare enables identity-driven, context-aware policies which replace the traditional castle-and-moat model that come with VPN-based solutions. Applications can be made available to employees as well as third parties through a completely clientless deployment. Policies can also be applied to the applications that sit outside your infrastructure to ensure a consistent experience across SaaS applications as well. 

By mid-2026, we plan to ship a number of new access control capabilities, including:

• Identity provider (IdP) agnostic multi-factor authentication (MFA): Admins can enforce step-up MFA without having to direct a user back to an identity provider.

• Just-in-time access controls: Review and approve timely access requests to sensitive resources. Users can request access via tools like Slack and Google Chat.

• Browser-based RDP: Traditionally, vendors provide a limited number of PoPs which can support clientless RDP. With Cloudflare, customers get highly performant clientless RDP from the browser by connecting to any of Cloudflare’s data centers. This feature enables access to RDP targets without any software installed on the user’s machine.

For decades, organizations relied on on-prem hardware firewalls to secure Internet access. Like applications, users have moved beyond the perimeter and cloud-based security services have become essential. Modern businesses expect solutions that:

• Protect users across locations from malware, ransomware, and other Internet threats

• Enforce those protections with real-time, comprehensive threat intelligence that adapts with emerging attack vectors

• Reduce management complexity while maintaining granular policy control across the entire network

Cloudflare Gateway, our secure web gateway (SWG), inspects and filters DNS, network, HTTP, and egress traffic with consistent protections across the Internet and internal resources. Customers adopt our SWG to block threats across remote and office workers, enforce acceptable use policies, encrypt traffic, and block unauthorized SaaS and cloud destinations. In a single-pass architecture, all traffic is verified, filtered, and inspected without the performance penalties seen with hardware-based firewalls and proxies. Threat intelligence is derived from unique real-time visibility across our global network, including 4.3 trillion DNS queries per day, which powers AI-backed threat hunting models to identify, for example, new / newly seen domains before other vendors. 

Browser isolation capabilities are also natively built-in, enabling organizations to insulate users from threats online and protect data in applications with a seamless user experience. For example, isolating web browsing safeguards users from unknown threats, including zero-days, while isolating apps like AI tools can restrict oversharing of proprietary information.

Customers can get started with a variety of deployment methods including device agents, network locations, PAC files, or DNS over HTTPS (DoH) endpoints. Regardless of implementation, consistent policy enforcement and comprehensive logging is easily accessible through our dashboard, our SQL-based Log Explorer experience, or third-party tools via LogPush.

By mid-2026, we plan to ship a number of new filtering and traffic handling capabilities, including:

• Deep packet inspection to apply filtering to non-standard ports for protocols like HTTP, SSH, and many others.

• Filtering using Fully Qualified Domain Names (FQDNs): Admins will no longer need to filter packets or egress connections based on destination IP addresses. They will be able to use the FQDN, application name, or destination category with the egress and network policy builders.

• Identity + PAC files, providing identity-based filtering without having to install the device client.

Our comprehensive cloud firewall delivers “firewall as a service” protection that helps organizations manage traffic flows globally. All traffic passing through Cloudflare has firewall policies evaluated first, thus providing the first layer of defense, eliminating unnecessary/unwanted traffic before being further evaluated against security policies. The Cloudflare firewall applies configuration changes globally in seconds, thus providing immediate response to emerging needs. With Cloudflare’s network and data center capacity, you get virtually limitless firewall capacity, without the constraints of traditional hardware firewalls, making it a vital component of your Zero Trust and defense-in-depth architecture.

SaaS applications relieve IT teams of the burden to host, maintain, and monitor the tools behind their business. However, they also create entirely new headaches for corresponding security teams. Modern organizations need solutions that:

• Provide visibility into unauthorized application usage that creates compliance and security risks

• Enable granular control over data flows within both sanctioned and unsanctioned applications

• Automate discovery and remediation of security misconfigurations in approved SaaS tools

Any user in an enterprise now needs to connect to an application on the public Internet to do their work, and some users prefer to use their favorite application rather than the ones vetted and approved by the IT department. This kind of Shadow IT infrastructure can lead to surprise fees, compliance violations, and data loss.

Cloudflare offers comprehensive scanning and filtering to detect when team members are using unapproved tools. With a single click, administrators can block those tools outright or control how those applications can be used. If your marketing team needs to use Google Drive to collaborate with a vendor, you can quickly apply a rule that makes sure they can only download files and never upload. Alternatively, you can allow users to visit an application and read from it while blocking all text input. Cloudflare's Shadow IT policies offer easy-to-deploy controls to help manage how your organization uses the Internet.

Beyond unsanctioned applications, even approved resources can cause trouble. Your organization might rely on Microsoft OneDrive for day-to-day work, but your compliance policies prohibit your HR department from storing files with employee Social Security numbers in the tool. Cloudflare's Cloud Access Security Broker (CASB) can routinely scan the SaaS applications your team relies on to detect improper usage, missing controls, or potential misconfiguration.

By mid-2026, we look forward to bringing our customers a slew of new capabilities designed to give teams even better visibility and control over their SaaS and cloud applications, including:

• Robust remediation capabilities: Resolve detected issues right from the dashboard, both automatically and on-demand with a single click.

• Advanced workflows: Configure automated behavior when new issues are detected, like custom alerting outputs and business justification prompts.

• User and Entity Behavior Analytics (UEBA) & suspicious activity monitoring: Monitor live events across your SaaS apps and detect anomalous/suspicious activity that could indicate compromise.

Over the past year, CIOs and CISOs have consistently identified data protection as a top concern, particularly regarding artificial intelligence and large language models. As organizations increasingly rely on cloud services and AI tools, they require modern solutions that:

• Protect sensitive information across all environments without hampering productivity

• Provide visibility into how data flows through both internal and external systems

• Enforce consistent security policies that adapt to evolving regulatory requirements

Cloudflare provides comprehensive visibility and control over data movement and data at rest. This helps organizations avoid the financial impact and reputational consequences of data loss and theft.

Our data security is an integral component of our SASE platform, providing granular control over how users interact with applications. This approach allows organizations to establish nuanced policies that safeguard sensitive information without completely blocking access to productivity-enhancing technologies.

We are introducing a number of exciting data protection capabilities by mid-2026, including AI-based DLP detections, delivering simple, innovative forensics, classifying sensitive data in the public cloud, and innovative, preventative cloud security controls. These features provide administrators with robust controls while maintaining the seamless performance and user experience that organizations expect from Cloudflare. 

Organizations today struggle with limited visibility into their users' digital experiences. When performance or availability issues arise, internal support teams often lack the tools to determine whether problems originate in the first, middle, or last mile, resulting in multiple support tickets and delayed resolutions.

Cloudflare addresses this challenge with a comprehensive monitoring toolkit built on the same systems we use to manage our massive global network in-house. This solution empowers IT teams to:

• Collect on-demand forensic and diagnostic information

• Systematically gather telemetry data

• Analyze patterns to anticipate issues before they impact productivity

Cloudflare provides unmatched insight into Internet outages and performance trends that affect your users. This intelligence allows administrators to refine their deployments and quickly identify whether issues are localized to their environment or part of broader global disruptions.

By mid-2026, we plan to ship a number of new digital experience monitoring capabilities, including:

• Real user monitoring (RUM) that measures the performance of every user’s request.

• Advanced monitoring for communication applications like Zoom and Microsoft Teams.

• Contextualizing user performance in terms of global Internet performance data.

Security Service Edge forms a critical component of modern enterprise protection, but organizations have modernization requirements across their network infrastructure. Cloudflare designed our capabilities with these needs in mind, because we deliver true convergence of both networking and security from our connectivity cloud.

Across the industry, we’ve seen many instances where vendors start with either networking or security as their primary focus, and acquire a vendor with an entirely different architecture to enter the SASE market. In such scenarios, there is no convergence with security and networking, because internal traffic is handled through different security controls than the cloud traffic.

Cloudflare delivers networking services using the same global data centers and backbone as our security components. Our composable architecture ensures all of our services are designed to work together, in any order. This means that your security and networking stays consistent and provides a common destination for your SASE journey, no matter where you start. 

We’re proud of the work that we’ve done to solve customer problems. Cloudflare continues to receive industry-wide recognition, earning additional positions in 2024 for our comprehensive suite of security solutions beyond SSE, built for the enterprise.

• Cloudflare named in Gartner® Magic Quadrant™ for Cloud Application Platforms²

• Cloudflare named in Gartner® Magic Quadrant™ for Email Security Platforms³

• Cloudflare named in Gartner® Magic Quadrant™ for Single-Vendor SASE⁴

We believe this recognition underscores our position as a pioneering security and networking platform built for tomorrow's challenges. When organizations choose Cloudflare, they gain more than just another SSE vendor; they’re establishing a partnership with a holistic platform capable of addressing their broader spectrum of requirements for both public and private resources, both today and in the future.

Tens of thousands of organizations trust Cloudflare to secure their teams every day.  We talk to customers directly about that feedback, and they have helped us understand why CIOs and CISOs choose Cloudflare One. For some teams we offer a cost-efficient opportunity to consolidate point solutions. Others appreciate that the ease-of-use means that many practitioners have set up our solution before they even talk to our team. We know that speed matters when we are 46% faster than Zscaler, 56% faster than Netskope, and 10% faster than Palo Alto Networks.

We kicked off 2025 with a week focused on new security features that teams can begin deploying now. In the year ahead, look forward to announcements for our Secure Web Gateway, data protection capabilities, digital experience monitoring, and our inline and API CASB tools. And stay tuned for exciting innovations with AI-driven analytics and monitoring tools, too.

Our commitment in 2025 is the same as it was in 2024. We are going to continue to help your teams solve more security problems so that you can focus on your own mission.

Ready to hold us to that commitment? Cloudflare offers something unique among the players in this space — you can start using nearly every feature in our SSE platform right now at no cost. Teams of up to 50 users can adopt the solution for free to jumpstart a proof of concept. We believe that organizations of any size should be able to quickly and easily start their journey to modernize security.

Footnotes:

¹ Gartner, Magic Quadrant for Security Service Edge, Analyst(s): Charlie Winckless, Thomas Lintemuth, Dale Koeppen, Charanpal Bhogal, May 20, 2025

² Gartner, Magic Quadrant for Cloud Application Platforms, Analyst(s): Tigran Egiazarov, Mukul Saha, Anne Thomas, Steve Schwent, November 1, 2024

³ Gartner, Magic Quadrant for Email Security Platforms, Analyst(s): Max Taggett, Nikul Patel, Franz Hinner, Deepak Mishra, December 16, 2024

⁴ Gartner, Magic Quadrant for Single-Vendor SASE, Analyst(s): Andrew Lerner, Neil MacDonald, Jonathan Forest, Charlie Winckless, July 3, 2024

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally, and MAGIC QUADRANT is a registered trademark of Gartner, Inc. and/or its affiliates and are used herein with permission. All rights reserved.

Gartner does not endorse any vendor, product or service depicted in its research publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner research publications consist of the opinions of Gartner’s research organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this research, including any warranties of merchantability or fitness for a particular purpose.

In the ever-evolving domain of enterprise security, CISOs and CIOs have to tirelessly build new enterprise networks and maintain old ones to achieve performant any-to-any connectivity. For their team of network architects, surveying their own environment to keep up with changing needs is half the job. The other is often unearthing new, innovative solutions which integrate seamlessly into the existing landscape. This continuous cycle of construction and fortification in the pursuit of secure, flexible infrastructure is exactly what Cloudflare’s SASE offering, Cloudflare One, was built for.

Cloudflare One has progressively evolved based on feedback from customers and analysts. Today, we are thrilled to introduce the public availability of the Cloudflare WARP Connector, a new tool that makes bidirectional, site-to-site, and mesh-like connectivity even easier to secure without the need to make any disruptive changes to existing network infrastructure.

Cloudflare's approach has always been focused on offering a breadth of products, acknowledging that there is no one-size-fits-all solution for network connectivity. Our vision is simple: any-to-any connectivity, any way you want it.

Prior to the WARP Connector, one of the easiest ways to connect your infrastructure to Cloudflare, whether that be a local HTTP server, web services served by a Kubernetes cluster, or a private network segment, was through the Cloudflare Tunnel app connector, cloudflared. In many cases this works great, but over time customers began to surface a long tail of use cases which could not be supported based on the underlying architecture of cloudflared. This includes situations where customers utilize VOIP phones, necessitating a SIP server to establish outgoing connections to user’s softphones, or a CI/CD server sending notifications to relevant stakeholders for each stage of the CI/CD pipelines. Later in this blog post, we explore these use cases in detail.

As cloudflared proxies at Layer 4 of the OSI model, its design was optimized specifically to proxy requests to origin services — it was not designed to be an active listener to handle requests from origin services. This design trade-off means that cloudflared needs to source NAT all requests it proxies to the application server. This setup is convenient for scenarios where customers don't need to update routing tables to deploy cloudflared in front of their original services. However, it also means that customers can’t see the true source IP of the client sending the requests. This matters in scenarios where a network firewall is logging all the network traffic, as the source IP of all the requests will be cloudflared’s IP address, causing the customer to lose visibility into the true client source.

To solve this problem, we identified two potential solutions: start from scratch by building a new connector, or borrow from an existing connector, likely in either cloudflared or WARP.

The following table provides an overview of the tradeoffs of the two approaches:

Starting today, the introduction of WARP Connector opens up new possibilities: server initiated (SIP/VOIP) flows; site-to-site connectivity, connecting branches, headquarters, and cloud platforms; and even mesh-like networking with WARP-to-WARP. Under the hood, this new connector is an extension of warp-client that can act as a virtual router for any subnet within the network to on/off-ramp traffic through Cloudflare.

By building on WARP, we were able to take advantage of its design, where it creates a virtual network interface on the host to logically subdivide the physical interface (NIC) for the purpose of routing IP traffic. This enables us to send bidirectional traffic through the WireGuard/MASQUE tunnel that’s maintained between the host and Cloudflare edge. By virtue of this architecture, customers also get the added benefit of visibility into the true source IP of the client.

WARP Connector can be easily deployed on the default gateway without any additional routing changes. Alternatively, static routes can be configured for specific CIDRs that need to be routed via WARP Connector, and the static routes can be configured on the default gateway or on every host in that subnet.

Here we’ll walk through a couple of key reasons why you may want to deploy our new connector, but remember that this solution can support numerous services, such as Microsoft’s System Center Configuration Manager (SCCM), Active Directory server updates, VOIP and SIP traffic, and developer workflows with complex CI/CD pipeline interaction. It’s also important to note this connector can either be run alongside cloudflared and Magic WAN, or can be a standalone remote access and site-to-site connector to the Cloudflare Global network.

For users to establish a voice or video call over a VOIP software service, typically a SIP server within the private network brokers the connection using the last known IP address of the end-user. However, if traffic is proxied anywhere along the path, this often results in participants only receiving partial voice or data signals. With the WARP Connector, customers can now apply granular policies to these services for secure access, fortifying VOIP infrastructure within their Zero Trust framework.

An organization’s DevOps ecosystem is generally built out of many parts, but a CI/CD server such as Jenkins or Teamcity is the epicenter of all development activities. Hence, securing that CI/CD server is critical. With the WARP Connector and WARP Client, organizations can secure the entire CI/CD pipeline and also streamline it easily.

Let's look at a typical CI/CD pipeline for a Kubernetes application. The environment is set up as depicted in the diagram above, with WARP clients on the developer and QA laptops and a WARP Connector securely connecting the CI/CD server and staging servers on different networks:

1. Typically, the CI/CD pipeline is triggered when a developer commits their code change, invoking a webhook on the CI/CD server.

2. Once the images are built, it's time to deploy the code, which is typically done in stages: test, staging and production.

3. Notifications are sent to the developer and QA engineer to notify them when the images are ready in the test/staging environments.

4. QA engineers receive the notifications via webhook from the CI/CD servers to kick-start their monitoring and troubleshooting workflow.

With WARP Connector, customers can easily connect their developers to the tools in the DevOps ecosystem by keeping the ecosystem private and not exposing it to the public. Once the DevOps ecosystem is securely connected to Cloudflare, granular security policies can be easily applied to secure access to the CI/CD pipeline.

Organizations running Microsoft AD Servers or non-web application servers often need to identify the true source IP address for auditing or policy application. If these requirements exist, WARP Connector simplifies this, offering solutions without adding NAT boundaries. This can be useful to rate-limit unhealthy source IP addresses, for ACL-based policies within the perimeter, or to collect additional diagnostics from end-users.

As part of this launch, we’re making some changes to the Cloudflare One Dashboard to better highlight our different network on/off ramp options. As of today, a new “Network” tab will appear on your dashboard. This will be the new home for the Cloudflare Tunnel UI.

We are also introducing the new “Routes” tab next to “Tunnels”. This page will present an organizational view of customer’s virtual networks, Cloudflare Tunnels, and routes associated with them. This new page helps answer a customer’s questions pertaining to their network configurations, such as: “Which Cloudflare Tunnel has the route to my host 192.168.1.2 ” or “If a route for CIDR 192.168.2.1/28 exists, how can it be accessed” or “What are the overlapping CIDRs in my environment and which VNETs do they belong to?”. This is extremely useful for customers who have very complex enterprise networks that use the Cloudflare dashboard for troubleshooting connectivity issues.

Embarking on your WARP Connector journey is straightforward. Currently deployable on Linux hosts, users can select “create a Tunnel” and pick from either cloudflared or WARP to deploy straight from the dashboard. Follow our developer documentation to get started in a few easy steps. In the near future we will be adding support for more platforms where WARP Connectors can be deployed.

Thank you to all of our private beta customers for their invaluable feedback. Moving forward, our immediate focus in the coming quarters is on simplifying deployment, mirroring that of cloudflared, and enhancing high availability through redundancy and failover mechanisms.

Stay tuned for more updates as we continue our journey in innovating and enhancing the Cloudflare One platform. We're excited to see how our customers leverage WARP Connector to transform their connectivity and security landscape.

Ping was born in 1983 when the Internet needed a simple, effective way to measure reachability and distance. In short, ping (and subsequent utilities like traceroute and MTR)  provides users with a quick way to validate whether one machine can communicate with another. Fast-forward to today and these network utility tools have become ubiquitous. Not only are they now the de facto standard for troubleshooting connectivity and network performance issues, but they also improve our overall quality of life by acting as a common suite of tools almost all Internet users are comfortable employing in their day-to-day roles and responsibilities.

Making network utility tools work as expected is very important to us, especially now as more and more customers are building their private networks on Cloudflare. Over 10,000 teams now run a private network on Cloudflare. Some of these teams are among the world's largest enterprises, some are small crews, and yet others are hobbyists, but they all want to know - can I reach that?

That’s why today we’re excited to incorporate support for these utilities into our already expansive troubleshooting toolkit for Cloudflare Zero Trust. To get started, sign up to receive beta access and start using the familiar debugging tools that we all know and love like ping, traceroute, and MTR to test connectivity to private network destinations running behind Tunnel.

With Cloudflare Zero Trust, we’ve made it ridiculously easy to build your private network on Cloudflare. In fact, it takes just three steps to get started. First, download Cloudflare’s device client, WARP, to connect your users to Cloudflare. Then, create identity and device aware policies to determine who can reach what within your network. And finally, connect your network to Cloudflare with Tunnel directly from the Zero Trust dashboard.

We’ve designed Cloudflare Zero Trust to act as a single pane of glass for your organization. This means that after you’ve deployed any part of our Zero Trust solution, whether that be ZTNA or SWG, you are clicks, not months, away from deploying Browser Isolation, Data Loss Prevention, Cloud Access Security Broker, and Email Security. This is a stark contrast from other solutions on the market which may require distinct implementations or have limited interoperability across their portfolio of services.

It’s that simple, but if you’re looking for more prescriptive guidance watch our demo below to get started:

To get started, sign-up for early access to the closed beta. If you’re interested in learning more about how it works and what else we will be launching in the future, keep scrolling.

Ping, traceroute and MTR are all powered by the same underlying protocol, ICMP. Every ICMP message has 8-bit type and code fields, which define the purpose and semantics of the message. While ICMP has many types of messages, the network diagnostic tools mentioned above make specific use of the echo request and echo reply message types.

Every ICMP message has a type, code and checksum. As you may have guessed from the name, an echo reply is generated in response to the receipt of an echo request, and critically, the request and reply have matching identifiers and sequence numbers. Make a mental note of this fact as it will be useful context later in this blog post.

As you may expect, each one of these utilities comes with its own unique nuances, but don’t worry. We’re going to provide a quick refresher on each before getting into the nitty-gritty details.

Ping works by sending a sequence of echo request packets to the destination. Each router hop between the sender and destination decrements the TTL field of the IP packet containing the ICMP message and forwards the packet to the next hop. If a hop decrements the TTL to 0 before reaching the destination, or doesn’t have a next hop to forward to, it will return an ICMP error message – “TTL exceeded” or “Destination host unreachable” respectively – to the sender. A destination which speaks ICMP will receive these echo request packets and return matching echo replies to the sender. The same process of traversing routers and TTL decrementing takes place on the return trip. On the sender’s machine, ping reports the final TTL of these replies, as well as the roundtrip latency of sending and receiving the ICMP messages to the destination. From this information a user can determine the distance between themselves and the origin server, both in terms of number of network hops and time.

As we’ve just outlined, while helpful, the output provided by ping is relatively simple. It does provide some useful information, but we will generally want to follow up this request with a traceroute to learn more about the specific path to a given destination. Similar to ping, traceroutes start by sending an ICMP echo request. However, it handles TTL a bit differently. You can learn more about why that is the case in our Learning Center, but the important takeaway is that this is how traceroutes are able to map and capture the IP address of each unique hop on the network path. This output makes traceroute an incredibly powerful tool to understanding not only if a machine can connect to another, but also how it will get there! And finally, we’ll cover MTR. We’ve grouped traceroute and MTR together for now as they operate in an extremely similar fashion. In short, the output of an MTR will provide everything traceroute can, but with some additional, aggregate statistics for each unique hop. MTR will also run until explicitly stopped allowing users to receive a statistical average for each hop on the path.

Now that we’ve had a quick refresher, let’s say I cannot connect to my private application server. With ICMP support enabled on my Zero Trust account, I could run a traceroute to see if the server is online.

Here is simple example from one of our lab environments:

Then, if my server is online, traceroute should output something like the following:

traceroute -I 172.16.10.120
traceroute to 172.16.10.120 (172.16.10.120), 64 hops max, 72 byte packets
 1  172.68.101.57 (172.68.101.57)  20.782 ms  12.070 ms  15.888 ms
 2  172.16.10.100 (172.16.10.100)  31.508 ms  30.657 ms  29.478 ms
 3  172.16.10.120 (172.16.10.120)  40.158 ms  55.719 ms  27.603 ms

Let’s examine this a bit deeper. Here, the first hop is the Cloudflare data center where my Cloudflare WARP device is connected via our Anycast network. Keep in mind this IP may look different depending on your location. The second hop will be the server running cloudflared. And finally, the last hop is my application server.

Conversely, if I could not connect to my app server I would expect traceroute to output the following:

traceroute -I 172.16.10.120
traceroute to 172.16.10.120 (172.16.10.120), 64 hops max, 72 byte packets
 1  172.68.101.57 (172.68.101.57)  20.782 ms  12.070 ms  15.888 ms
 2  * * *
 3  * * *

In the example above, this means the ICMP echo requests are not reaching cloudflared. To troubleshoot, first I will make sure cloudflared is running by checking the status of the Tunnel in the ZeroTrust dashboard. Then I will check if the Tunnel has a route to the destination IP. This can be found in the Routes column of the Tunnels table in the dashboard. If it does not, I will add a route to my Tunnel to see if this changes the output of my traceroute.

Once I have confirmed that cloudflared is running and the Tunnel has a route to my app server, traceroute will show the following:

raceroute -I 172.16.10.120
traceroute to 172.16.10.120 (172.16.10.120), 64 hops max, 72 byte packets
 1  172.68.101.57 (172.68.101.57)  20.782 ms  12.070 ms  15.888 ms
 2  172.16.10.100 (172.16.10.100)  31.508 ms  30.657 ms  29.478 ms
 3  * * *

However, it looks like we still can’t quite reach the application server. This means the ICMP echo requests reached cloudflared, but my application server isn’t returning echo replies. Now, I can narrow down the problem to my application server, or communication between cloudflared and the app server. Perhaps the machine needs to be rebooted or there is a firewall rule in place, but either way we have what we need to start troubleshooting the last hop. With ICMP support, we now have many network tools at our disposal to troubleshoot connectivity end-to-end.

Note that the route cloudflared to origin is always shown as a single hop, even if there are one or more routers between the two. This is because cloudflared creates its own echo request to the origin, instead of forwarding the original packets. In the next section we will explain the technical reason behind it.

A few quarters ago, Cloudflare Zero Trust extended support for UDP end-to-end as well. Since UDP and ICMP are both datagram-based protocols, within the Cloudflare network we can reuse the same infrastructure to proxy both UDP and ICMP traffic. To do this, we send the individual datagrams for either protocol over a QUIC connection using QUIC datagrams between Cloudflare and the cloudflared instances within your network.

With UDP, we establish and maintain a session per client/destination pair, such that we are able to send only the UDP payload and a session identifier in datagrams. In this way, we don’t need to send the IP and port to which the UDP payload should be forwarded with every single packet.

However, with ICMP we decided that establishing a session like this is far too much overhead, given that typically only a handful of ICMP packets are exchanged between endpoints. Instead, we send the entire IP packet (with the ICMP payload inside) as a single datagram.

What this means is that cloudflared can read the destination of the ICMP packet from the IP header it receives. While this conveys the eventual destination of the packet to cloudflared, there is still work to be done to actually send the packet. Cloudflared cannot simply send out the IP packet it receives without modification, because the source IP in the packet is still the original client IP, and not a source that is routable to the cloudflared instance itself.

To receive ICMP echo replies in response to the ICMP packets it forwards, cloudflared must apply a source NAT to the packet. This means that when cloudflared receives an IP packet, it must complete the following:

• Read the destination IP address of the packet

• Strip off the IP header to get the ICMP payload

• Send the ICMP payload to the destination, meaning the source address of the ICMP packet will be the IP of a network interface to which cloudflared can bind

• When cloudflared receives replies on this address, it must rewrite the destination address of the received packet (destination because the direction of the packet is reversed) to the original client source address

Network Address Translation like this is done all the time for TCP and UDP, but is much easier in those cases because ports can be used to disambiguate cases where the source and destination IPs are the same. Since ICMP packets do not have ports associated with them, we needed to find a way to map packets received from the upstream back to the original source which sent cloudflared those packets.

For example, imagine that two clients 192.0.2.1 and 192.0.2.2 both send an ICMP echo request to a destination 10.0.0.8. As we previously outlined, cloudflared must rewrite the source IPs of these packets to a source address to which it can bind. In this scenario, when the echo replies come back, the IP headers will be identical: source=10.0.0.8 destination=<cloudflared’s IP>. So, how can cloudflared determine which packet needs to have its destination rewritten to 192.0.2.1 and which to 192.0.2.2?

To solve this problem, we use fields of the ICMP packet to track packet flows, in the same way that ports are used in TCP/UDP NAT. The field we’ll use for this purpose is the Echo ID. When an echo request is received, conformant ICMP endpoints will return an echo reply with the same identifier as was received in the request. This means we can send the packet from 192.0.2.1 with ID 23 and the one from 192.0.2.2 with ID 45, and when we receive replies with IDs 23 and 45, we know which one corresponds to each original source.

Of course this strategy only works for ICMP echo requests, which make up a relatively small percentage of the available ICMP message types. For security reasons, however, and owing to the fact that these message types are sufficient to implement the ubiquitous ping and traceroute functionality that we’re after, these are the only message types we currently support. We’ll talk through the security reasons for this choice in the next section.

Generally, applications need to send ICMP packets through raw sockets. Applications have control of the IP header using this socket, so it requires elevated privileges to open. Whereas the IP header for TCP and UDP packets are added on send and removed on receive by the operating system. To adhere to security best-practices, we don’t really want to run cloudflared with additional privileges. We needed a better solution. To solve this, we found inspiration in the ping utility, which you’ll note can be run by any user, without elevated permissions. So then, how does ping send ICMP echo requests and listen for echo replies as a normal user program? Well, the answer is less satisfying: it depends (on the platform). And as cloudflared supports all the following platforms, we needed to answer this question for each.

On linux, ping opens a datagram socket for the ICMP protocol with the syscall socket(PF_INET, SOCK_DGRAM, PROT_ICMP). This type of socket can only be opened if the group ID of the user running the program is in /proc/sys/net/ipv4/ping_group_range, but critically, the user does not need to be root. This socket is “special” in that it can only send ICMP echo requests and receive echo replies. Great! It also has a conceptual “port” associated with it, despite the fact that ICMP does not use ports. In this case, the identifier field of echo requests sent through this socket are rewritten to the “port” assigned to the socket. Reciprocally, echo replies received by the kernel which have the same identifier are sent to the socket which sent the request.

Therefore, on linux cloudflared is able to perform source NAT for ICMP packets simply by opening a unique socket per source IP address. This rewrites the identifier field and source address of the request. Replies are delivered to this same socket meaning that cloudflared can easily rewrite the destination IP address (destination because the packets are flowing to the client) and echo identifier back to the original values received from the client.

On Darwin (the UNIX-based core set of components which make up macOS), things are similar, in that we can open an unprivileged ICMP socket with the same syscall socket(PF_INET, SOCK_DGRAM, PROT_ICMP). However, there is an important difference. With Darwin the kernel does not allocate a conceptual “port” for this socket, and thus, when sending ICMP echo requests the kernel does not rewrite the echo ID as it does on linux. Further, and more importantly for our purposes, the kernel does not demultiplex ICMP echo replies to the socket which sent the corresponding request using the echo identifier. This means that on macOS, we effectively need to perform the echo ID rewriting manually. In practice, this means that when cloudflared receives an echo request on macOS, it must choose an echo ID which is unique for the destination. Cloudflared then adds a key of (chosen echo ID, destination IP) to a mapping it then maintains, with a value of (original echo ID, original source IP). Cloudflared rewrites the echo ID in the echo request packet to the one it chose and forwards it to the destination. When it receives a reply, it is able to use the source IP address and echo ID to look up the client address and original echo ID and rewrite the echo ID and destination address in the reply packet before forwarding it back to the client.

Finally, we arrived at Windows which conveniently provides a Win32 API IcmpSendEcho that sends echo requests and returns echo reply, timeout or error. For ICMPv6 we just had to use Icmp6SendEcho. The APIs are in C, but cloudflared can call them through CGO without a problem. If you also need to call these APIs in a Go program, checkout our wrapper for inspiration.

And there you have it! That’s how we built the most exciting ping release since 1983. Overall, we’re thrilled to announce this new feature and can’t wait to get your feedback on ways we can continue improving our implementation moving forward.

Support for these ICMP-based utilities is just the beginning of how we’re thinking about improving our Zero Trust administrator experience. Our goal is to continue providing tools which make it easy to identify issues within the network that impact connectivity and performance.

Looking forward, we plan to add more dials and knobs for observability with announcements like Digital Experience Monitoring across our Zero Trust platform to help users proactively monitor and stay alert to changing network conditions. In the meantime, try applying Zero Trust controls to your private network for free by signing up today.

Today, organizations of all shapes and sizes lack visibility and insight into the digital experiences of their end-users. This often leaves IT and network administrators feeling vulnerable to issues beyond their control which hinder productivity across their organization. When issues inevitably arise, teams are left with a finger-pointing exercise. They’re unsure if the root cause lies within the first, middle or last mile and are forced to file a ticket for the respective owners of each. Ideally, each team sprints into investigation to find the needle in the haystack. However, once each side has exhausted all resources, they once again finger point upstream. To help solve this problem, we’re building a new product, Digital Experience Monitoring, which will enable administrators to pinpoint and resolve issues impacting end-user connectivity and performance.

To get started, sign up to receive early access. If you’re interested in learning more about how it works and what else we will be launching in the near future, keep scrolling.

Over the last year, we’ve received an overwhelming amount of feedback that users want to see the intelligence that Cloudflare possesses from our unique perspective, helping power the Internet embedded within our Zero Trust platform. Today, we’re excited to announce just that. Throughout the coming weeks, we will be releasing a number of features for our Digital Experience Monitoring product which will provide you with unparalleled visibility into the performance and connectivity of your users, applications, and networks.

With data centers in more than 275 cities across the globe, Cloudflare handles an average of 39 million HTTP requests and 22 million DNS requests every second. And with more than one billion unique IP addresses connecting to our network we have one of the most representative views of Internet traffic on the planet. This unique point of view on the Internet will be able to provide you deep insight into the digital experience of your users. You can think of Digital Experience Monitoring as the air traffic control tower of your Zero Trust deployment providing you with the data-driven insights you need to help each user arrive at their destination as quickly and smoothly as possible.

When we began to research Digital Experience Monitoring, we started with you: the user. Users want a single dashboard to monitor user, application, and network availability and performance. Ultimately, this dashboard needs to help users cohesively understand the minute-by-minute experiences of their end-users so that they can quickly and easily resolve issues impacting productivity. Simply put, users want hop by hop visibility into the network traffic paths of each and every user in their organization.

From our conversations with our users, we understand that providing this level of insight has become even more critical and challenging in an increasingly work-from-anywhere world.

With this product, we want to empower you to answer the hard questions. The questions in the kind of tickets we all wish we could avoid when they appear in the queue like “Why can’t the CEO reach SharePoint while traveling abroad?”. Could it have been a poor Wi-Fi signal strength in the hotel? High CPU on the device? Or something else entirely?

Without the proper tools, it’s nearly impossible to answer these questions. Regardless, it’s all but certain that this investigation will be a time-consuming endeavor whether it has a happy ending or not. Traditionally, the investigation will go something like this. IT professionals will start their investigation by looking into the first-mile which may include profiling the health of the endpoint (i.e. CPU or RAM utilization), Wi-Fi signal strength, or local network congestion. With any luck at all, the issue is identified, and the pain stops here.

Unfortunately, teams rarely have the tools required to prove these theories out so, frustrated, they move on to everything in between the user and the application. Here we might be looking for an outage or a similar issue with a local Internet Service Provider (ISP). Again, even if we do have reason to believe that this is the issue it can be difficult to prove this beyond a reasonable doubt.

Reluctantly, we move onto the last mile. Here we’ll be looking to validate that the application in question is available and if so, how quickly we can establish a meaningful connection (Time to First Byte, First Contentful Paint, packet loss) to this application. More often than not, the lead investigator is left with more questions than answers after attempting to account for the hop by hop degradation. Then, by the time the ticket can be closed, the CEO has boarded a flight back home and the issue is no longer relevant.

With Digital Experience Monitoring, we’ve set out to build the tools you need to quickly find the needle in the haystack and resolve issues related to performance and connectivity. However, we also understand that availability and performance are just shorthand measures for gauging the complete experience of our customers. Of course, there is much more to a good user experience than just insights and analytics. We will continue to pay close attention to other key metrics around the volume of support tickets, contact rate, and time to resolution as other significant indicators of a healthy deployment. Internally, when shared with Cloudflare, this telemetry data will help enable our support teams to quickly validate and report issues to continuously improve the overall Zero Trust experience.

“As CIO, I am focused on outfitting Cintas with technology and systems that help us deliver on our promises for the 1 million plus businesses we serve across North America.  As we leverage more cloud based technology to create differentiated experiences for our customers, Cloudflare is an integral part of delivering on that promise.”  - Matthew Hough, CIO, Cintas

In the coming weeks, we’ll be launching three new features. Here is a look ahead at what you can expect when you sign up for early access.

One of the common challenges of deploying software is understanding how it is performing in the wild. For Zero Trust, this might mean trying to answer how many of your end-users are running our device agent, Cloudflare WARP, for instance. Then, of those users, you may want to see how many users have enabled, paused, or disabled the agent during the early phases of a deployment. Shortly after finding these answers, you may want to see if there is any correlation between the users who pause their WARP agent and the data center through which they are connected to Cloudflare. These are the kinds of answers you will be able to find with Zero Trust Fleet Status. These insights will be available at both an organizational and per-user level.

Oftentimes, the issues being reported to IT professionals will fall outside their control. For instance, an outage for a popular SaaS application can derail an otherwise perfectly productive day. But, these issues would become much easier to address if you knew about them before your users began to report them. For instance, this foresight would allow you to proactively communicate issues to the organization and get ahead of the flood of IT tickets destined for your inbox. With Synthetic Application Monitoring, we’ll be providing Zero Trust administrators the ability to create synthetic application tests to public-facing endpoints.

With this tool, users can initiate periodic traceroute and HTTP GET requests destined for a given public IP or hostname. In the dashboard, we’ll then surface global and user-level analytics enabling administrators to easily identify trends across their organization. Users will also have the ability to filter results down to identify individual users or devices who are most impacted by these outages.

Once an issue with a given user or device is identified through the Synthetic Application Monitoring reports highlighted above, administrators will be able to view hop-by-hop telemetry data outlining the critical path to public facing endpoints. Administrators will have the ability to view this data represented graphically and export any data which may be relevant outside the context of Zero Trust.

According to Gartner®, “by 2026 at least 60% of I&O leaders will use Digital Experience Monitoring (DEM) to measure application, services and endpoint performance from the user’s viewpoint, up from less than 20% in 2021.” The items at the top of our roadmap will be just the beginning to Cloudflare’s approach to bringing our intelligence into your Zero Trust deployments.

Perhaps what we’re most excited about with this product is that users on all Zero Trust plans will be able to get started at no additional cost and then upgrade their plans for more advanced features and usage moving forward. Join our waitlist to be notified when these initial capabilities are available and receive early access.

Gartner Market Guide for Digital Experience Monitoring, 03/28/2022, Mrudula Bangera, Padraig Byrne, Gregg Siegfried.GARTNER is the registered trademark and service mark of Gartner Inc., and/or its affiliates in the U.S. and/or internationally and has been used herein with permission. All rights reserved.

Millions of users rely on Cloudflare WARP to connect to the Internet through Cloudflare’s network. Individuals download the mobile or desktop application and rely on the Wireguard-based tunnel to make their browser faster and more private. Thousands of enterprises trust Cloudflare WARP to connect employees to our Secure Web Gateway and other Zero Trust services as they navigate the Internet.

We’ve heard from both groups of users that they also want to connect to other devices running WARP. Teams can build a private network on Cloudflare’s network today by connecting WARP on one side to a Cloudflare Tunnel, GRE tunnels, or IPSec tunnels on the other end. However, what if both devices already run WARP?

Starting today, we’re excited to make it even easier to build a network on Cloudflare with the launch of WARP-to-WARP connectivity. With a single click, any device running WARP in your organization can reach any other device running WARP. Developers can connect to a teammate's machine to test a web server. Administrators can reach employee devices to troubleshoot issues. The feature works with our existing private network on-ramps, like the tunnel options listed above. All with Zero Trust rules built in.

To get started, sign-up to receive early access to our closed beta. If you’re interested in learning more about how it works and what else we will be launching in the future, keep scrolling.

We understand that adopting a Zero Trust architecture can feel overwhelming at times. With Cloudflare One, our mission is to make Zero Trust prescriptive and approachable regardless of where you are on your journey today. To help users navigate the uncertain, we created resources like our vendor-agnostic Zero Trust Roadmap which lays out a battle-tested path to Zero Trust. Within our own products and services, we’ve launched a number of features to bridge the gap between the networks you manage today and the network you hope to build for your organization in the future.

Ultimately, our goal is to enable you to overlay your network on Cloudflare however you want, whether that be with existing hardware in the field, a carrier you already partner with, through existing technology standards like IPsec tunnels, or more Zero Trust approaches like WARP or Tunnel. It shouldn’t matter which method you chose to start with, the point is that you need the flexibility to get started no matter where you are in this journey. We call these connectivity options on-ramps and off-ramps.

The model laid out above allows users to start by defining their specific needs and then customize their deployment by choosing from a set of fully composable on and offramps to connect their users and devices to Cloudflare. This means that customers are able to leverage any of these solutions together to route traffic seamlessly between devices, offices, data centers, cloud environments, and self-hosted or SaaS applications.

One example of a deployment we’ve seen thousands of customers be successful with is what we call WARP-to-Tunnel. In this deployment, the on-ramp Cloudflare WARP ensures end-user traffic reaches Cloudflare’s global network in a secure and performant manner. The off-ramp Cloudflare Tunnel then ensures that, after your Zero Trust rules have been enforced, we have secure, redundant, and reliable paths to land user traffic back in your distributed, private network.

This is a great example of a deployment that is ideal for users that need to support public to private traffic flows (i.e. North-South)

But what happens when you need to support private to private traffic flows (i.e. East-West) within this deployment?

Starting today, devices on-ramping to Cloudflare with WARP will also be able to off-ramp to each other. With this announcement, we’re adding yet another tool to leverage in new or existing deployments that provides users with stronger network fabric to connect users, devices, and autonomous systems.

This means any of your Zero Trust-enrolled devices will be able to securely connect to any other device on your Cloudflare-defined network, regardless of physical location or network configuration. This unlocks the ability for you to address any device running WARP in the exact same way you are able to send traffic to services behind a Cloudflare Tunnel today. Naturally, all of this traffic flows through our in-line Zero Trust services, regardless of how it gets to Cloudflare, and this new connectivity announced today is no exception.

To power all of this, we now track where WARP devices are connected to, in Cloudflare’s global network, the same way we do for Cloudflare Tunnel. Traffic meant for a specific WARP device is relayed across our network, using Argo Smart Routing, and piped through the transport that routes IP packets to the appropriate WARP device. Since this traffic goes through our Zero Trust Secure Web Gateway — allowing various types of filtering — it means we upgrade and downgrade traffic from purely routed IP packets to fully proxied TLS connections (as well as other protocols). In the case of using SSH to remotely access a colleague’s WARP device, this means that your traffic is eligible for SSH command auditing as well.

If you already deployed Cloudflare WARP to your organization, then your IT department will be excited to learn they can use this new connectivity to reach out to any device running Cloudflare WARP. Connecting via SSH, RDP, SMB, or any other service running on the device is now simpler than ever. All of this provides Zero Trust access for the IT team members, with their actions being secured in-line, audited, and pushed to your organization’s logs.

Or, maybe you are done with designing a new function of an existing product and want to let your team members check it out at their own convenience. Sending them a link with your private IP — assigned by Cloudflare — will do the job. Their devices will see your machine as if they were in the same physical network, despite being across the other side of the world.

The usefulness doesn’t end with humans on both sides of the interaction: the weekend has arrived, and you have finally set out to move your local NAS to a host provider where you run a virtual machine. By running Cloudflare WARP on it, similarly to your laptop, you can now access your photos using the virtual machine’s private IP. This was already possible with WARP to Tunnel; but with WARP-to-WARP, you also get connectivity in reverse direction, where you can have the virtual machine periodically rsync/scp files from your laptop as well. This means you can make any server initiate traffic towards the rest of your Zero Trust organization with this new type of connectivity.

This feature will be available on all plans at no additional cost. To get started with this new feature, add your name to the closed beta, and we’ll notify you once you’ve been enrolled. Then, you’ll simply ensure that at least two devices are enrolled in Cloudflare Zero Trust and have the latest version of Cloudflare WARP installed.

This new feature builds upon the existing benefits of Cloudflare Zero Trust, which include enhanced connectivity, improved performance, and streamlined access controls. With the ability to connect to any other device in their deployment, Zero Trust users will be able to take advantage of even more robust security and connectivity options.

To get started in minutes, create a Zero Trust account, download the WARP agent, enroll these devices into your Zero Trust organization, and start creating Zero Trust policies to establish fast, secure connectivity between these devices. That’s it.

With Cloudflare One, building your private network on Cloudflare is easy. What is not so easy is maintaining the security of your private network over time. Resources are constantly being spun up and down with new users being added and removed on a daily basis, making it painful to manage over time.

That’s why today we’re opening a closed beta for our new Zero Trust network discovery tool. With Private Network Discovery, our Zero Trust platform will now start passively cataloging both the resources being accessed and the users who are accessing them without any additional configuration required. No third party tools, commands, or clicks necessary.

To get started, sign-up for early access to the closed beta and gain instant visibility into your network today. If you’re interested in learning more about how it works and what else we will be launching in the future for general availability, keep scrolling.

One of the most laborious aspects of migrating to Zero Trust is replicating the security policies which are active within your network today. Even if you do have a point-in-time understanding of your environment, networks are constantly evolving with new resources being spun up dynamically for various operations. This results in a constant cycle to discover and secure applications which creates an endless backlog of due diligence for security teams.

That’s why we built Private Network Discovery. With Private Network Discovery, organizations can easily gain complete visibility into the users and applications that live on their network without any additional effort on their part. Simply connect your private network to Cloudflare, and we will surface any unique traffic we discover on your network to allow you to seamlessly translate them into Cloudflare Access applications.

Building out a private network has two primary components: the infrastructure side, and the client side.

The infrastructure side of the equation is powered by Cloudflare Tunnel, which simply connects your infrastructure (whether that be a single application, many applications, or an entire network segment) to Cloudflare. This is made possible by running a simple command-line daemon in your environment to establish multiple secure, outbound-only links to Cloudflare. Simply put, Tunnel is what connects your network to Cloudflare.

On the other side of this equation, you need your end users to be able to easily connect to Cloudflare and, more importantly, your network. This connection is handled by our robust device agent, Cloudflare WARP. This agent can be rolled out to your entire organization in just a few minutes using your in-house MDM tooling, and it establishes a secure connection from your users’ devices to the Cloudflare network.

Now that we have your infrastructure and your users connected to Cloudflare, it becomes easy to tag your applications and layer on Zero Trust security controls to verify both identity and device-centric rules for each and every request on your network.

As we mentioned earlier, we built this feature to help your team gain visibility into your network by passively cataloging unique traffic destined for an RFC 1918 or RFC 4193 address space. By design, this tool operates in an observability mode whereby all applications are surfaced, but are tagged with a base state of “Unreviewed.”

The Network Discovery tool surfaces all origins within your network, defined as any unique IP address, port, or protocol. You can review the details of any given origin and then create a Cloudflare Access application to control access to that origin. It’s also worth noting that Access applications may be composed of more than one origin.

Let’s take, for example, a privately hosted video conferencing service, Jitsi. I’m using this example as our team actually uses this service internally to test our new features before pushing them into production. In this scenario, we know that our self-hosted instance of Jitsi lives at 10.0.0.1:443. However, as this is a video conferencing application, it communicates on both tcp:10.0.0.1:443 and udp:10.0.0.1:10000. Here we would select one origin and assign it an application name.

As a note, during the closed beta you will not be able to view this application in the Cloudflare Access application table. For now, these application names will only be reflected in the discovered origins table of the Private Network Discovery report. You will see them reflected in the Application name column exclusively. However, when this feature goes into general availability you’ll find all the applications you have created under Zero Trust > Access > Applications as well.

After you have assigned an application name and added your first origin, tcp:10.0.0.1:443, you can then follow the same pattern to add the other origin, udp:10.0.0.1:10000, as well. This allows you to create logical groupings of origins to create a more accurate representation of the resources on your network.

By creating an application, our Network Discovery tool will automatically update the status of these individual origins from “Unreviewed'' to “In-Review.” This will allow your team to easily track the origin’s status. From there, you can drill further down to review the number of unique users accessing a particular origin as well as the total number of requests each user has made. This will help equip your team with the information it needs to create identity and device-driven Zero Trust policies. Once your team is comfortable with a given application's usage, you can then manually update the status of a given application to be either “Approved” or “Unapproved”.

Our closed beta launch is just the beginning. While the closed beta release supports creating friendly names for your private network applications, those names do not currently appear in the Cloudflare Zero Trust policy builder.

As we move towards general availability, our top priority will be making it easier to secure your private network based on what is surfaced by the Private Network Discovery tool. With the general availability launch, you will be able to create Access applications directly from your Private Network Discovery report, reference your private network applications in Cloudflare Access and create Zero Trust security policies for those applications, all in one singular workflow.

As you can see, we have exciting plans for this tool and will continue investing in Private Network Discovery in the future. If you’re interested in gaining access to the closed beta, sign-up here and be among the first users to try it out!

A little over a decade ago, Cloudflare launched at TechCrunch Disrupt. At the time, we talked about three core principles that differentiated Cloudflare from traditional security vendors: be more secure, more performant, and ridiculously easy to use. Ease of use is at the heart of every decision we make, and this is no different for Cloudflare Tunnel.

That’s why we’re thrilled to announce today that creating tunnels, which previously required up to 14 commands in the terminal, can now be accomplished in just three simple steps directly from the Zero Trust dashboard.

If you’ve heard enough, jump over to sign-up/teams to unplug your VPN and start building your private network with Cloudflare. If you’re interested in learning more about our motivations for this release and what we’re building next, keep scrolling.

Cloudflare Tunnel is the easiest way to connect your infrastructure to Cloudflare, whether that be a local HTTP server, web services served by a Kubernetes cluster, or a private network segment. This connectivity is made possible through our lightweight, open-source connector, cloudflared. Our connector offers high-availability by design, creating four long-lived connections to two distinct data centers within Cloudflare’s network. This means that whether an individual connection, server, or data center goes down, your network remains up. Users can also maintain redundancy within their own environment by deploying multiple instances of the connector in the event a single host goes down for one reason or another.

Historically, the best way to deploy our connector has been through the cloudflared CLI. Today, we’re thrilled to announce that we have launched a new solution to remotely create, deploy, and manage tunnels and their configuration directly from the Zero Trust dashboard. This new solution allows our customers to provide their workforce with Zero Trust network access in 15 minutes or less.

Command line interfaces are exceptional at what they do. They allow users to pass commands at their console or terminal and interact directly with the operating system. This precision grants users exact control over the interactions they may have with a given program or service where this exactitude is required.

However, they also have a higher learning curve and can be less intuitive for new users. This means users need to carefully research the tools they wish to use prior to trying them out. Many users don’t have the luxury to perform this level of research, only to test a program and find it’s not a great fit for their problem.

Conversely, GUIs, like our Zero Trust dashboard, have the flexibility to teach by doing. Little to no program knowledge is required to get started. Users can be intuitively led to their desired results and only need to research how and why they completed certain steps after they know this solution fits their problem.

When we first released Cloudflare Tunnel, it had less than ten distinct commands to get started. We now have far more than this, as well as a myriad of new use cases to invoke them. This has made what used to be an easy-to-navigate CLI library into something more cumbersome for users just discovering our product.

Simple typos led to immense frustration for some users. Imagine, for example, a user needs to advertise IP routes for their private network tunnel. It can be burdensome to remember cloudflared tunnel route ip add <IP/CIDR>. Through the Zero Trust dashboard, you can forget all about the semantics of the CLI library. All you need to know is the name of your tunnel and the network range you wish to connect through Cloudflare. Simply enter my-private-net (or whatever you want to call it), copy the installation script, and input your network range. It’s that simple. If you accidentally type an invalid IP or CIDR block, the dashboard will provide an actionable, human-readable error and get you on track.

Whether you prefer the CLI or GUI, they ultimately achieve the same outcome through different means. Each has merit and ideally users get the best of both worlds in one solution.

Tunnels have typically required a locally managed configuration file to route requests to their appropriate destinations. This configuration file was never created by default, but was required for almost every use case. This meant that users needed to use the command line to create and populate their configuration file using examples from developer documentation. As functionality has been added into cloudflared, configuration files have become unwieldy to manage. Understanding the parameters and values to include as well as where to include them has become a burden for users. These issues were often difficult to catch with the naked eye and painful to troubleshoot for users.

We also wanted to improve the concept of tunnel permissions with our latest release. Previously, users were required to manage two distinct tokens: The cert.pem and the Tunnel_UUID.json file. In short, cert.pem, issued during the cloudflared tunnel login command, granted the ability to create, delete, and list tunnels for their Cloudflare account through the CLI. Tunnel_UUID.json, issued during the cloudflared tunnel create <NAME> command, granted the ability to run a specified tunnel. However, since tunnels can now be created directly from your Cloudflare account in the Zero Trust dashboard, there is no longer a requirement to authenticate your origin prior to creating a tunnel. This action is already performed during the initial Cloudflare login event.

With today’s release, users no longer need to manage configuration files or tokens locally. Instead, Cloudflare will manage this for you based on the inputs you provide in the Zero Trust dashboard. If users typo a hostname or service, they’ll know well before attempting to run their tunnel, saving time and hassle. We’ll also manage your tokens for you, and if you need to refresh your tokens at some point in the future, we’ll rotate the token on your behalf as well.

We commonly refer to Cloudflare Tunnel as an “on-ramp” to our Zero Trust platform. Once connected, you can seamlessly pair it with WARP, Gateway, or Access to protect your resources with Zero Trust security policies, so that each request is validated against your organization's device and identity based rules.

Users can achieve a clientless Zero Trust deployment by pairing Cloudflare Tunnel with Access. In this model, users will follow the flow laid out in the Zero Trust dashboard. First, users name their tunnel. Next, users will be provided a single installation script tailored to the origin’s operating system and system architecture. Finally, they’ll create either public hostnames or private network routes for their tunnel. As outlined earlier, this step eliminates the need for a configuration file. Public hostname values will now replace ingress rules for remotely managed tunnels. Simply add the public hostname through which you’d like to access your private resource. Then, map the hostname value to a service behind your origin server. Finally, create a Cloudflare Access policy to ensure only those users who meet your requirements are able to access this resource.

Alternatively, users can pair Cloudflare Tunnel with WARP and Gateway if they prefer a client-based approach to Zero Trust. Here, they’ll follow the same flow outlined above but instead of creating a public hostname, they’ll add a private network. This step replaces the cloudflared tunnel route ip add <IP/CIDR> step from the CLI library. Then, users can navigate to the Cloudflare Gateway section of the Zero Trust dashboard and create two rules to test private network connectivity and get started.

1. Name: Allow for <IP/CIDR>      Policy: Destination IP in <IP/CIDR> AND User Email is Action: Allow

2. Name: Default deny for <IP/CIDR>Policy: Destination IP in <IP/CIDR>Action: Block

It’s important to note, with either approach, most use cases will only require a single tunnel. A tunnel can advertise both public hostnames and private networks without conflicts. This helps make orchestration simple. In fact, we suggest starting with the least number of tunnels possible and using replicas to handle redundancy rather than additional tunnels. This, of course, is dependent on each user's environment, but generally it’s smart to start with a single tunnel and create more only when there is a need to keep networks or services logically separated.

Since we launched Cloudflare Tunnel, hundreds of thousands of tunnels have been created. That’s many tunnels that need to be migrated over to our new orchestration method. We want to make this process frictionless. That’s why we’re currently building out tooling to seamlessly migrate locally managed configurations to Cloudflare managed configurations. This will be available in a few weeks.

At launch, we also will not support global configuration options listed in our developer documentation. These parameters require case-by-case support, and we’ll be adding these commands incrementally over time. Most notably, this means the best way to adjust your cloudflared logging levels will still be by modifying the Cloudflare Tunnel service start command and appending the --loglevel flag into your service run command. This will become a priority after releasing the migration wizard.

As you can see, we have exciting plans for the future of remote tunnel management and will continue investing in this as we move forward. Check it out today and deploy your first Cloudflare Tunnel from the dashboard in three simple steps.

At the end of 2020, Cloudflare empowered organizations to start building a private network on top of our network. Using Cloudflare Tunnel on the server side, and Cloudflare WARP on the client side, the need for a legacy VPN was eliminated. Fast-forward to today, and thousands of organizations have gone on this journey with us — unplugging their legacy VPN concentrators, internal firewalls, and load balancers. They’ve eliminated the need to maintain all this legacy hardware; they’ve dramatically improved speeds for end users; and they’re able to maintain Zero Trust rules organization-wide.

We started with TCP, which is powerful because it enables an important range of use cases. However, to truly replace a VPN, you need to be able to cover UDP, too. Starting today, we’re excited to provide early access to UDP on Cloudflare’s Zero Trust platform. And even better: as a result of supporting UDP, we can offer Internal DNS — so there’s no need to migrate thousands of private hostnames by hand to override DNS rules. You can get started with Cloudflare for Teams for free today by signing up here; and if you’d like to join the waitlist to gain early access to UDP and Internal DNS, please visit here.

Building out a private network has two primary components: the infrastructure side, and the client side.

The infrastructure side of the equation is powered by Cloudflare Tunnel, which simply connects your infrastructure (whether that be a singular application, many applications, or an entire network segment) to Cloudflare. This is made possible by running a simple command-line daemon in your environment to establish multiple secure, outbound-only, load-balanced links to Cloudflare. Simply put, Tunnel is what connects your network to Cloudflare.

On the other side of this equation, we need your end users to be able to easily connect to Cloudflare and, more importantly, your network. This connection is handled by our robust device client, Cloudflare WARP. This client can be rolled out to your entire organization in just a few minutes using your in-house MDM tooling, and it establishes a secure, WireGuard-based connection from your users’ devices to the Cloudflare network.

Now that we have your infrastructure and your users connected to Cloudflare, it becomes easy to tag your applications and layer on Zero Trust security controls to verify both identity and device-centric rules for each and every request on your network.

Up until now though, only TCP was supported.

Over the past year, with more and more users adopting Cloudflare’s Zero Trust platform, we have gathered data surrounding all the use cases that are keeping VPNs plugged in. Of those, the most common need has been blanket support for UDP-based traffic. Modern protocols like QUIC take advantage of UDP’s lightweight architecture — and at Cloudflare, we believe it is part of our mission to advance these new standards to help build a better Internet.

Today, we’re excited to open an official waitlist for those who would like early access to Cloudflare for Teams with UDP support.

UDP is a vital component of the Internet. Without it, many applications would be rendered woefully inadequate for modern use. Applications which depend on near real time communication such as video streaming or VoIP services are prime examples of why we need UDP and the role it fills for the Internet. At their core, however, TCP and UDP achieve the same results — just through vastly different means. Each has their own unique benefits and drawbacks, which are always felt downstream by the applications that utilize them.

Here’s a quick example of how they both work, if you were to ask a question to somebody as a metaphor. TCP should look pretty familiar: you would typically say hi, wait for them to say hi back, ask how they are, wait for their response, and then ask them what you want.

UDP, on the other hand, is the equivalent of just walking up to someone and asking what you want without checking to make sure that they're listening. With this approach, some of your question may be missed, but that's fine as long as you get an answer.

Like the conversation above, with UDP many applications actually don’t care if some data gets lost; video streaming or game servers are good examples here. If you were to lose a packet in transit while streaming, you wouldn’t want the entire stream to be interrupted until this packet is received — you’d rather just drop the packet and move on. Another reason application developers may utilize UDP is because they’d prefer to develop their own controls around connection, transmission, and quality control rather than use TCP’s standardized ones.

For Cloudflare, end-to-end support for UDP-based traffic will unlock a number of new use cases. Here are a few we think you’ll agree are pretty exciting.

Most corporate networks require an internal DNS resolver to disseminate access to resources made available over their Intranet. Your Intranet needs an internal DNS resolver for many of the same reasons the Internet needs public DNS resolvers. In short, humans are good at many things, but remembering long strings of numbers (in this case IP addresses) is not one of them. Both public and internal DNS resolvers were designed to solve this problem (and much more) for us.

In the corporate world, it would be needlessly painful to ask internal users to navigate to, say, 192.168.0.1 to simply reach Sharepoint or OneDrive. Instead, it’s much easier to create DNS entries for each resource and let your internal resolver handle all the mapping for your users as this is something humans are actually quite good at.

Under the hood, DNS queries generally consist of a single UDP request from the client. The server can then return a single reply to the client. Since DNS requests are not very large, they can often be sent and received in a single packet. This makes support for UDP across our Zero Trust platform a key enabler to pulling the plug on your VPN.

Another common use case for UDP is thick client applications. One benefit of UDP we have discussed so far is that it is a lean protocol. It’s lean because the three-way handshake of TCP and other measures for reliability have been stripped out by design. In many cases, application developers still want these reliability controls, but are intimately familiar with their applications and know these controls could be better handled by tailoring them to their application. These thick client applications often perform critical business functions and must be supported end-to-end to migrate. As an example, legacy versions of Outlook may be implemented through thick clients where most of the operations are performed by the local machine, and only the sync interactions with Exchange servers occur over UDP.

Again, UDP support on our Zero Trust platform now means these types of applications are no reason to remain on your legacy VPN.

A huge portion of the world's Internet traffic is transported over UDP. Often, people equate time-sensitive applications with UDP, where occasionally dropping packets would be better than waiting — but there are a number of other use cases, and we’re excited to be able to provide sweeping support.

You can already get started building your private network on Cloudflare with our tutorials and guides in our developer documentation. Below is the critical path. And if you’re already a customer, and you’re interested in joining the waitlist for UDP and Internal DNS access, please skip ahead to the end of this post!

First, you need to install cloudflared on your network and authenticate it with the command below:

cloudflared tunnel login

Next, you’ll create a tunnel with a user-friendly name to identify your network or environment.

cloudflared tunnel create acme-network

Finally, you’ll want to configure your tunnel with the IP/CIDR range of your private network. By doing this, you’re making the Cloudflare WARP agent aware that any requests to this IP range need to be routed to our new tunnel.

cloudflared tunnel route ip add 192.168.0.1/32

Then, all you need to do is run your tunnel!

To connect your first user, start by downloading the Cloudflare WARP agent on the device they’ll be connecting from, then follow the steps in our installer.

Next, you’ll visit the Teams Dashboard and define who is allowed to access our network by creating an enrollment policy. This policy can be created under Settings > Devices > Device Enrollment. In the example below, you can see that we’re requiring users to be located in Canada and have an email address ending @cloudflare.com.

Once you’ve created this policy, you can enroll your first device by clicking the WARP desktop icon on your machine and navigating to preferences > Account > Login with Teams.

Last, we’ll remove the IP range we added to our Tunnel from the Exclude list in Settings > Network > Split Tunnels. This will ensure this traffic is, in fact, routed to Cloudflare and then sent to our private network Tunnel as intended.

In addition to the tutorial above, we also have in-product guides in the Teams Dashboard which go into more detail about each step and provide validation along the way.

To create your first Tunnel, navigate to the Access > Tunnels.

To enroll your first device into WARP, navigate to My Team > Devices.

We’re incredibly excited to release our waitlist today and even more excited to launch this feature in the coming weeks. We’re just getting started with private network Tunnels and plan to continue adding more support for Zero Trust access rules for each request to each internal DNS hostname after launch. We’re also working on a number of efforts to measure performance and to ensure we remain the fastest Zero Trust platform — making using us a delight for your users, compared to the pain of using a legacy VPN.

At Cloudflare, we believe that you shouldn’t have to compromise privacy for security. Last year, we launched Cloudflare Gateway — a comprehensive, Secure Web Gateway with built-in Zero Trust browsing controls for your organization. Today, we’re excited to share the latest set of privacy features available to administrators to log and audit events based on your team’s needs.

Cloudflare Gateway helps organizations replace legacy firewalls while also implementing Zero Trust controls for their users. Gateway meets you wherever your users are and allows them to connect to the Internet or even your private network running on Cloudflare. This extends your security perimeter without having to purchase or maintain any additional boxes.

Organizations also benefit from improvements to user performance beyond just removing the backhaul of traffic to an office or data center. Cloudflare’s network delivers security filters closer to the user in over 250 cities around the world. Customers start their connection by using the world’s fastest DNS resolver. Once connected, Cloudflare intelligently routes their traffic through our network with layer 4 network and layer 7 HTTP filters.

To get started, administrators deploy Cloudflare’s client (WARP) on user devices, whether those devices are macOS, Windows, iOS, Android, ChromeOS or Linux. The client then sends all outbound layer 4 traffic to Cloudflare, along with the identity of the user on the device.

With proxy and TLS decryption turned on, Cloudflare will log all traffic sent through Gateway and surface this in Cloudflare’s dashboard in the form of raw logs and aggregate analytics. However, in some instances, administrators may not want to retain logs or allow access to all members of their security team.

The reasons may vary, but the end result is the same: administrators need the ability to control how their users' data is collected and who can audit those records.

Legacy solutions typically give administrators an all-or-nothing blunt hammer. Organizations could either enable or disable all logging. Without any logging, those services did not capture any personally identifiable information (PII). By avoiding PII, administrators did not have to worry about control or access permissions, but they lost all visibility to investigate security events.

That lack of visibility adds even more complications when teams need to address tickets from their users to answer questions like “why was I blocked?”, “why did that request fail?”, or “shouldn’t that have been blocked?”. Without logs related to any of these events, your team can’t help end users diagnose these types of issues.

Starting today, your team has more options to decide the type of information Cloudflare Gateway logs and who in your organization can review it. We are releasing role-based dashboard access for the logging and analytics pages, as well as selective logging of events. With role-based access, those with access to your account will have PII information redacted from their dashboard view by default.

We’re excited to help organizations build least-privilege controls into how they manage the deployment of Cloudflare Gateway. Security team members can continue to manage policies or investigate aggregate attacks. However, some events call for further investigation. With today’s release, your team can delegate the ability to review and search using PII to specific team members.

We still know that some customers want to reduce the logs stored altogether, and we’re excited to help solve that too. Now, administrators can now select what level of logging they want Cloudflare to store on their behalf. They can control this for each component, DNS, Network, or HTTP and can even choose to only log block events.

That setting does not mean you lose all logs — just that Cloudflare never stores them. Selective logging combined with our previously released Logpush service allows users to stop storage of logs on Cloudflare and turn on a Logpush job to their destination of choice in their location of choice as well.

To get started, any Cloudflare Gateway customer can visit the Cloudflare for Teams dashboard and navigate to Settings > Network. The first option on this page will be to specify your preference for activity logging. By default, Gateway will log all events, including DNS queries, HTTP requests and Network sessions. In the network settings page, you can then refine what type of events you wish to be logged. For each component of Gateway you will find three options:

1. Capture all

2. Capture only blocked

3. Don’t capture

Additionally, you’ll find an option to redact all PII from logs by default. This will redact any information that can be used to potentially identify a user including User Name, User Email, User ID, Device ID, source IP, URL, referrer and user agent.

We’ve also included new roles within the Cloudflare dashboard, which provide better granularity when partitioning Administrator access to Access or Gateway components. These new roles will go live in January 2022 and can be modified on enterprise accounts by visiting Account Home → Members.

If you’re not yet ready to create an account, but would like to explore our Zero Trust services, check out our interactive demo where you can take a self-guided tour of the platform with narrated walkthroughs of key use cases, including setting up DNS and HTTP filtering with Cloudflare Gateway.

Moving forward, we’re excited to continue adding more and more privacy features that will give you and your team more granular control over your environment. The features announced today are available to users on any plan; your team can follow this link to get started today.

Whether the services are internal apps protected with Zero Trust policies, websites running in Kubernetes clusters in a public cloud environment, or a hobbyist project on a Raspberry Pi — Cloudflare Tunnel provides a stable, secure, and highly performant way to serve traffic.

Starting today, with our new UI in the Cloudflare for Teams Dashboard, users who deploy and manage Cloudflare Tunnel at scale now have easier visibility into their tunnels’ status, routes, uptime, connectors, cloudflared version, and much more. On the Teams Dashboard you will also find an interactive guide that walks you through setting up your first tunnel.  

We wanted to start by making the tunnel onboarding process more transparent for users. We understand that not all users are intimately familiar with the command line nor are they deploying tunnel in an environment or OS they’re most comfortable with. To alleviate that burden, we designed a comprehensive onboarding guide with pathways for MacOS, Windows, and Linux for our two primary onboarding flows:

1. Connecting an origin to Cloudflare

2. Connecting a private network via WARP to Tunnel

Our new onboarding guide walks through each command required to create, route, and run your tunnel successfully while also highlighting relevant validation commands to serve as guardrails along the way. Once completed, you’ll be able to view and manage your newly established tunnels.

When thinking about the new user interface for tunnel we wanted to concentrate our efforts on how users gain visibility into their tunnels today. It was important that we provide the same level of observability, but through the lens of a visual, interactive dashboard. Specifically, we strove to build a familiar experience like the one a user may see if they were to run cloudflared tunnel list to show all of their tunnels, or cloudflared tunnel info if they wanted to better understand the connection status of a specific tunnel.

In the interface, you can quickly search by name or filter by name, status, uptime, or creation date. This allows users to easily identify and manage the tunnels they need, when they need them. We also included other key metrics such as Status and Uptime.

A tunnel's status depends on the health of its connections:

• Active: This means your tunnel is running and has a healthy connection to the Cloudflare network.

• Inactive: This means your tunnel is not running and is not connected to Cloudflare.

• Degraded: This means one or more of your four long-lived TCP connections to Cloudflare have been disconnected, but traffic is still being served to your origin.

A tunnel’s uptime is also calculated by the health of its connections. We perform this calculation by determining the UTC timestamp of when the first (of four) long-lived TCP connections is established with the Cloudflare Edge. In the event this single connection is terminated, we will continue tracking uptime as long as one of the other three connections continues to serve traffic. If no connections are active, Uptime will reset to zero.

Last year, shortly after the announcement of Named Tunnels, we released a new feature that allowed users to utilize the same Named Tunnel to serve traffic to many different services through the use of Ingress Rules. In the new UI, if you’re running your tunnels in this manner, you’ll be able to see these various services reflected by hovering over the route's value in the dashboard. Today, this includes routes for DNS records, Load Balancers, and Private IP ranges.

Even more recently, we announced highly available and highly scalable instances of cloudflared, known more commonly as “cloudflared replicas.” To view your cloudflared replicas, select and expand a tunnel. Then you will identify how many cloudflared replicas you’re running for a given tunnel, as well as the corresponding connection status, data center, IP address, and version. And ultimately, when you’re ready to delete a tunnel, you can do so directly from the dashboard as well.

Moving forward, we’re excited to begin incorporating more Cloudflare Tunnel analytics into our dashboard. We also want to continue making Cloudflare Tunnel the easiest way to connect to Cloudflare. In order to do that, we will focus on improving our onboarding experience for new users and look forward to bringing more of that functionality into the Teams Dashboard. If you have things you’re interested in having more visibility around in the future, let us know below!

Your team likely uses more SaaS applications than you realize. The time your administrators spend vetting and approving applications sanctioned for use can suddenly be wasted when users sign up for alternative services and store data in new places. Starting today, you can use Cloudflare for Teams to detect and block unapproved SaaS applications with just two clicks.

SaaS applications save time and budget for IT departments. Instead of paying for servers to host tools — and having staff ready to monitor, upgrade, and troubleshoot those tools — organizations can sign up for a SaaS equivalent with just a credit card and never worry about hosting or maintenance again.

That same convenience causes a data control problem. Those SaaS applications sit outside any environment that you control; the same reason they are easy for your team is also a potential liability now that your sensitive data is kept by third parties. Most organizations keep this in check through careful audits of the SaaS applications being used. Depending on industry and regulatory impact, IT departments evaluate, approve, and catalog the applications they use.

However, users can intentionally or accidentally bypass those approvals. For example, if your organization relies on OneDrive but a user is more comfortable with Google Drive, that user might decide to store work files in Google Drive instead. IT has no visibility into this happening and the user might think it’s fine. That user begins sharing files with other users in your organization, who also sign up with Google Drive, and suddenly an unsanctioned application holds sensitive information. This is “Shadow IT” and these applications inherently obfuscate the controls put in place by your organization.

Cloudflare Gateway routes all Internet bound traffic to Cloudflare’s network to enforce granular controls for your users to block them from unknown security threats. Now, it also provides your team added assurance with a low-effort, high-visibility overview into the SaaS applications being used in your environment.

By simply turning on Gateway, all HTTP requests for your organization are aggregated in your Gateway Activity Log for audit and security purposes. Within the activity log, we surface pertinent information about the user, action, and request. These records include data about the application and application type. In the example above, the application type would be Collaboration and Online Meeting and the application would be Google Drive.

From there, Gateway analyzes your HTTP request in the Activity Log and surfaces your Shadow IT, by categorizing and sorting these seemingly miscellaneous applications into actionable insights without any additional lift from your team.

With Shadow IT Discovery, Cloudflare for Teams first catalogs all applications used in your organization. The feature runs in an “observation” mode first - all applications are analyzed, but default to “unreviewed.”

Your team can then review the applications found and, with just a couple clicks, designate applications approved or unapproved — either for a single application or in bulk.

This allows administrators to easily track the top approved and unapproved applications their users are accessing to better profile their security posture. When drilling down into a more detailed view, administrators can take bulk actions to move multiple newly discovered applications at once. In this view, users can also filter on application type to easily identify redundancies in their organization.

Another feature we wanted to add was the ability to quickly highlight if an application being used by your organization has already been secured by Cloudflare Access. You can find this information in the column titled Secured. If an application is not Secured by Access, you can start that process today as well with Access for SaaS. (We added two new tutorials this week!)

When you mark an application unapproved, Cloudflare for Teams does not block it outright. We know some organizations need to label an application unapproved and check in with the users before they block access to it altogether. If your team is ready, you can then apply a Gateway rule to block access to it going forward.

While we’re excited to help IT teams stop worrying about unapproved apps, we also talked to teams who feared they were overspending for certain approved applications.

We want to help here too. Today’s launch counts the number of unique users who access any one application over different time intervals. IT teams can use this data to check usage against licenses and right size as needed.

Without this feature, many administrators and our own internal IT department were losing sleep each night wondering if their users were circumventing their controls and putting them at risk of attack. Additionally, many administrators are financially impacted as they procure software licenses for their entire organization. With Shadow IT Discovery, we empower your team to anticipate popular applications and begin the assessment process earlier in the procurement lifecycle.

We’re excited to announce Shadow IT and can’t wait to see what you’ll do with it. To get started, deploy HTTP filtering for your organization with the Cloudflare for Teams client. In the future, we’ll also be adding automation to block unapproved applications in Gateway, but we can’t wait to hear what else you’d like to see out of this feature.

This post is also available in Español, Français and Deutsch.

A few months ago, we announced that we wanted to make Zero Trust security accessible to everyone, regardless of size, scale, or resources. Argo Tunnel, our secure method of connecting resources directly to Cloudflare, is the next piece of the puzzle.

Argo Tunnel creates a secure, outbound-only connection between your services and Cloudflare by deploying a lightweight connector in your environment. With this model, your team does not need to go through the hassle of poking holes in your firewall or validating that traffic originated from Cloudflare IPs.

In the past, Argo Tunnel has been priced based on bandwidth consumption as part of Argo Smart Routing, Cloudflare’s traffic acceleration feature. Starting today, we’re excited to announce that any organization can use the secure, outbound-only connection feature of the product at no cost. You can still add the paid Argo Smart Routing feature to accelerate traffic.

As part of that change (and to reduce confusion), we’re also renaming the product to Cloudflare Tunnel. To get started, sign up today.

If you’re interested in how and why we’re doing this, keep scrolling.

In 2018, Cloudflare introduced Argo Tunnel, a private, secure connection between your origin and Cloudflare. Traditionally, from the moment an Internet property is deployed, developers spend an exhaustive amount of time and energy locking it down through access control lists, rotating ip addresses, or clunky solutions like GRE tunnels.

We built Tunnel to help alleviate that burden.

With Tunnel, users can create a private link from their origin server directly to Cloudflare without a publicly routable IP address. Instead, this private connection is established by running a lightweight daemon, cloudflared, on your origin, which creates a secure, outbound-only connection. This means that only traffic that routes through Cloudflare can reach your origin.

Originally, we built Tunnel to solve a straightforward problem. It was unnecessarily difficult to connect a server to the Internet. Instead of implementing other legacy models, we wanted to create a frictionless way to establish a private connection directly to Cloudflare. This was of particular interest to us as we also wanted to solve what was a key pain point for many of our own customers, too.

Since 2010, Cloudflare has onboarded new users by having them complete two steps: 1) add their Internet property and 2) change their nameservers. The second step is important because once you change your nameservers, requests made to your resources first hit Cloudflare’s network. Cloudflare is then able to use this as an opportunity to block unwanted or malicious traffic instead of would-be attackers hitting your origin IP addresses directly. This is commonly referred to as a reverse proxy model.

But what happens if an attacker discovers that origin IP address? Couldn’t they just bypass Cloudflare altogether? That’s where Tunnel comes into play. Tunnel secures your origin by making outbound-only connections to Cloudflare. This removes legacy model requirements of poking ingress rules into your machine often leaving your infrastructure vulnerable to attack. More importantly, you can actually enhance the security controls of your origin by enforcing Zero Trust rules through Cloudflare which validate each request to your resource.

With that, suppose you are working on a local development environment for a new web application and want to securely share updates with a friend or collaborator. You would first install cloudflared to connect your origin to Cloudflare. Then, you would create your Tunnel and generate a hostname in the Cloudflare dashboard using your Tunnel UUID so that users can reach your resource and run your Tunnel. You can also add a Zero Trust policy with Cloudflare Access to your DNS record so that only friends and collaborators can view your resource.

Over the past few months, we’ve also been working to enhance stability and persistence. In order to improve stability, we removed internal dependencies which caused Tunnel to require both our Control and Data Planes to be online and available for Tunnel reconnects.

By removing these upstream dependencies, Tunnels are able to gracefully reinitiate connections without requiring that both services be available simultaneously. We also migrated to Cloudflare’s edge load balancer, Unimog, which increased the average life of a given Tunnel from minutes to days. When these connections support longer uptimes and have less reliance on internal dependencies, they become well positioned for greater stability around the globe.

We also wanted to focus efforts on persistence. Previously, if cloudflared needed to restart for any reason, we treated each restart as a new Tunnel. This meant creating a new DNS record as well as establishing a connection to Cloudflare.

In our latest feature release, we introduced the concept of Named Tunnels. With Named Tunnels, users can assign a Tunnel with a permanent name which then creates a direct relationship with your Tunnel UUID. This model allows these two identifiers to become persistent records which can enable autonomous reconnection. Now in the event your Named Tunnel does need to restart, your cloudflared instance can reference this UUID address to reconnect rather than starting each restart from the ground up.

At Cloudflare, our mission is to help build a better Internet, and we’re excited to take another step towards that mission by opening up Tunnel for everyone. We can’t wait to see how you’ll take advantage of the enhanced stability, persistence, and Zero Trust security that come with Tunnel.

With Tunnel, we’ve seen the possibilities are as creative as you are. So, instead of telling you how to use Tunnel, here are a couple easy ways to get started:

• Connect an application or server: Connect an origin to Cloudflare via a public hostname

• Build a private network: Enable remote access to private network applications

Today, we’re announcing a new feature within the Teams Dash. We called it “Home”. We created Home with a simple goal in mind: design an adaptive and informative landing page where users can see a round-up of their environment.

In this last post of our series, we’ll show, rather than tell, how we collaborated as a team that rows in the same direction and towards the same goal — to create a great user experience.

In this blog post, we’ll walk you through your new Teams Home by calling out a few of the guiding principles we had in mind as we designed it. Transparency, adaptiveness, guidance and warmth aren’t only foundational words in the Cloudflare for Teams product principles — they’re part of our day-to-day brainstorming and discussion around user experience.

Here’s how the Teams Home reflects these principles.

What you’ll find in the new Teams Home is a single space to view your network and applications traffic. We wanted to build an experience that allows users to get a comprehensive view of all things protected by Teams — a single pane of glass that’s always available, and that users can quickly pull up to spot any anomalies in their network traffic. Or simply to keep it under control.

We’ve also made it simpler for you to keep an eye on user count, and added a direct link to our plans page should you need to make any changes to the subscription you’ve chosen.

The Teams Home brings all users signals into one view, threading together concepts that were once sparse across the Dash.

We called it “Home,” because we wanted it to feel like a space you visit each day that brings you clarity and peace of mind. Too often, security products can feel clinical and stark, and we wanted to avoid that. Through the use of color theory and language analysis, we actively worked to convey a feeling of approachability, while still keeping the Dash functional and straightforward.

When writing for UX, we need to be considerate of a user’s emotions as they follow a given flow in our product. Some users may appreciate certain elements as they explore the dash on a not-so-busy day; other users may not if their environment is at-risk and they simply need to identify what’s wrong, fast.

With this in mind, we’ve sprinkled bits of conversational, friendly copy where appropriate. For example, the biggest textual element in the Home page is a greeting — consistent with the header in our Quick Start page (“Welcome aboard!”), the tone is designed to be cheerful and welcoming.

Another subtle example of this is our loading screen. Nobody likes to wait, so we wanted to build this interaction for our users as well. With an animation that brings in elements representative of Cloudflare’s network, and alternating lines of copy that refer to the semantics of building and cleaning a physical home, we wanted to add a quirky touch where it doesn’t interfere with what really matters.

The Teams family has grown and expanded since its inception, and we wanted to highlight complementary features that are a key part of our user journeys. In the footer, you’ll find easy access to things like Cloudflare Radar, the Teams Help page, and a quick-start guide packed with simple starter packs. These additional features help craft a holistic picture of the Teams story.

In our product principles, we give great importance to ease of use. And we, as a team, have an ambitious goal in mind — make Zero Trust security principles approachable for everyone.

To us, a product is easy to use when it guides users to success through clear paths in the interface. This is why we’ve pre-established some of these paths — we want to help our users take their first steps within Teams. With just a few clicks from the Home and Quick Start pages, users who signed up primarily for Secure Web Gateway functionalities can add Zero Trust rules in front of their applications, and vice-versa.

We’ve also incorporated an entirely new approach to some of our empty states. Instead of just telling our users there’s no data to show, we help them take actions to start populating those empty charts.

As threats on the Internet evolve, so will the needs of our users. Throughout this process, we thought critically about how the Teams Home could be flexible in nature, and scale was a key priority. We’ll continue to ship new features — and when we do, those features will have a place in the Teams Home, in large part due to the modular approach we adopted. Moving forward, we will continue to add more data signals into the Teams Home and aim to put more control into your hands to customize your unique Home experience. We’re also integrating easier ways for you to give us feedback on the overall experience and are excited to learn more from our users.

The Teams Home is available today for all users on the Teams Dash. If you don’t have a Cloudflare for Teams account yet, click here to get started.

You’ll know you’re Home when you see the Welcome Page.

Back in 2010, Cloudflare was introduced at TechCrunch Disrupt as a security and performance solution that took the tools of the biggest service providers and made them available to anyone online. But simply replicating these tools wasn’t enough — we needed to make them ridiculously easy to use.

When we launched Cloudflare for Teams almost ten years later, the vision was very much the same — build a secure and powerful Zero Trust solution that is ridiculously easy to use. However, while we talk about what we’re building with a regular cadence, we often gloss over how we are designing Cloudflare for Teams to make it simple and easy to use.

In this blog post we’ll do just that — if that sounds like your jam, keep scrolling.

First, let's back up a bit and introduce Cloudflare for Teams.

We launched Cloudflare for Teams in January, 2020. With Teams, we wanted to alleviate the burden Cloudflare customers were feeling when trying to protect themselves and their infrastructure from threats online. We knew that continuing to rely on expensive hardware would be difficult to maintain and impractical to scale.

At its core, Teams joins two products together — Access and Gateway. On the one hand, Access acts as a bouncer at the door of all your applications, checking the identity of everyone who wants in. It's a Zero Trust solution that secures inbound connections. On the other hand, Gateway is a Secure Web Gateway solution that acts as your organization's bodyguard — it secures your users as they set out to navigate the Internet.

Over the past year, we’ve been rapidly shipping features to help our customers face the new and daunting challenges 2020 brought around. However, that velocity often took a toll on the intentionality of how we design the Teams Dashboard, and resulted in a myriad of unintended consequences. This is often referred to as a “Feature Shop” dilemma, where Product and Design only think about what they’re building and become too resource-constrained to consider why they’re building it.

In an interface, this pattern often manifests itself through siloed functionality and fractured experiences. And admittedly, when we first began building the Teams Dashboard, many of our experiences felt this way. Users were able to take singular features from inception to fruition, but were limited in their ability to thread these experiences together in a seamless fashion across the Dashboard.

Here’s an example. In the early days of Cloudflare for Teams, we wanted to provide users with a single pane of glass to manage their security policies. In order to do so, users would need to onboard to both Access and Gateway. Only one problem, we didn’t have an onboarding pathway for Cloudflare Access. The obvious question became “What do we need?”. Inherently, the answer was an onboarding flow for Cloudflare Access.

Just like that, we were off to the races.

In retrospect, what we should have been asking instead was “Why do users need onboarding flow?” By focusing on what, we polluted our own ability to build the right solution for this problem. Instead of providing a seamless entryway to our dashboard, we created a fork-in-the-road decision point and siloed our customers into two separate paths that did not make it easy for them to approach our dashboard.

From an experiential perspective, we later equated this to inviting our users to a party. We give them an address, but when they show up at the doorstep, they realize the house is actually a duplex. Which doorbell are they supposed to ring? Where's the party? What will they find if they walk into the wrong unit?

That’s where Design fits in. Our design team is hyper-obsessed with asking why. Why are we throwing a party? Why should anyone come? Why should they stay? By challenging our team to lead with design, we take a questioning attitude to each of the features we contemplate building. With this approach, we do not assume a feature is valuable, intuitive, or even required. We assume nothing.

During our “Feature Shop” days, we had a bad habit of providing “bad mockups” or outlining a solution for Design to prototype. This is often referred to as “solution pollution”. For example, if I tell you I need a fast car, you’re probably going to start designing a car. However, if instead I tell you I need to get from point A to point B as quick as possible, you may end up designing a bike, scooter, car, or something entirely new and novel. Design thrives in this balance.

Now, we begin at the beginning and gather contextual data which drove us toward a given feature hypothesis. Together, Product and Design then research the problem alongside the users it may impact. More importantly, once the problem space has been validated, we partner on the solution itself.

With this new approach in mind, we revisited our onboarding experience, and this time, the solution we arrived at was quite different from our initial prototypes. Instead of creating two divergent pathways we now proposed a single Cloudflare for Teams onboarding flow. This solved the duplex problem.

This flow prioritized two key elements; preparing users for success and emphasizing time-to-value. During initial research, Design was able to identify that users often felt overwhelmed and underprepared for the configuration required during an early onboarding. Additionally, due to this sentiment, users failed to reach an initial “Aha!” moment until much later than anticipated in their user journey. To address these concerns, we truncated the onboarding process to just three simple steps:

• Welcome to Teams

• Create a Team Name

• Pick a Plan

As simple as that. Then, we created a Quick Start guide which users land on after onboarding. Let’s call this our inboarding flow. Next, we created a variety of “Starter Packs” within the guide which automate much the laborious configuration for users so they can start realizing value from Cloudflare for Teams almost instantly:

Moving forward, we will continue to expand on the Quick Start guide adding more robust starter packs and enhancing the opportunities for continuous learning. We’re also looking to incorporate intelligent recommendations based on your environment. We’ll also be releasing other improvements this quarter which apply the same underlying concepts found in our Quick Start guide to other areas of the UI such as our Empty States and Overview pages.

Perhaps most importantly, by leading with Design we’re able to foster healthy debate early and often for the products and features we consider releasing within the UI. These relationships drive us to map risks to controls and force us to build with care and intentionality. After all, we all have the same mission: to help build a better Internet.

If you’re interested in learning more about the Cloudflare for Teams design lifecycle, stay tuned. We have three upcoming blog releases which will walk you through our product content strategy, our design vision, and an exciting new feature release where you can see this partnership in action.

If you’re interested in how and why we’re doing this, keep scrolling.

Cloudflare Access is one-half of Cloudflare for Teams - a Zero Trust solution that secures inbound connections to your protected applications. Cloudflare Access works like a bouncer, checking identity at the door to all of your applications.

The other half of Cloudflare for Teams is Cloudflare Gateway which, as our clever name implies, is a Secure Web Gateway protecting all of your users’ outbound connections to the Internet. To continue with this analogy, Cloudflare Gateway is your organization’s bodyguard, securing your users as they navigate the Internet.

Together, these two solutions provide a powerful, single dashboard to protect your users, networks, and applications from malicious actors.

At Cloudflare, our mission is to help build a better Internet. That means a better Internet for everyone, regardless of size, scale, or resources. With Cloudflare for Teams, our part in this mission is to keep your team members secure from unknown threats and your applications safe from attack, so that your team can focus on your business.

Earlier this year, shortly after we launched Cloudflare for Teams, organizations suddenly had to change the way they worked. Users left offices, and the security provided by those offices, to work from home. This accelerated the pace of IT transformation from years to days, or even hours.

To alleviate that burden, we provided Cloudflare for Teams for everyone at no cost, and with no restrictions until September 1, 2020. We also offered free one-on-one onboarding to make adoption seamless, and used those sessions to improve the product for our current users as well.

Moving forward, users will continue to work from home, and applications will continue to move away from managed data centers. While our initial free program is no longer available, our team wanted to find a new way to continue helping organizations of any size adjust to this new security model that seems to be here to stay.

Today, we are launching the Cloudflare for Teams Free plan, which brings the features of enterprise Zero Trust products and Secure Web Gateways to small teams as well.

Cloudflare for Teams Free offers robust Zero Trust security features for both internal and SaaS applications, and supports integration with a myriad of social and enterprise identity providers like AzureAD or Github. Our Free plan also includes DNS content and security filtering for multiple network locations, complete with 24 hour log retention. By offering Cloudflare for Teams Free, our goal is to empower you to take your first step on a journey to Zero Trust with us.

With up to 50 seats of Access and Gateway, we’ve seen that the possibilities are endless. In fact, here are some of our favorite ways users are already getting the most out of Cloudflare for Teams Free today.

• Collaborate on your startup. Build your product without worrying about security. Use Access to protect your development environment.

• Secure your home Wi-Fi network. Point your home Wi-Fi router’s traffic to Gateway, and set up simple filtering rules to block malware and phishing attacks.

• Protect the backend of your personal website. Lock down your WordPress admin panel pages, and invite collaborators to work on your blog by using Access’ one-time-pin feature.

• Safeguard a guest Wi-Fi network. Shield a retail location with Gateway by enforcing your Acceptable Use Policy on your network.

In addition to our new Cloudflare for Teams Free plan, we’re also making it easier to continue your Zero Trust journey by offering enhanced features in our standalone Cloudflare Access or Cloudflare Gateway plans.

With standalone Access, you can easily scale up or down with as many users as you need at any time for $3 per user.

Similarly, with Gateway standalone, you can safely and securely deploy DNS or HTTP security controls from 1 up to 20 different locations for $5 per user without compromising on reliability or performance.

Last but not least, we’re excited to finally give users a way to bundle with Teams Standard, which brings together everything from Access and Gateway under one simple plan at $7 per user.

To get started, just navigate to our sign-up page and create an account. If you already have an active account, you can head straight to the Cloudflare for Teams dashboard, where you’ll be dropped directly into our self-guided onboarding flow. From here, you're just three steps away from deploying Access or Gateway but, in our opinion, you can’t go wrong kicking off with either.