Egress through Cloudflare Tunnel

Some third-party services only accept connections from specific source IPs listed in an Access Control List (ACL). If a non-Cloudflare IP (for example, an IP from your ISP or a cloud provider like AWS) is already on their allowlist, you can route traffic through a Cloudflare Tunnel so that it exits using that same IP. This is called source IP anchoring — it allows you to keep your existing egress IPs without purchasing Cloudflare dedicated egress IPs.

For example, assume your banking service at app.bank.com expects traffic from an AWS IP. You install cloudflared in your AWS environment and add a public hostname route for app.bank.com. When users connect to app.bank.com through the Cloudflare One Client, Gateway applies your network policies and routes the filtered traffic through the Cloudflare Tunnel to AWS. The traffic then exits 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["Cloudflare One
				Client"]--"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 ↗.

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

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.

To route a public hostname through Cloudflare Tunnel:

1. In the Cloudflare dashboard, go to Networking > Routes.

   Go to Routes ↗

2. Select Create hostname route.

3. In Hostname, enter the public hostname that represents the application (for example, app.bank.com). The hostname should be accessible from the public Internet.

4. For Tunnel, select the Cloudflare Tunnel that is being used to connect the private network to Cloudflare.

5. Select Create route.

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

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

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Gateway's network engine operates at Layer 3/Layer 4 of the OSI model ↗, where only IP addresses are available — not hostnames. The initial resolved IP acts as a signal: when a packet's destination IP falls within this range, Gateway recognizes that the IP maps to a public hostname route and sends the traffic through the corresponding Cloudflare Tunnel.

To route initial resolved IPs through the Cloudflare One Client:

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: 172.64.128.0/20
  • IPv6: 2606:4700:0cf1:4000::/64

  This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

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

You can build Gateway network policies to filter HTTPS traffic to your public hostname on port 443. For example, to restrict app.bank.com so that only certain users or groups can access it through your AWS egress IP, create two policies: one to allow authorized users, and one to block everyone else.

1. Allow company employees:

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

2. Block everyone else on port 443:

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

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

From a 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.

Starting with Chrome 142 ↗, Local Network Access (LNA) restricts requests from websites to local IP addresses. LNA is implemented at the Chromium engine level, so this affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This can affect accounts whose Gateway initial resolved IP range is still drawn from Carrier-Grade NAT (CGNAT) address space (100.64.0.0/10) — for example, the legacy default range 100.80.0.0/16, or a custom range configured within CGNAT space. These browsers categorize such 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 in this space, the browser 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. The browser blocks 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 into CGNAT space.

Accounts using the current default initial resolved IP range (172.64.128.0/20) are not affected, because this range is public Cloudflare address space rather than CGNAT. If your account was created before this default changed, or if you configured a custom CGNAT-space range, refer to Configure initial resolved IPs to move to a non-CGNAT range instead of relying on the following browser workarounds.

The workarounds below use Google Chrome Enterprise policies. If your organization manages a different Chromium-based browser, consult that browser's enterprise policy documentation for an equivalent control.

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.

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 your CGNAT-space initial resolved IP range (for example, 100.80.0.0/16) 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.