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!

4 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?

@SamRhea : Your blog post from yesterday doesn’t mention anything about which type of plan is needed to access this feature.

The documentation doesn’t tell much either

The warp tunnel tutorial states “You must have a Cloudflare for Teams Gateway or Standard plan to use this feature”.

My question : Is it usable with the Free Plan ?


My initial guess was “yes” with a free plan and the corresponding CF:Teams Gateway policy

But I have not been able to make it work with my free plan

## Server side (the one initiating the argo tunnel)

cloudflared --version
cloudflared version 2021.4.0 (built 2021-04-07-2103 UTC)

cat /etc/cloudflared/config.yml
tunnel: ${TUNNELID}
credentials-file: /root/.cloudflared/${TUNNELID}.json
protocol: http2
warp-routing:
   enabled: true

cat /root/.cloudflared/${TUNNELID}.json | jq .
{
  "AccountTag": "${AccountTag}",
  "TunnelSecret": "${TunnelSecret}",
  "TunnelID": "${TUNNELID}",
  "TunnelName": "test3"
}

cloudflared tunnel list
ID                                   NAME  CREATED              CONNECTIONS
${TUNNELID} test3 2021-04-21T10:21:04Z 2xCDG, 2xWAW

cloudflared tunnel route ip show
NETWORK        COMMENT TUNNEL ID                            TUNNEL NAME CREATED              DELETED
192.168.1.0/24         ${TUNNELID} test3       2021-04-21T10:21:21Z -

ip a s dev eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether dc:a6:32:${redacted} brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.27/24 brd 192.168.1.255 scope global dynamic noprefixroute eth0
       valid_lft 84406sec preferred_lft 73606sec

# http demo service running on this test server 
curl http://192.168.1.27:8001/
Hello World

## CF Teams Gateway

Split tunnel configured accordingly

  • 192.168.0.0/16 removed

## Client side (the one initiating the WARP WG tunnel to cloudflare)

Client is on an other private subnet and has internet access

ifconfig
(...)
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	options=400<CHANNEL_IO>
	ether a4:5e:60:${redacted}
	inet6 fe80::c5b:29b1:c8f3:f980%en0 prefixlen 64 secured scopeid 0x4
	inet 172.20.10.2 netmask 0xfffffff0 broadcast 172.20.10.15
	nd6 options=201<PERFORMNUD,DAD>
	media: autoselect
	status: active

ping -c 3 google.com
PING google.com (142.250.74.238): 56 data bytes
64 bytes from 142.250.74.238: icmp_seq=0 ttl=120 time=72.230 ms
64 bytes from 142.250.74.238: icmp_seq=1 ttl=120 time=52.806 ms
64 bytes from 142.250.74.238: icmp_seq=2 ttl=120 time=59.121 ms
--- google.com ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 52.806/61.386/72.230/8.090 ms
  • WARP client version : 1.4.106 (20210407.1)
  • gateway with WARP enabled in the WARP client conf
  • user re enrolled in WARP for Teams (logout/login from warp client just to make sure)
  • subnet 192.168.0.0/16 not listed in WARP client Pref > Advanced > Excluded IPs
  • WARP for Teams is connected : “Your Internet is protected”

But, client can’t reach the private network 192.168.1.0/24

ping -c 3 192.168.1.27
PING 192.168.1.27 (192.168.1.27): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
--- 192.168.1.27 ping statistics ---
3 packets transmitted, 0 packets received, 100.0% packet loss

traceroute 192.168.1.27
traceroute to 192.168.1.27 (192.168.1.27), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  * *^C

curl http://192.168.1.27:8001/
curl: (7) Failed to connect to 192.168.1.27 port 8001: Operation timed out

More info :

Only connecting to private network is an issue;
Connecting application (HTTP or SSH) using an other cloudflared argo tunnel works fine on the same client and server, including access through CF:Gateway with idp auth or short-lived certificates for SSH

