Skip to content
Cloudflare Docs

WARP architecture

This guide explains how the Cloudflare WARP client interacts with a device’s operating system to route traffic in Gateway with WARP mode.

In Gateway with DoH mode, the IP traffic information does not apply. In Secure Web Gateway without DNS filtering mode, the DNS traffic information does not apply.

Overview

The WARP client allows organizations to have granular control over the applications an end user device can access. The client forwards DNS and network traffic from the device to Cloudflare’s global network, where Zero Trust policies are applied in the cloud. On all operating systems, the WARP daemon maintains three connections between the device and Cloudflare:

ConnectionProtocolPurpose
Device orchestrationHTTPSPerform user registration, check device posture, apply WARP profile settings.
DoH ↗HTTPSSend DNS requests to Gateway for DNS policy enforcement.
WARP tunnel (via WireGuard or MASQUE)UDPSend IP packets to Gateway for network policy enforcement, HTTP policy enforcement, and private network access.
flowchart LR
subgraph Device
W[WARP client] -.-> D
D[DNS proxy]
W -.-> V[Virtual interface]
end
subgraph Cloudflare
A[Zero Trust account]
subgraph Gateway
G[DNS resolver]
N[L3/L4 firewall]
end
end
W<--Device orchestration-->A
D<--DoH-->G
V<--WARP tunnel-->N
N --> O[(Application)]

Your Split Tunnel configuration determines what traffic is sent down the WARP tunnel. Your Local Domain Fallback configuration determines which DNS requests are sent to Gateway via DoH. Traffic to the DoH endpoint and device orchestration API endpoint do not obey Split Tunnel rules, since those connections always operate outside of the WARP tunnel.

Next, you will learn how WARP configures your operating system to apply your Local Domain Fallback and Split Tunnel routing rules. Implementation details differ between desktop and mobile clients.

Windows, macOS, and Linux

The desktop client consists of two components: a service/daemon that handles all WARP functionality on your device, and a GUI wrapper that makes it easier for a user to interact with the daemon.

DNS traffic

When you turn on WARP, WARP creates a local DNS proxy on the device and binds it to these IP addresses on port 53 (the port designated for DNS traffic):

  • IPv4: 127.0.2.2 and 127.0.2.3
  • IPv6:
    • macOS and Linux: fd01:db8:1111::2 and fd01:db8:1111::3
    • Windows: ::ffff:127.0.2.2

WARP then configures the operating system to send all DNS requests to these IP addresses. All network interfaces on the device will now use this local DNS proxy for DNS resolution. In other words, all DNS traffic will now be handled by the WARP client.

Based on your Local Domain Fallback configuration, WARP will either forward the request to Gateway for DNS policy enforcement or forward the request to your private DNS resolver.

  • Requests to Gateway are sent over our DoH connection (outside of the WARP tunnel).
  • Requests to your private DNS resolver are sent either inside or outside of the tunnel depending on your Split Tunnel configuration. For more information, refer to How the WARP client handles DNS requests.
flowchart LR
D{{DNS request}}-->L["Local DNS proxy <br> (127.0.2.2 and 127.0.2.3)"]-->R{In local domain fallback?}
R -- Yes --> F[Private DNS resolver]
R -- No --> G[Cloudflare Gateway]

You can verify that the operating system is using WARP’s local DNS proxy:

On macOS, open a terminal window and run scutil --dns. The DNS servers should be set to WARP’s local DNS proxy IPs.

Terminal window
scutil --dns
DNS configuration (for scoped queries)
resolver #1
  search domain[0] : <DNS-SEARCH-DOMAIN>
  nameserver[0] : 127.0.2.2
  nameserver[1] : 127.0.2.3
  if_index : 15 (en0)
  flags    : Scoped, Request A records
  reach    : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
resolver #2
  nameserver[0] : 127.0.2.2
  nameserver[1] : 127.0.2.3
  nameserver[2] : fd01:db8:1111::2
  nameserver[3] : fd01:db8:1111::3
  if_index : 23 (utun3)
  flags    : Scoped, Request A records, Request AAAA records
  reach    : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

IP traffic

When you turn on WARP, WARP makes three changes on the device to control if traffic is sent inside or outside of the WARP tunnel:

flowchart LR
P{{IP packet}}-->R["OS routing table"]-->F["OS firewall"] --> S{Excluded from Split Tunnels?}
S -- Yes --> A[(Application)]
S -- No --> U["Virtual interface<br> (172.16.0.2)"] --> G[Cloudflare Gateway]

Virtual interface

Virtual interfaces allow the operating system to logically subdivide a physical interface, such as a network interface controller (NIC), into separate interfaces for the purposes of routing IP traffic. WARP’s virtual interface is what maintains the WireGuard/MASQUE connection between the device and Cloudflare. By default, its IP address is hardcoded as 172.16.0.2. You can use Override local interface IP to assign unique IPs per device.

To view a list of all network interfaces on the operating system:

On macOS, run ifconfig. When WARP is turned on, you will see a utun interface with IP address 172.16.0.2.

Terminal window
ifconfig
<redacted>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
  inet 172.16.0.2 --> 172.16.0.2 netmask 0xffffffff
  inet6 fe80::f6d4:88ff:fe82:6d9e%utun3 prefixlen 64 scopeid 0x17
  inet6 2606:4700:110:8c7d:7369:7526:a59b:5636 prefixlen 128
  nd6 options=201<PERFORMNUD,DAD>

Routing table

WARP edits the system routing table to control what IP traffic goes to Gateway. The routing table indicates which network interface should handle packets to a particular IP address. By default, all traffic routes through WARP’s virtual interface except for the IPs and domains on your Split Tunnel exclude list (which use the default interface on your device).

You can verify that the routing table matches your Split Tunnel rules:

To view the entire routing table on macOS, run netstat -r.

You can also search the routing table for a domain or IP address. In this example, we see that traffic to google.com is sent through utun3, which is the WARP virtual interface on this device:

Terminal window
route get google.com
   route to: lga25s81-in-f14.1e100.net
destination: 136.0.0.0
       mask: 248.0.0.0
  interface: utun3
      flags: <UP,DONE,PRCLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1280         0

In contrast, this DHCP address is excluded from WARP and uses the default interface:

Terminal window
route get 169.254.0.0
   route to: 169.254.0.0
destination: 169.254.0.0
       mask: 255.255.0.0
  interface: en0
      flags: <UP,DONE,CLONING,STATIC>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500   -210842

System firewall

WARP modifies the operating system firewall to enforce your Split Tunnel rules. This adds a layer of protection in case a service bypasses the routing table and tries to send traffic directly through another interface. For example, if traffic to 203.0.113.0 is supposed to be inspected by Gateway, we create a firewall rule that blocks 203.0.113.0 on all interfaces except for utun.

iOS, Android, and ChromeOS

On iOS and Android/ChromeOS, the Cloudflare One Agent installs itself as a VPN client to capture and route all traffic. The app is built on the official VPN framework for iOS and Android. For more information, refer to Apple’s NetworkExtension documentation ↗ and Google’s Android developer documentation ↗.

Note that ChromeOS runs the Android app in a virtual machine, rather than running a native Chrome app.

Cloudflare DashboardDiscordCommunityLearning CenterSupport Portal
Cookie Settings