Private networks and SSH

A route publishes one web service at a hostname. Two more ways reach things that aren't web pages:

• A private network: people signed in to your Cloudflare Zero Trust organization with the WARP client reach addresses on this machine's network, like a NAS at 192.168.1.20 or a whole range such as 192.168.1.0/24, as if they were at home. Nothing gets a public hostname.
• A private hostname: the same WARP users reach a name such as wiki.internal without knowing its address. This machine looks the name up and connects to whatever it points to.
• SSH, RDP, SMB and TCP routes: a hostname that carries a non-HTTP service; visitors connect with cloudflared on their computer.

Share a private networkCopy Anchor Link

What you needCopy Anchor Link

• Cloudflare Zero Trust set up on the account (free for up to 50 users), and the WARP client on each device that should reach the network, signed in to your organization.
• Account · Cloudflare Tunnel · Edit on the credential (it covers private network routes). Zero Trust read access lets the Doctor check WARP settings too.

In the appCopy Anchor Link

To stop, choose the stop button next to the range (Stop sharing 192.168.1.0/24), then Stop Sharing. Ranges added outside Teitunnel are marked Added outside Teitunnel.

From the terminalCopy Anchor Link

teitunnel network add 192.168.1.0/24
teitunnel networks                     # --json
teitunnel network remove 192.168.1.0/24

-y applies without asking, -a picks the account, and --replace confirms a public range.

What Teitunnel checksCopy Anchor Link

• A range already routed to another tunnel is refused ("… is already shared through tunnel “…”. Remove that route first.").
• A range that overlaps another tunnel's is allowed, with a warning: for addresses both cover, the narrower range wins.
• A public range (not 10.x, 172.16–31.x, 192.168.x, 100.64–127.x or fd00::/8) needs a confirmation (Send these public addresses through this Mac), because WARP users would reach those addresses through this machine instead of the internet.
• Ranges broader than /8 (IPv4) or /16 (IPv6), loopback and link-local addresses are refused.

Routes go in the account's default virtual network. Removing this machine's tunnel removes the ranges routed to it; other tunnels' ranges are never touched.

When WARP users can't reach itCopy Anchor Link

The Doctor reads your WARP settings once you share a network and warns about the usual causes, which only you can change in the Zero Trust dashboard:

• Split Tunnels exclude the range (network.excluded). Cloudflare's default device profile excludes private address space such as 192.168.0.0/16, so WARP sends that traffic to the local network. Remove or narrow the entry.
• Split Tunnels don't include it (network.not_included), in include mode: add the range.
• The Gateway proxy is off (network.proxy_off). Turn it on for TCP, and UDP if your services use it.

Without read access to the Zero Trust settings, routes keep working and the Private Networks section says what's missing ("This account's API token can't read private networks.").

Share a private hostnameCopy Anchor Link

A private hostname route sends WARP users' traffic for one name, like wiki.internal or nas.home.arpa, through this machine's tunnel. The connector here looks the name up with this machine's DNS (its hosts file, or the DNS server it uses) and connects to that address on the port the WARP user asked for. There's no public DNS record and no route to set up in the tunnel: only WARP users of your organization reach it.

What you needCopy Anchor Link

Everything a private network needs (above), and:

• This machine can look the name up. Try ping wiki.internal here. If it doesn't resolve, add it to this machine's hosts file (/etc/hosts, or C:\Windows\System32\drivers\etc\hosts on Windows) or to your local DNS server.
• A recent WARP client: 2025.4.929.0 or later on Windows, macOS and Linux, 1.11 on iOS, 2.4.2 on Android and ChromeOS. Teitunnel's cloudflared is recent enough (hostname routes need 2025.7.0 or later).
• In the Zero Trust dashboard, the Gateway proxy on for TCP (and UDP), and the name's top-level domain (such as internal) removed from Local Domain Fallback, so WARP asks Cloudflare for the name instead of the local network.
• Split Tunnels that send WARP's initial resolved addresses through WARP: 172.64.128.0/20 and 2606:4700:0cf1:4000::/64 unless you changed them. In include mode, add them.

Share itCopy Anchor Link

In the app, it's the same Share a Private Network sheet: enter the hostname as the Network, review "Route private hostname wiki.internal to tunnel “…”", and choose Share. The name is listed under Private Networks with the ranges.

teitunnel network add wiki.internal
teitunnel networks                     # ranges, then hostnames
teitunnel network remove wiki.internal

AI agents use the same addNetwork and removeNetwork changes in the MCP server.

What Teitunnel checksCopy Anchor Link

• Exact names only: wildcards (*.internal) and single words (wiki) are refused, and so are localhost names, which always mean the WARP user's own device.
• A name already routed to another tunnel is refused ("… is already shared through tunnel “…”. Remove that route first.").
• A name on one of the account's domains, like intranet.yourhost.com, needs a confirmation (Send this hostname through this Mac for WARP clients, or --replace), because WARP users would reach this machine instead of its public address.
• Removing this machine's tunnel removes the hostnames routed to it; other tunnels' hostnames are never touched.

Hostname routes carry TCP and UDP only; ping and other ICMP tools need an address range. If WARP users can't reach the name, the Doctor reports a name this machine can't look up (network.hostname_unresolved) and a Gateway proxy that's off (network.proxy_off). It doesn't check Split Tunnels or Local Domain Fallback for hostnames, since the credential can't read them.

Requirements per Cloudflare's Connect a private hostname, checked 2026-09-26.

Connect to SSH, RDP, SMB and TCP routesCopy Anchor Link

A route can carry SSH, Remote Desktop, SMB or any TCP service: use an origin like ssh://localhost:22, rdp://localhost:3389, smb://localhost:445 or tcp://localhost:5432.

teitunnel route add ssh.yourhost.com ssh://localhost:22 --allow team@yourhost.com

A browser can't open these, so the route's details show a Connect section with the command visitors run, with cloudflared installed on their computer:

For SSH it also gives an ~/.ssh/config entry, so plain ssh ssh.yourhost.com works:

Host ssh.yourhost.com
  ProxyCommand cloudflared access ssh --hostname %h

The local port for RDP and TCP is the route's own port; SMB uses 8445, since 445 is taken on most computers. Keep the command running while you're connected.

Combine it with Require a login so only the people you choose can connect: cloudflared opens the browser to sign in the first time. The SSH tutorial walks through it end to end.

Limits, costs and permissionsCopy Anchor Link

RelatedCopy Anchor Link