The host dials out, the internet walks in

One command exposes a service running on an internal host to the public internet, over a valid TLS certificate, without opening a single inbound port on the perimeter firewall. The command is cloudflared tunnel --url http://localhost:8080. It requires no Cloudflare account, no registered domain, and no change request. It returns a random hostname on trycloudflare.com that anyone on the internet can reach.

Cloudflare calls this feature Quick Tunnels, delivered through the TryCloudflare service and the cloudflared client. The client opens an outbound connection from the host it runs on to Cloudflare’s edge network. Cloudflare terminates TLS at the edge, assigns the ephemeral trycloudflare.com hostname, and proxies inbound requests back down the connection the client already established. The internal host never accepts an inbound connection from the internet. It dials out. The public listener is Cloudflare, not the host.

For a penetration testing exercise, this is not a convenience feature. It is an ingress and egress primitive that operates outside the control most organisations rely on to govern what is reachable. The behaviour is documented, the client is signed, and the destination is a major CDN. Every property that makes the traffic safe to allow is the same property that makes it useful to an operator working inside the boundary.

Most network defence is built on a single assumption: the perimeter firewall governs reachability. Inbound is denied by default. For a service to be exposed to the internet, something has to permit it. An open inbound port, a NAT rule, a DMZ placement, a load balancer publishing the listener. Reachability is treated as a property the security team grants explicitly, and the inbound ruleset is where that grant is recorded and enforced.

The second half of the assumption is that outbound traffic is trusted. Egress to major cloud and CDN providers is allow-listed because business systems depend on it. TLS to a reputable domain reads as normal traffic. Where egress filtering exists at all, it is usually built on domain and category reputation, and Cloudflare sits inside the allowed set. Analysts triaging outbound connections weight destination reputation heavily. A session to a trycloudflare.com host over 443 does not present as hostile.

This model comes from a network position view of trust. What you can reach, and what can reach you, is defined by where you sit relative to the firewall. The listener has to be exposed for it to be attacked. Segmentation, DMZ design, and inbound rule review all assume that exposure is an inbound event the perimeter can see and stop. The control and the boundary are treated as the same object.

Quick Tunnels invert the ingress direction. The public listener is Cloudflare’s edge. The internal host establishes the session outbound, and inbound internet requests are carried back down that existing session. No inbound firewall rule is consulted, because no inbound connection is ever offered to the perimeter. The control the organisation relies on to govern reachability is not in the path of the traffic it is meant to govern. It is not bypassed by a flaw. It is bypassed by direction.

Every trust anchor the defence assumed now works for the operator. The tunnel egresses over outbound 443 and QUIC to Cloudflare, which egress filtering permits. The public hostname carries a valid, Cloudflare-issued TLS certificate, so certificate inspection passes. The destination domain is trycloudflare.com, which reputation-based triage rates as benign. The same properties that justified allowing Cloudflare are the properties that carry the tunnel through the controls unexamined.

For an engagement, this collapses several setup steps into one command. A phishing page, a payload host, a command and control redirector, or reverse access to an internal-only service can be stood up on a trusted TLS hostname in seconds, with no account to attribute and no infrastructure to register. The tunnel is ephemeral and dies with the process, which shortens the window available to any control that works retrospectively. The reachability of an internal listener is now decided by a client the host can run outbound, not by the inbound ruleset the security team maintains.

The failure is positional. The perimeter firewall enforces reachability on inbound connections. A Quick Tunnel carries inbound internet requests down a session the internal host opened outbound. The inbound ruleset is never consulted, because no inbound connection is offered to it. The control did not fail under load and did not misread a rule. It was never in the path of the traffic it exists to govern.

The boundary that broke is the one between what a host can reach and what can reach the host. The organisation treats these as separate states governed by separate rules. The cloudflared client collapses them. A host permitted to open an outbound 443 or QUIC session to Cloudflare is, by that same permission, able to publish a listener the internet can reach. The capability to egress to a trusted destination is the capability to accept ingress carried back from it. There is no additional grant. The outbound permission is the ingress grant.

What enabled the access is identity and execution context, not a network exposure. The reachability of the internal service is a function of what the host can run and where it can connect, not of what the perimeter permits inbound. If the process can execute cloudflared and the destination is reachable, the tunnel stands up. Inbound rule review, DMZ placement, and listener segmentation describe a boundary the traffic does not cross. What is externally observable is an outbound session to Cloudflare and inbound requests arriving on it. None of that behaviour is offered to the control designed to stop it.

The pattern is direction. A control that inspects one direction of traffic is not a control for a technique that does not use that direction. The perimeter firewall governs inbound. The technique establishes reachability outbound. The control and the technique never occupy the same path. This is not specific to Cloudflare. Any outbound-initiated session to a trusted intermediary that proxies requests back down the same connection reproduces the failure, because the property being used is the direction of session establishment, not the identity of the provider.

The second half of the pattern is that trust granted for one function is available for every function the channel can carry. Egress to Cloudflare was permitted for the business traffic that depends on it. That permission does not scope what the channel does once open. A session allowed because the destination is reputable carries a reverse-reachable listener with the same reputation, the same valid TLS certificate, and the same benign destination rating. The controls that examine destination and certificate return the verdict they were built to return. They pass the tunnel because the tunnel presents exactly the properties they were built to trust.

This closes the loop with the assumption the defence started from. Reachability was treated as an inbound event the perimeter records and enforces. The mechanism shows reachability can be granted entirely outbound, by a client the host runs, to a destination the organisation already trusts. Every layer that reads destination reputation, certificate validity, and traffic direction as safety signals is reading the same signals the operator depends on to pass. The tunnel is ephemeral and terminates with the process, which removes the residual artifact a retrospective control would need to act on. The control set is not defeated at a single point. It is bypassed as a set, because every member inspects a direction or a property the technique satisfies by design.

Treat the inbound firewall as what it is: a control over inbound connections, and nothing more. It is not a reachability control for services exposed through an outbound-initiated tunnel. For this technique it is ineffective, and effectiveness is measured by whether the control sits in the path, not by whether it is correctly configured. A correctly configured control the traffic never touches is not a partial control. It is absent.

Reachability is decided where the session is established. For a Quick Tunnel that is outbound, on the host, by whatever can execute cloudflared and connect to Cloudflare’s edge. That is the control point. If the ability to run the client and open the outbound session is not governed, then reachability of internal services is not governed, regardless of the state of the inbound ruleset. Egress to Cloudflare must be treated as what it demonstrably is: a grant that includes reverse reachability, not a benign convenience.

What must now be true is a single accounting. Every path by which an internal host can reach a trusted intermediary is a path by which that host can be reached. Destination reputation, certificate validity, and outbound direction are not evidence of safety when the technique is built from exactly those properties. If a host can run the client and reach the edge, the tunnel will stand up. If the system allows it, it will happen. Govern the capability and the egress, or accept that the inbound ruleset describes a boundary the traffic has no reason to cross.

See also: NordVPN for tunneled traffic when operating outside controlled networks.

---

#ad Contains an affiliate link.