Matching egress policies to the right traffic
Egress policies control which source IP address an organization’s traffic uses when leaving for the public Internet. Because customers often use dedicated egress IPs to satisfy IP-based access control lists (ACLs) at external services, the destination hostname matters as much as the user identity. A regulated banking application, for example, might only allow a corporate account to be accessed from a single dedicated egress IP such as 203.0.113.9.
With a conventional egress policy, an administrator can restrict that dedicated IP to a specific user group. But until recently, the policy could only be written against a destination IP address, not a hostname. That forces the administrator to track the banking application’s IP address — which belongs to a third party, may change frequently, and could sit behind ephemeral infrastructure, a reverse proxy, or a CDN. Some customers resorted to homegrown scripts that continually update destination IP lists via Cloudflare’s API to keep egress policies aligned with the external services their users actually connect to.
Gateway evaluates egress policies at layer 4, before any connection is established. The source IP for a connection must be chosen before the first packet (the TCP SYN) is sent, and long before any layer 7 data such as HTTP is available. The IP and TCP headers do not carry a hostname, so Gateway previously had no way to make an egress decision based on the destination’s name. The only options were destination IP-based rules.
Hostname as a policy primitive
The new open beta feature lets egress policies reference hostnames directly. Instead of writing rules for an IP address that may change, an administrator can now define a policy for https://bank.example.com and apply it only to a user group such as the finance team. The external service still sees traffic from the dedicated egress IP via its own ACLs; the egress policy simply controls which users get that IP when reaching that hostname.
Hostname support extends to three related selectors:
- Domain: a single rule for
*.bank.example.comcovers all subdomains, eliminating the need for separate rules per hostname. - Content category: one policy can govern an entire category, such as Cryptocurrency, rather than requiring rules for each individual site.
- Application: a policy can target an application like Slack without enumerating all its backing domains and hosts (
app.slack.com,slack.com,acmeco.slack.com,slack-edge.com, and so on).
How hostname-based egress works
Gateway’s dual role — as both an L4/L7 proxy and a DNS resolver — is the key to the implementation. Every connection to a hostname begins with a DNS query that Gateway itself resolves. Gateway uses that lookup to bind the destination IP in the subsequent connection to the hostname the user originally requested.
The mechanism relies on a synthetic IP address. When a user queries for bank.example.com, the Gateway resolver performs its public DNS lookup and learns the real destination IP, say 96.7.128.198. But instead of returning that real IP to the user, it returns a temporary, randomly selected address from a reserved CGNAT range: 100.80.0.0/16 for IPv4 or 2606:4700:0cf1:4000::/64 for IPv6 (per RFC 6598 and RFC 6264). That initial resolved IP is a label that associates the connection with the hostname.
When Gateway sees traffic destined for the synthetic IP 100.80.10.10, it matches that address to bank.example.com and applies the corresponding egress policy. It then rewrites the destination from the synthetic IP to the real destination IP (96.7.128.198) and forwards the traffic from the chosen egress IP. The full sequence is:
- The user’s DNS query for
bank.example.comreaches the Gateway resolver. - Gateway resolves the hostname to its public IP,
96.7.128.198. - Gateway answers the user instead with the synthetic IP
100.80.10.10, which is tagged to the hostname. - When the user’s connection to
100.80.10.10arrives, Gateway recognizes the hostname and applies the matching egress policy. - Gateway rewrites the destination to the real IP
96.7.128.198and sends the traffic out the appropriate egress IP.
The rewritten traffic reaches the external service with the correct destination IP and the correct egress source IP, so the policy is enforced end-to-end without any change to how users or external services see the network.
Dynamic IP assignment behind the scenes
The initial resolved IP address that Gateway assigns to a hostname — say, 100.80.10.10 for bank.example.com — is not a permanent mapping. Gateway holds it for only a short window, then releases it back into the shared pool of addresses in 100.80.0.0/16, where it may later be assigned to a different hostname entirely.
This random dynamic assignment, rather than a static one-to-one hostname-to-IP mapping, is what makes the feature scalable. The 100.80.0.0/16 block contains only 65,536 addresses, far fewer than the number of hostnames a customer might need to write egress policies for. A dynamic pool lets Gateway support policies for an effectively unlimited number of hostnames without exhausting address space.
It also unlocks wildcard and grouped policies. A single egress policy for *.bank.example.com applies to any traffic for arbitrary subdomains like acmeco.bank.example.com or auth.bank.example.com. With static assignments, customers would need to author a separate policy per individual hostname — a far more cumbersome approach. The same mechanism extends to content categories and applications, which are essentially collections of hostnames that can share one policy.
A stateless-network constraint
Cloudflare’s network spans servers in over 330 cities across 125 countries. The architecture deliberately avoids sharing strongly-consistent storage between servers — even within a single data center — to keep performance and reliability high. This feature was therefore built under the assumption that no state is shared between any two Cloudflare servers.
That design constraint creates a problem. If an end user’s DNS traffic lands on one Cloudflare server and their network traffic lands on another, there is no way to correlate the hostname-to-destination-IP mapping (e.g., bank.example.com = 96.7.128.198, learned from DNS) with the initial resolved IP (e.g., 100.80.10.10) used by the network traffic. Without that correlation, the mechanism breaks and traffic is dropped.
The solution is to force DNS and network traffic to arrive at the same Cloudflare server by sending both through the same tunnel. Because of this requirement, egress policies by hostname currently work only with the following on-ramps:
- The WARP client, which now sends DNS traffic inside the WARP tunnel
- PAC files
- Browser Isolation
Support for additional on-ramps is under active development.
Roadmap
Beyond broadening on-ramp support, Cloudflare plans to apply hostname-based rulesets more widely across its SASE platform. These future features will all build on the same initial-resolved-IP mechanism, allowing customers to consolidate rulesets and enforce tighter security policies without needing per-hostname static mappings.
