A homelab server without a public IPv4 usually turns to Cloudflare Tunnel first. It is free, it removes port forwarding, and a web app becomes reachable in a few minutes without touching the router. For a self-hosted website or API, that is often the whole problem solved.
The same tunnel does not turn that server into a normal public IP address. A game server, a mail server, a self-hosted VPN endpoint, or anything using a protocol other than HTTP will not become reachable to an anonymous visitor through it, no matter how the tunnel is configured. Knowing exactly where that line sits decides whether Cloudflare Tunnel is enough on its own, or whether a routed IPv4 needs to sit next to it.
What Cloudflare Tunnel actually does
Cloudflare Tunnel runs a small daemon, cloudflared, on the machine that hosts the application. That daemon opens an outbound connection to Cloudflare's network and keeps it open. Nothing needs to be forwarded on the router, and no public IPv4 needs to sit on the server at all. Cloudflare's own description of the mechanism is that cloudflared "creates outbound-only connections" to its edge, so the origin server's firewall can "block all inbound traffic" entirely. Cloudflare: Connect networks with Cloudflare Tunnel
When the exposed resource is a public hostname over HTTP or HTTPS, this works for any visitor. A browser, a mobile app, or a plain curl request connects to Cloudflare's edge exactly as it would connect to any other website. Cloudflare terminates TLS, proxies the request through the already-open tunnel, and returns the response. No visitor needs an account, a client, or any special software. This is the case Cloudflare Tunnel was built for, and it removes port forwarding completely for that traffic.
Where Cloudflare Tunnel cannot follow you
The same tunnel behaves differently once the exposed service stops being an HTTP request. Cloudflare's documentation for arbitrary TCP applications, the category that covers SSH, RDP, and raw database ports, requires the connecting client to run cloudflared locally and authenticate through a Cloudflare Access policy tied to an identity provider. There is no anonymous path into that connection type. Cloudflare: Arbitrary TCP applications
UDP is more restrictive again. Cloudflare added UDP support to its Zero Trust private network routing, but only for devices already enrolled with the WARP client inside that Zero Trust organization. Cloudflare's own announcement describes end users downloading "the Cloudflare WARP agent" and being matched by an enrollment policy before a device can reach a UDP resource this way. Cloudflare: Extending Zero Trust to UDP A visiting game client, a customer's SIP phone, or a stranger's WireGuard peer cannot install WARP and join a Zero Trust organization just to reach a service that is supposed to be public.
A second limit is worth naming honestly, even though it is less clear-cut. Cloudflare retired the old clause that singled out non-HTML content in 2023, but the replacement CDN-specific terms still treat sustained, high-bandwidth media traffic differently from ordinary web pages, and community discussion on Cloudflare's own forum shows the line is not fully settled. A self-hosted Plex or Jellyfin library pushed through the free tunnel around the clock is a case to treat cautiously rather than assume is fully covered, and worth checking against the current terms before relying on it.
| Service | Cloudflare Tunnel, anonymous visitor | Routed IPv4 |
|---|---|---|
| Website or API (HTTP/HTTPS) | Reachable by anyone | Reachable by anyone |
| SSH or RDP for your own admin access | Only with Access and your own SSO login | Reachable directly |
| Public game server (UDP or raw TCP) | Not reachable; needs WARP enrollment | Reachable directly |
| Mail server (SMTP, IMAP) | Not reachable | Reachable directly |
| Self-hosted VPN endpoint of your own | Not reachable; needs WARP enrollment | Reachable directly |
| Continuous self-hosted media (Plex, Jellyfin) | Discouraged for sustained media traffic | No content-type restriction |
How a routed IPv4 covers the gap
A Taipan Transit routed IPv4 starts from the same idea as Cloudflare Tunnel: the server dials out, over WireGuard, GRE, or IPsec, and keeps that connection open. Nothing needs to be forwarded on the home router or a CGNAT gateway either. The difference is what happens at the far end. Cloudflare terminates HTTP requests and proxies them. Taipan routes the assigned public IPv4 through the tunnel at the IP layer, so every protocol and port the server itself allows becomes reachable, the same way it would be if the server held that public address directly.
That is why a game server, a mail transfer agent, a VPN endpoint of your own, or an application built on a custom protocol can sit behind CGNAT or a shared home connection and still accept connections from any anonymous client, without asking that client to install anything. The visitor does not know, and does not need to know, that the traffic crossed a tunnel before reaching the server.
Taipan Transit routes a dedicated public IPv4 through WireGuard, GRE, or IPsec starting at €2 per month for the tunnel and €0.70 per month per address on its pricing page. Add one when a service needs to be reachable by anonymous visitors on a protocol Cloudflare Tunnel cannot forward.
Run both without conflict
Choosing one tool does not require abandoning the other. A homelab commonly keeps its web apps behind Cloudflare Tunnel, where the free anonymous HTTPS path stays genuinely convenient, and adds a routed IPv4 only for the specific service that needs to be reachable outside of Cloudflare Access: a game server for friends, a mail server with its own reverse DNS, or a WireGuard endpoint of the homelab's own. The two paths do not need to overlap. Keep the DNS records and cloudflared configuration for the HTTP apps unchanged, and point only the new service at the routed address.
The common mistake is treating a WARP-enrolled private network as a smaller version of a public service. Enrolling a device in a Zero Trust organization authorizes that one device under that one policy. It cannot stand in for a service that unknown visitors, customers, or game clients must reach without any enrollment step. Cloudflare Tunnel remains the right tool for the HTTP traffic it was built for. A routed IPv4 is the tool for the traffic that needs a real public address behind it.
Frequently asked questions
Can Cloudflare Tunnel expose a Minecraft or other game server to the public?
No. A public game server needs anonymous UDP or raw TCP reachability. Cloudflare's Zero Trust private network routing only accepts connections from devices already enrolled with the WARP client, so random players cannot join through it.
Does Cloudflare Tunnel need port forwarding?
No. The cloudflared daemon opens the connection outward from the server, the same outbound-only principle a routed IPv4 tunnel uses, so no inbound rule is needed on the router or CGNAT gateway.
Is Cloudflare Tunnel free?
The tunnel transport itself has no cost or usage cap. Cloudflare Access, which gates non-HTTP resources, stays free for up to 50 users before per-user billing applies.
Can Cloudflare Tunnel and a routed IPv4 be used together?
Yes. Keep existing HTTP apps on Cloudflare Tunnel and route a dedicated IPv4 only for the service that needs anonymous non-HTTP reachability, such as a game server or a mail server.