Egress through Cloudflare Tunnel

WARP feature availability

WARP modes
Traffic and DNS mode

System	Availability	Minimum WARP version
Windows	✅	2025.4.929.0
macOS	✅	2025.4.929.0
Linux	✅	2025.4.929.0
iOS	✅	1.11
Android	✅	2.4.2
ChromeOS	✅	2.4.2

A Cloudflare Tunnel can be used for source IP anchoring when you want to use existing egress IPs instead of purchasing Cloudflare dedicated egress IPs. Some third-party websites may have an Access Control List (ACL) that only allows connections from certain source IPs. If you already have a non-Cloudflare IP on their allowlist (such as an egress IP provided by an ISP or a cloud provider like AWS), you can configure cloudflared to anchor user traffic to the same IPs that you use today.

For example, assume that your organization's banking service, app.bank.com, expects user traffic to come from an AWS IP. You can install cloudflared in your AWS environment and add a public hostname route pointing to app.bank.com. When users connect to app.bank.com using the WARP client, Gateway will apply your network policies and route the filtered traffic down the corresponding Cloudflare Tunnel to AWS. The traffic can then egress to the public Internet using your AWS egress IP.

    flowchart LR
      subgraph aws["AWS VPC"]
				cloudflared["cloudflared"]
      end
			subgraph cloudflare[Cloudflare]
			  gateway["Gateway"]
			end
			subgraph internet[Internet]
				resolver[1.1.1.1]
				app[Application]
			end
      warp["WARP
			  clients"]--"app.bank.com"-->gateway--"Network traffic"-->cloudflared
			gateway<-.DNS lookup.->resolver
			aws--AWS egress IP -->app

To learn more about how Gateway applies hostname-based egress policies, refer to the Cloudflare blog ↗.

Prerequisites

User traffic is on-ramped to Gateway using one of the following methods:

On-ramp method	Compatibility
WARP	✅
PAC files	✅
Browser Isolation	✅
WARP Connector	✅
Cloudflare WAN	🚧¹

WARP feature availability

WARP modes
Traffic and DNS mode

System	Availability	Minimum WARP version
Windows	✅	2025.4.929.0
macOS	✅	2025.4.929.0
Linux	✅	2025.4.929.0
iOS	✅	1.11
Android	✅	2.4.2
ChromeOS	✅	2.4.2

Not compatible with ECMP routing. For hostname-based routing to work, DNS queries and the resulting network traffic must reach Cloudflare over the same IPsec/GRE tunnel.
↩

1. Connect your private network

Connect your private network to Cloudflare using cloudflared. For example, if you want traffic to egress from AWS, connect the private CIDR block of your AWS VPC.

2. Add a public hostname route

To route a public hostname through Cloudflare Tunnel:

In Cloudflare One ↗, go to Networks > Routes > Hostname routes.
Select Create hostname route.
In Hostname, enter the public hostname that represents the application (for example, app.bank.com). The hostname should be accessible from the public Internet.
For Tunnel, select the Cloudflare Tunnel that is being used to connect the private network to Cloudflare.
Select Create route.

3. Route network traffic through WARP

In your WARP Split Tunnels configuration, route the following IP addresses through the WARP tunnel to Gateway.

Initial resolved IPs

When users connect to a public hostname route, Gateway will assign an initial resolved IP to the DNS query from the following range:

The initial resolved IP is required because Gateway's network engine operates at L3/L4 and can only see IPs (not hostnames) when processing the connection. If a packet's destination IP falls within the initial resolved IP CGNAT range, Gateway knows that the IP maps to a public hostname route and sends the traffic down the corresponding Cloudflare Tunnel.

To route initial resolved IPs through WARP:

In your WARP device profile, configure Split Tunnels such that the initial resolved IPs route through the WARP tunnel. Configuration depends on your Split Tunnels mode:

Exclude mode: Delete 100.64.0.0/10 from your Split Tunnels list. We recommend adding back the IP ranges that are not explicitly used for Cloudflare One services. This reduces the risk of conflicts with existing private network configurations that may use the CGNAT address space.
Include mode: Add Split Tunnel entries for the following IP addresses:
- IPv4: 100.80.0.0/16
- IPv6: 2606:4700:0cf1:4000::/64

Private network IPs

Your private network's CIDR block should also route through the WARP tunnel. For a detailed configuration example, refer to Connect a private network.

4. (Optional) Configure network policies

You can build Gateway network policies to filter HTTPS traffic to your public hostname on port 443. For example, suppose that you want to block all WARP users from accessing app.bank.com except for a specific set of users or groups. Additionally, those authorized users should only access app.bank.com using your AWS egress IP. You can accomplish this using two policies: the first allows specific users to reach app.bank.com, and the second blocks all other port 443 traffic to app.bank.com.

Allow company employees:

Selector Operator Value Logic Action
SNI in app.bank.com And Allow
User Email matches regex .*@example.com
Block everyone else on port 443:

Selector Operator Value Action
SNI in app.bank.com Block

Selector	Operator	Value	Logic	Action
SNI	in	`app.bank.com`	And	Allow
User Email	matches regex	`.*@example.com`

Selector	Operator	Value	Action
SNI	in	`app.bank.com`	Block

Gateway does not currently support hostname-based filtering for traffic on non-443 ports. To block traffic to app.bank.com on all ports, you will need to use the Destination IP selector and specify the public IP space of app.bank.com.

5. Test the connection

From a WARP device, open a browser and go to app.bank.com.

You can search for app.bank.com in your Gateway DNS logs; the DNS response details section should show the public resolved IPs as well as an initial resolved IP. You can also check your Cloudflare Tunnel logs to confirm that requests are routing through the tunnel to the public resolved IPs.

Limitations

Google Chrome restricts local network access

Starting with Chrome 142 ↗, the browser restricts requests from websites to local IP addresses, including the Gateway initial resolved IP CGNAT range (100.80.0.0/16). Because this range falls within 100.64.0.0/10, Chrome categorizes these addresses as belonging to a local network. When a website loaded from a public IP makes subrequests to a domain resolved through an initial resolved IP, Chrome treats this as a public-to-local network request and displays a prompt asking the user to allow access to devices on the local network. Chrome will block requests to these domains until the user accepts this prompt.

This commonly occurs when an Egress policy matches broadly used domains (such as cloudfront.net or github.com), causing subrequests from public pages to resolve to the 100.80.0.0/16 range.

Iframes

If the affected request originates from within an iframe (for example, an application embedded in a third-party portal), the iframe must declare the local-network-access permission for the browser prompt to appear in the parent frame:

Chrome 142-144: Use the allow="local-network-access" attribute on the iframe element.
Chrome 145+: The permission was split into allow="local-network" and allow="loopback-network".

If iframes are nested, every iframe in the chain must include the appropriate attribute. Since third-party applications control their own iframe attributes, this may not be configurable by the end user.

Workarounds

To avoid this issue, choose one of the following options:

Override IP address space classification (Chrome 146+): Use the LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome Enterprise policy to reclassify the 100.80.0.0/16 range as public. This is the most targeted fix because it only changes the classification for the initial resolved IP range rather than disabling security checks entirely.
Allow specific URLs (Chrome 140+): Use the LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise policy to exempt specific websites from Local Network Access checks. Note that https://* is a valid entry to disable checks for all URLs.
Allow specific URLs (Chrome 146+): Use the LocalNetworkAllowedForUrls ↗ Chrome Enterprise policy, which replaces LocalNetworkAccessAllowedForUrls starting in Chrome 146.
Opt out of Local Network Access restrictions (Chrome 142-152): Use the LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise policy to completely opt out of Local Network Access restrictions. This is a temporary policy and will be removed after Chrome 152.
Disable the Chrome feature flag: Go to chrome://flags and set the Local Network Access Checks flag to Disabled. This approach is suitable for individual users but not for enterprise-wide deployment.