Feedback needed on new feature: private network between WARP and Argo Tunnel

Hi everyone - you can now use Argo Tunnel to create a private network that runs on Cloudflare’s network. You can connect services available at RFC 1918 IPs and users can enroll and reach them through the Cloudflare WARP client - with just a single click.

We could use some help testing the feature and would appreciate your feedback. Walkthrough guide on how to enable it below:

Some notes:

Requirements

  • You will need a Cloudflare for Teams Standard or Gateway plan

Limitations

  • Users authenticate into the WARP client once. Unlike Access today, which enforces Zero Trust rules on each request, that is the only auth event required. We’re bringing that Zero Trust set to this feature in an upcoming release.

Help testing

  • We’re interested in all feedback, but especially notes on protocols that have issues, deployment usability, and feature requests.
8 Likes

Great feature! Did expect this kind of feature, but didn’t think it would be this fast.

However, looking from performance view, WARP is not enabled on all colos, so there might be performance drawbacks (especially non-http services) compared to using ordinary Argo tunnel (connected to nearest colo w/ paid plans, this is client side). Personally I would rather use similar alternatives (tailscale, zerotier, etc) or use the ordinary Argo tunnel if I don’t see any benefits from using Argo + WARP.

Haven’t tried it yet though, will try it soon.

SSH and HTTP works so far. Will try connect to other services and protocols.

I would like to see how’s the auditing part can be done. I assume it’s logged part of Cloudflare Gateway HTTP logs?

It will be part of Gateway logs soon; that will be added with the Zero Trust rules in an upcoming release.

Please keep us posted on the other services and protocols you test!

2 Likes

The “Split Tunnel” option is quite handy for us to specify a subnet not to route via WARP. But, I would like to see an option to exclude a smaller subnet from a larger subnet (in case we just need that smaller subnet to route to WARP, but not the rest of the large subnet). For example, 192.168.0.0/16 is included in the split tunneling record, however I just need to route a smaller subnet to WARP - which is 192.168.100.0/24, while keeping the rest local.

This is fantastic. Will be experimenting with RDP and file share workloads.

Key for us to roll out deployment would probably be a “route only Access workloads / just these zones ranges”. This allows us to EASILY co-exist with existing VPN infra, allows for in office access without disrupting in office access to file shares / printers etc, allows remote users (with an endless array of local network topologies) to just connect to the access workloads without messing up their youtube, music, printer, network scanners etc.

Over time of course may migrate more onto the access model, at some point even “in office” workloads. But to get there need the easiest possible roll-out options to get users access to Access workloads.

OK - a bit of experimenting later.

Is there a mode I am missing to just do access only with Warp / Cloudflare for Teams.

Ie, no scary notice to staff working from home that company will be watching all their traffic.

Our goal is pretty simple - absolutely simplest way to get a zero trust model going.

The google login is fantastic.
The warp client is pretty deployable.

BUT

  • There is a scary notice about all traffic being monitored. I just want to do a VPN replacement (for now) so that traffic for specific routes / IP’s goes goes over WARP to our tunneled RDP session hosts etc. Am I missing something here?