The case against the hardware firewall

Hardware firewall appliances have been a staple of corporate security for decades, but the architectural assumptions they were built on no longer match how networks are designed. Cloudflare’s answer is to collapse the entire stack — packet filtering, stateful inspection, application awareness, and identity-based controls — into a single cloud-native firewall that runs across its global network. The company is also launching the Oahu program to help organizations retire legacy appliances as part of this transition.

The generations of firewall technology map directly to the evolution of network architecture. Early firewalls were stateless packet filters that inspected IPs and ports at layers 3 and 4, which was adequate when networks were confined to a single LAN. As organizations connected to the Internet, stateful inspection and deep packet inspection were added to track connection state and block unsolicited inbound traffic. That extra security required substantially more compute and memory, forcing IT teams into capacity planning and cost-versus-redundancy tradeoffs for each appliance. Even then, visibility was shallow: administrators could see that a user reached a given IP on port 80, but determining what content was actually accessed, or which user was responsible, required painstaking correlation of DHCP leases and device records.

Next Generation Firewalls (NGFWs) added application awareness to address that gap, with vendor-provided intelligence that could identify individual applications from traffic patterns and feed those labels into policy rules. Virtualized versions followed as applications moved to the cloud, easing the lead-time burden of hardware procurement. Vendors kept bundling more features — VPN gateways, IDS/IPS, WAF, bot management, DDoS protection — but the fundamental problems persisted: redundant appliance design, backhauling traffic to locations that had firewalls, and careful IP management to approximate identity.

Zero Trust principles eventually made their way into firewall policy engines, with integration with identity providers so that rules could reference user groups rather than IP addresses. That was a meaningful step, but it still left organizations managing appliances and orchestrating policy across distributed sites. And the controls fell short for contractors, partner organizations with their own IdPs, and the sprawl created by hybrid work.

One network, many on-ramps

Cloudflare One replaces the distributed set of hardware devices with a single logical firewall that all traffic flows through or to. On-ramps are flexible: GRE or IPsec tunnels at the network layer, application-layer tunnels, direct network interconnect, BYOIP, or the device client. Once traffic is on Cloudflare’s network, the operational concerns that dominated hardware firewall management disappear:

  • Capacity planning is moot — firewall capacity is the capacity of Cloudflare’s global network, which exceeds 100 Tbps and is growing.
  • Location planning is unnecessary — Anycast routing sends traffic to the closest point of presence, with built-in redundancy and failover rather than primary/backup appliance pairs.
  • Maintenance windows are eliminated — firewall capabilities are deployed continuously across the edge, like all Cloudflare products.
  • DDoS protection is inherent — attacks are blocked close to the source, with only clean traffic forwarded to its destination.

Policy at every layer

Policy construction spans the traditional spectrum plus Zero Trust attributes. At layers 3 through 5, rules can be both stateless and stateful, matching on IP, port, protocol, and packet metadata. The same attributes, paired with identity data and the device client, can define the private network itself. Cloudflare provides managed lists to reduce the burden of maintaining IP allow and block lists, and offers deep packet inspection as well as programmable packet filters for positive security models against large-scale attacks.

Layer 7 controls use Cloudflare’s threat intelligence for application and content categories. The protected DNS resolver, built on the consumer 1.1.1.1 service, blocks resolution of known or suspected risky domains. After resolution, administrators can apply HTTP policies to intercept and filter traffic. Self-hosted or SaaS applications can be fronted by an access policy that acts as a web-based identity proxy. To prevent data exfiltration, remote browser isolation can lock down access to external HTTP applications, and support is on the way for logging and filtering individual commands over SSH sessions.

Propagate once, enforce everywhere

The operational model for hardware firewalls involved deploying policies device by device or standing up an orchestration layer to manage the fleet. Cloudflare manages policy centrally from a dashboard, API, or Terraform, and changes propagate edge-wide in seconds via the Quicksilver configuration distribution system. Traffic visibility is available through logs, which now include configurable controls for selectively logging sensitive data.

The net effect is a firewall that scales with the network it protects, applies identity and application context at every layer, and requires no hardware lifecycle planning. That is the argument for moving security out of the data center and onto the network edge itself.

Zero Trust firewalling without the hardware

Firewalls are expected to cover a broad set of traffic flows: blocking malicious inbound traffic, filtering outbound connections so users and applications only reach safe destinations, and inspecting internal East/West flows to enforce Zero Trust. Hardware appliances have traditionally been the tool for these jobs, with different boxes often covering different use cases in different locations. Cloudflare One aims to consolidate those functions into a single platform with one source of truth for firewall policy.

Branch office protection without dedicated appliances

In a traditional setup, each office location needs at least one hardware firewall — often two for redundancy. That means forecasting traffic volume per branch, then ordering, installing and maintaining the appliances. With Cloudflare One, branch traffic can be filtered from the cloud using whatever router is already on site, as long as it supports GRE or IPsec.

Three steps are needed to get a branch office protected:

  1. Establish a GRE or IPsec tunnel. Cloudflare provides an Anycast IP address as the tunnel endpoint; standard GRE or IPsec configuration works with no extra steps, and the Anycast IP gives automatic connectivity to every Cloudflare data center.
  2. Configure network-layer firewall rules. All IP traffic flows through Magic Firewall, which supports rules based on source or destination IP, port, protocol, country, or bit field match. Magic Firewall integrates with IP Lists and supports programmable packet filtering.
  3. Upgrade traffic for application-layer filtering. After passing through Magic Firewall, TCP and UDP traffic can be upgraded for deeper inspection via Cloudflare Gateway. That unlocks application and content awareness, identity enforcement, SSH/HTTP proxying, and DLP.
Before: deploying hardware firewalls at every branch; managing different models and sometimes different vendors. After: traffic connected to global Anycast network; firewall policies deployed in one place propagate globally

Scaling past the data center bottleneck

Firewalls protecting a high-traffic headquarters or data center are often among the largest capital expenditures in an IT budget. Traditional setups require beefy appliances with specialized components to handle high throughput gracefully, at increased cost.

Cloudflare's architecture distributes packet processing across every server in its network, so no single device creates a bottleneck or requires premium hardware. Traffic can be on-ramped with BYOIP, a standard tunnel mechanism, or Cloudflare Network Interconnect. Firewall rules can then process traffic at terabit-per-second scale over the distributed network.

Before: traffic through the data center needed to flow through expensive appliance(s) that could keep up with volume. After: traffic balanced across thousands of commodity servers; malicious traffic blocked close to its source

Roaming users and the Zero Trust shift

Legacy architectures route remote users back to a central location where firewalls sit. Users establish a VPN connection to headquarters, and their traffic is processed there before reaching its destination. Even when VPN concentrators provide user-level controls, this model adds latency and does not fundamentally deliver Zero Trust.

Cloudflare's model uses a device client as the on-ramp to Zero Trust policies, letting users connect to corporate resources without hair-pinning through a central firewall site.

Before: user traffic backhauled to firewall device over VPN; after: policy enforced at the edge location closest to the user.

Roadmap and availability

Cloudflare has identified several areas customers want expanded next: broader NAT Gateway functionality, richer analytics and reporting with user experience monitoring across all firewall capabilities, and a full suite of DLP features applied to all traffic flowing through Cloudflare's network.

The new firewall capabilities are available for enterprise customers today. Documentation for Magic Firewall and the Oahu Program — which covers migrating from hardware firewalls to Zero Trust — are available now; customers can also contact their account team for onboarding.