Skip to content
Cloudflare Docs

Cloudflare Gateway

Cloudflare Gateway, our comprehensive Secure Web Gateway, allows you to set up policies to inspect DNS, network, HTTP, and egress traffic.

You can apply network and HTTP Gateway policies alongside Magic Firewall policies (for L3/4 traffic filtering) to Internet-bound traffic or private traffic entering the Cloudflare network through Magic WAN. Additionally, you can configure Gateway to resolve DNS queries from Magic WAN.

HTTPS filtering

To inspect HTTPS traffic, you need to install a Cloudflare root certificate on each client device. A certificate is required for Cloudflare to decrypt TLS.

Installing certificates

You can use the WARP client to automatically install a Cloudflare certificate on supported devices. If your device or application does not support certificate installation through WARP, you can manually install a certificate.

Exempting traffic from inspection

If you cannot or do not want to install the certificate, you can create Do Not Inspect policies to exempt incompatible Magic WAN traffic from inspection or to disable TLS decryption entirely.

Because Gateway cannot discern Magic WAN traffic, you must use WARP client checks or the IP addresses associated with Magic WAN to match traffic with Gateway policies.

For example, if your organization onboards devices to Magic WAN using WARP, you can exempt devices not running WARP using OS version checks:

SelectorOperatorValueLogicAction
Passed Device Posture Checksnot inWindows (OS version)OrDo Not Inspect
Passed Device Posture Checksnot inmacOS (OS version)OrDo Not Inspect
Passed Device Posture Checksnot inLinux (OS version)OrDo Not Inspect
Passed Device Posture Checksnot iniOS (OS version)OrDo Not Inspect
Passed Device Posture Checksnot inAndroid (OS version)Do Not Inspect

If your organization onboards users to Magic WAN using an on-ramp other than WARP, you can exempt devices from inspection using the IP addresses for your Magic IPsec tunnels:

SelectorOperatorValueAction
Source IPin203.0.113.0/24Do Not Inspect

DNS filtering

You can configure the DNS resolver for your Magic WAN networks to the shared IP addresses for the Gateway DNS resolver. The Gateway DNS resolver IPs are 172.64.36.1 and 172.64.36.2.

When you resolve DNS queries from Magic WAN through Gateway, Gateway will log the queries with the private source IP. You can use the private source IP to create resolver policies for queries intended for internal DNS records.

The following diagram illustrates how DNS queries from Magic WAN and WARP Connector flow through Gateway to your internal DNS:

flowchart LR
subgraph subGraph0["Data center"]
  direction TB
      InternalDNS(["Internal DNS"])
      ResolverPolicies["Resolver policies"]
      CloudflareGatewayDNSResolver["Gateway DNS resolver"]
end
  ResolverPolicies -- Retain and use</br>Source Internal IP --> InternalDNS
  CloudflareGatewayDNSResolver -- <br> --> ResolverPolicies
  WarpConnector["WARP Connector"] -- DHCP/DNS resolver --> IPSecTunnel["IPsec tunnel"]
  MagicWAN[$Magic WAN] -- DHCP/DNS resolver --> IPSecTunnel
  IPSecTunnel -- Shared IP endpoints --> CloudflareGatewayDNSResolver
  ResolverPolicies@{ shape: proc}
  WarpConnector@{ shape: in-out}
  MagicWAN@{ shape: in-out}

Outbound Internet traffic

By default, the following traffic routed through Magic WAN tunnels and destined to public IP addresses is proxied/filtered through Cloudflare Gateway:

  • TCP, UDP, and ICMP traffic sourced from RFC 1918 ↗ IPs or WARP devices.
  • TCP and UDP traffic sourced from BYOIP or Leased IPs and destined to a well-known port (0-1023).

By default, traffic destined to public IPs will be routed over the public Internet. If you want to configure specific public IP ranges to be routed through your Magic WAN tunnels instead of over the public Internet after filtering, contact your account team.

This traffic will egress from Cloudflare according to the egress policies you define in Cloudflare Gateway. By default, it will egress from a shared Cloudflare public IP range.

Private traffic

By default, TCP, UDP, and ICMP traffic routed through Magic WAN tunnels and destined to routes behind Cloudflare Tunnel will be proxied/filtered through Cloudflare Gateway.

Contact your account team to enable Gateway filtering for traffic destined to routes behind Magic WAN tunnels.

Default filtering criteria

When enabled, TCP/UDP traffic meeting all the following criteria will be proxied and filtered by Cloudflare Gateway:

  • Source and destination IPs: Both must be part of RFC1918 ↗ space, WARP, BYOIP, or Leased IPs.
  • Source port: Must be a client port strictly higher than 1023.
  • Destination port: Must be a well-known port (lower than 1024).

Custom filtering criteria

You can specify more specific matches to override the default criteria:

  • Source IP prefix: A subset of RFC1918 space, BYOIP, or Leased IPs.
  • Destination IP prefix: A subset of RFC1918 space, BYOIP, or Leased IPs.
  • Destination port: Any port from 0 to 65535.

Test Gateway integration

To check if Gateway is working properly with your Magic WAN connection, open a browser from a host behind your customer premise equipment, and browse to https://ifconfig.me.

If you are still testing Gateway and Cloudflare is not your default route, configure a policy-based route on your router to send traffic to Cloudflare Gateway first.

Confirm there is an entry for the test in HTTP Gateway Activity Logs.

Verify the following details:

  • Destination IP: Should be the public IP address of ifconfig.me.
  • Source IP: Should be the private (WAN) address of the host with the browser.
  • Outbound connection: Should be sourced from a Magic WAN IP address, not any public IP address that Cloudflare might be advertising on your behalf.

This applies when using Magic Transit With Egress Option as well.

Additionally, test both http://ifconfig.me (non-TLS) and https://ifconfig.me (TLS) to ensure that your TCP maximum segment size (MSS Clamping) has been set properly.

If the HTTPS query hangs or fails but HTTP works, the MSS value may be too high or not set. Reduce this value on your customer premise equipment to match the overhead introduced by your IKE and ESP ↗ settings.