CF Egress

[rshenderson]

Hi, Just had sometime to day to work on some of the INetPanel.
Feature request, add the ability to have Cloudflare Egress which would mean CF would not have to run in token mode, that might break everything.

Randy

[Tux82]

Are you referring to the dedicated egress IP with Cloudflare?

[rshenderson]

Yes, I have a site that authenticates by Ip address since my is somewhat dynamic and this setting is not something can be managed with a service like dyndns if CF egress was an option my outgoing api backend connect would always have the same ip.

[Tux82]

Thanks Randy — that's a clear use case, and you're right that DDNS can't solve it. A service that allowlists an IP literal doesn't care that a hostname follows you around.

I dug into what Cloudflare actually offers here, and the short version is that this isn't something the panel can turn on for you. Worth laying out why, and what does work.

The tunnel isn't in the path

cloudflared is ingress only. It dials out to Cloudflare's edge to receive inbound traffic for your sites — it doesn't touch connections your server initiates. When your backend calls that API, the packets leave over your normal ISP path with your dynamic IP, exactly as they would if the tunnel weren't running.

So the good news for your worry about breaking things: egress is a completely separate mechanism. Nothing about it would change how the panel runs the tunnel, and token mode stays exactly as it is. There's no version of this where fixing egress puts your ingress at risk.

Cloudflare's dedicated egress IP is Enterprise-only

The product you're thinking of is dedicated egress IPs under Zero Trust Gateway. The docs are blunt about it — "Only available as an add-on to Zero Trust Enterprise plans", and you have to "Contact your account team to obtain a dedicated egress IP."

Even with the entitlement, the traffic has to be proxied by Gateway, which means running the Cloudflare One (WARP) client on the box and enrolling it in a Zero Trust org. That's a heavier footprint than I'd want to put on a hosting server that's already running a tunnel, and it's an account-level entitlement rather than a config toggle — the panel couldn't provision it for you even if I wired up the UI.

There's also a feature called egress through Cloudflare Tunnel that sounds like exactly this, but it runs the other direction: it routes WARP-enrolled user traffic through Gateway and down a tunnel into infrastructure you already own, so it exits from that infrastructure's IP. It assumes you already have a box with the allowlisted static IP. If you had one, you wouldn't need Cloudflare in the middle.

What actually solves it

Any host with a static IP, used as an egress hop for that one API. A $4–5/month VPS is enough — this is a handful of API calls, not bulk traffic.

Two ways to use it, easiest first:

A proxy, scoped to just that API client. Run tinyproxy or a SOCKS5 listener on the VPS, locked to your server's IP, and point only that one backend call at it. In PHP that's a couple of cURL options:

curl_setopt($ch, CURLOPT_PROXY, 'socks5h://your-vps:1080');
curl_setopt($ch, CURLOPT_PROXYUSERPWD, 'user:pass');

Nothing else on the box is affected, no routing tables change, and if the VPS dies only that one integration stops — your sites stay up. For an SSH-only version with no daemon to maintain, ssh -N -D 1080 user@your-vps via autossh gets you the same thing.

Policy routing over WireGuard, if you'd rather it be transparent to the app. WireGuard to the VPS, then a routing rule sending only that API's destination IPs over wg0. Cleaner from the app's point of view, but it's real routing config and a mistake there can black-hole traffic — I'd only go this way if the upstream has a stable, documented set of IPs.

Either way you allowlist the VPS's IP with the upstream once and never think about it again, which is the actual goal.

For the panel

I'm not going to add a Cloudflare-egress button, since it'd be a button that does nothing without an Enterprise contract. But the general shape is worth having, and it'd cover you and anyone else with an IP-allowlisted upstream:

Egress routing — define an egress hop (WireGuard peer or SOCKS/HTTP proxy) plus the destinations that should use it, and the panel handles the config, keeps it alive across reboots, and shows you the effective source IP so you can confirm what the upstream will see.

Fair warning that it's a bigger job than it looks. The panel's WireGuard support today sets your box up as a WG server for admin lockdown — peers dial in, and everything masquerades out your main interface. Egress routing is the client direction, so it's new plumbing rather than a flag on the existing feature. It's on the list, but behind the reliability work coming out of #17.

One thing worth checking before any of this: does that API let you allowlist a hostname instead of an IP? A few do, and if yours is one of them the panel's Cloudflare DDNS (Settings → Cloudflare) already keeps a record pointed at your current IP, and you'd be done today for free. Long shot, but it costs one support ticket to find out.

If you do go the VPS route, tell me which provider and I'll write up the exact setup — happy to fold it into the docs, since you won't be the last person to hit this.

[rshenderson]

Thanks for checking