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 via Magic WAN.

HTTPS filtering

In order to inspect HTTPS traffic, you need to install the Cloudflare root certificate on each client device. You can use the WARP client to automatically install the Cloudflare certificate on supported devices. If your device or application does not support certificate installation via WARP, you can manually install the certificate. The certificate is required for Cloudflare to decrypt TLS.

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 via WARP, you can exempt devices not running WARP using OS version checks:

Selector	Operator	Value	Logic	Action
Passed Device Posture Checks	not in	Windows (OS version)	Or	Do Not Inspect
Passed Device Posture Checks	not in	macOS (OS version)	Or	Do Not Inspect
Passed Device Posture Checks	not in	Linux (OS version)	Or	Do Not Inspect
Passed Device Posture Checks	not in	iOS (OS version)	Or	Do Not Inspect
Passed Device Posture Checks	not in	Android (OS version)		Do Not Inspect

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

Selector	Operator	Value	Action
Source IP	in	203.0.113.0/24	Do Not Inspect

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 BYO or Leased IPs and destined to a well-known port (0-1023).

Traffic destined to public IPs will be routed over the public Internet, unless explicitly specified otherwise. 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. If enabled, by default, TCP and UDP traffic sourced from and destined to RFC1918 ↗ space, WARP, or BYO or Leased IPs with source port higher than 1023 and destination port lower than 1024 will be proxied/filtered by Cloudflare Gateway.

Optionally, more specific matches may be specified to override the default:

• Source IP prefix in a subset of RFC1918 space, or BYO or Leased IPs
• Destination IP prefix in a subset of RFC1918 space, or BYO or Leased IPs
• Destination port number anywhere from 0-65535

Source ports are hard-coded to 1024-65535 and may not be overridden.

​​Run traceroute

Magic WAN clients connecting through GRE, IPsec, CNI or WARP that want to perform a traceroute to an endpoint behind a Cloudflare Tunnel will need to change some settings to make the command useful. Refer to Run traceroute for more information.

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 in the process of testing Gateway, and Cloudflare is not your default route, configure a policy-based route on your router to send traffic to Cloudflare Gateway first, before browsing to https://ifconfig.me.

Confirm there is an entry for the test in HTTP Gateway Activity Logs. The destination IP address should be the public IP address of ifconfig.me, and the source IP address should be the private (WAN) address of the host with the browser. Your outbound connection should be sourced from a Magic WAN IP address, and not any public IP address that Cloudflare might be advertising on your behalf. This is true as well when using Magic Transit With Egress Option.

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 response to the HTTPS query hangs or fails, but HTTP works, it is possible that the MSS value is too high or not set. Reduce this value on your customer premise equipment to match the overhead introduced by your IKE and ESP ↗ settings.