Standard plan is a higher tier than Free Plan. So, free plan is not included.

Thank you for your reply @erictung

I could be wrong, but “You must have a Cloudflare for Teams Gateway or Standard plan to use this feature” means to me “Cloudflare for Teams Gateway” free plan is enough, assuming you have a some gateway policy configured.

If free plan is not eligible (and I could understand that), may be it could be worth mentioning it in the doc and blog post.

Regards,

Uh, no. There’s no such thing as “Cloudflare for Teams Gateway” free plan or “Cloudflare for Teams Access” free plan. They only offer “Cloudflare for Teams” free plan, so you will get both.

Basically Cloudflare for Teams Gateway and Cloudflare for Teams Access are separate products that people can subscribe if they just want to purchase one product instead of purchasing the whole “Cloudflare for Teams Standard or Enterprise” plan - which includes both products.

1 Like

Ok, thank you @erictung, it makes sense now

It must be this part of the blog post that led me to the wrong assumption (emphasis mine) :

We’re excited to give any team the ability to run their internal network on Cloudflare’s global edge. Organizations that have 50 or fewer team members can use this feature, as well as nearly all of Cloudflare for Teams, at no cost by starting here.

I guess ones need to be ASA + ACE + ASE + ASP to navigate into the rich Cloudfront offering :wink:

Regards

2 Likes

Hmm, @SamRhea can you clarify on this?

Yeah, that’s exactly the part that got me to start on this project. I am on the free plan and I kept trying to get this to work but I kept failing. I finally realized that the docs specified that you be on a certain plan and I just gave up. I thought it was open to the free plan too. :frowning:

Oh, great.

I’ve just spent 2+ hrs on my personal CF account trying to figure out why this feature doesn’t work.

The blog post is worded just as if the private network routing is available on Free plan. What’s even more disturbing that during tunnel creation or even route ip add add command at no point is there a warning that the route will not be working due to plan constraints.

So I guess it’s zeros all the way down: Zero trust, Zero observability, Zero debug :clap:

1 Like

Hi everyone - this feature is available on the Teams Free plan with no constraints. The feature relies on the ability to use Gateway’s HTTP proxy, which is free for up to 50 users - you’ll need to go into Gateway / Policies / Settings and enable the proxy and inspection. Let me know where you’re seeing issues or constraints, but should not be any issues related to plan type.

1 Like

Does this mean that for this to work it’s not enough to install WARP client, but you have to deploy and trust Gateway’s CA certificate on each and every device that should have access? (I do understand that services on private ranges will work without the cert, but the rest of the Internet apparently won’t.)

Isn’t this supposed to be more convenient than corporate VPN solutions?


It would be nice to update the tutorial to reflect this requirement.

1 Like

It seems it is not possible to use this feature with the iOS WARP client at the moment. It appears to have hard-coded split-tunnel ranges that are NOT impacted by the Gateway policies set in the dashboard.

I have removed 10.0.0.0/8 from the dashboard, however, after re-installing the WARP client (as well as logging out and in/resetting all settings), the 10.0.0.0/8 network range is still set as a split tunnel. And connections to IPs within that range do not work.

Any ideas when this will be resolved?

1 Like

Cloudflare Gateway with HTTP filtering is essentially a Secure Web Gateway (SWG). SWG is different from your traditional VPN, where SWG will actually decrypt users’ HTTPS traffic, inspect it (check whether the website is allowed/blocked), and then re-encrypt again and send it back to the server. Traditional VPN won’t decrypt HTTPS (or any SSL traffic) between user and server, hence the reason why we don’t have to install any CA cert in the users’ machine.

1 Like

Thanks @erictung.

@MaximGashkov - to add one note, you can configure Gateway in a mode where no traffic is inspected (by adding a rule that excludes all destinations from inspection), but it this feature is built as part of the wider SWG and ZTNA set, not purely standalone - at least not yet.

2 Likes