So it looks good: Using Cloudflare Tunnel and WARP to allow zero trust, VPN-like access to an internal network, but I’m not an idiot, and I’ve spent hours going through the documentation, and I cannot make this work.
On Server:
cloudflared tunnel create example.local
cloudflared tunnel route ip add 192.168.1.0/24 example.local
cloudflared tunnel --config C:\xxx\config.yaml run example.local
In Cloudflare Teams
Set up device registration, email ends in @company.com
Set up Gateway → Policies → Split Tunnelling to remove 192.168.1.0/24
Set up Gateway → Policies → Network with a Disable Rule and Enable rule as per CF documentation, which, by the way, indicated that you should put a block rule before the allow rule, aren’t the rules processed in order? At no point does the documentation discuss multi-rule processing. Either way, it doesn’t work with either rule first: Configure Zero Trust Network Access in Cloudflare Zero Trust · Cloudflare Zero Trust docs
(Also, the regex described in the tutorial is not valid regex, also the GUI doesn’t auto-fill group names or IDs, which is very awkward, nor does it explain how to list multiple entries in the field).
On Client Desktop
Install Warp
Warp → Preferences → Account → Sign into Cloudflare Teams
Ping a host on the remote local network, and it’s a no-show.
What am I missing here, because this is the second day I’ve spend 4 hours on this, reading all the documentation carefully, and I cannot figure out how to make this work.
At this point I would be very happy to pay someone to go through my setup with me and show me where I’m going wrong, but CF support is really bad below the Business plan.
FYI, it needs to be a full TCP VPN style solution because the applications the team needs use a combination of SMB, SQL, and proprietary connections on different ports, it’s not something I can just proxy one or two ports/services.
My Problems:
a) As per documentation, CF only forwards TCP, so testing connections with Ping (ICMP) is pointless, my fault.
b) I stupidly was pointing to my config.yaml when it was actually config.yml
CF’s Problems:
Seems like Warp enabled tunnels (or maybe just new named tunnels?) are not appearing in Traffic → Cloudflare Tunnel . Very confusing.
CF Documentation says to create a block all rule, then an allow rule, which leaves the rules in the wrong order. They forget to mention rule processing order in any of their documentation.
Any anyway, if you want to allow all your user’s access, you don’t need to set any rules.
no-tls-verify: true is ignored when Teams → Gateway → Policies → Settings → TLS Decrypt is enabled, and this causes CF to prevent accessing internal services with self signed or local certificates. I get that there are two different inspections here, with this switch affecting cloudflared.exe and not the Gateway TLS inspection, but it’s annoying anyway.
Teams → Gateway → Policies → Settings → Proxy Settings - Enable HTTP Traffic Filtering. This is an awful name for a setting that controls all TCP filtering. It also doesn’t mention in the documentation that you need to enable this (disabled by default).
The introductory documentation is missing the entire “Configure Network and Settings Tabs in Teams Gateway” section. It’s an entire step missed.
Alright, so now my new problem. In a traditional VPN, it will forward DNS lookups to the DNS server on the Private Network, making it easy to connect to private services run therein.
WARP forwarded all non-excluded DNS lookups to 1.1.1.1, which will only support real addresses (no .local).
All the excluded DNS lookups (such as .local) and sent to the local machine’s default DNS, not the DNS server on the Private Network. The local machine, not currently being directly on the Private Network, obviously can’t resolve the .local addresses.
Any ideas?
I could create some real server names: server1.company.com and point them to local addresses: 192.168.x.x, and that does work. However some of these legacy applications hard-code their server names upon installation (ie from the installation source) which was server1.local.
I’m not sure I can change these retrospectively, and would rather just resolve the existing names. At present, the only thing I can think of is hosts file entries, which is horrible.
What would be fantastic, is if the WARP client had a section for “Static DNS” where we could enter names and IP addresses into the Teams console, and they would push to all the clients, for static name resolution, that overwrote the “Local Domains” list. It could be part of the Local Domains feature.
Thanks for all of the feedback here - we’ll definitely make sure we address the issues in the documentation - should you be inclined, you can submit PRs on github for any of our docs including the tutorial:
I wanted to test this myself and I ran into one possible issue which is that my Warp device doesn’t seem to be inheriting the “Split Tunnel” config from my Teams account.
Can you check on your Warp client whether the (lack of) split tunnel config for 192.168.1.0/24 made it to your client desktop? That could be the source of the issue if you’re hitting the same snag that I did.
This is likely the problem: ping uses ICMP, but WARP to Cloudflared Tunnel supports TCP only. Ping won’t work over this “VPN replacement”, at least not yet with the current support.
You can try netcat - Wikipedia or equivalent in your OS (where you installed WARP) to check it out.
A second note (mentioned by Simon) is that the Split Tunnel seems to not work in all OS — I’m not fully knowledgeable, but I think there’s an open bug being addressed where Android (and iOS I think) are not respecting the Split Tunnel config all the time.
But otherwise, if you use WARP in a desktop/laptop, it should be good based on my experience.
Finally, the remark about DNS management is extremely well put. We had that in our radar since day one and I’m sure it will get better support over time. It’s just a matter of getting something out first step by step.
Until then, you can use Gateway DNS rules to create overrides. That way, your WARP traffic will send the DNS requests to our edge and it will resolve your private names to your private IPs.
Check it out at Resolve internal hostnames with Cloudflare for Teams
OK more updates. @simon Sorry, I’m not going through your documentation and updating it, it’s in too poor condition. There are cloudflared.exe config switches referenced in the tutorials which are not referenced in the cloudflared.exe list of config switches. The tutorials often only give half the picture, and the main documentation gives another 45%, and then there’s 5% just undocumented. I get that the CF products are priced incredibly competitively, but I’m not doing your documentation for you unless someone spends the same amount of time doing my VPN. Also, a post I made to this forum has gone into ‘spam review’ which had 3 or 4 links to errors or omissions in the documentation.
@nuno.diegues Yep, the Split Tunnelling settings are propagating to my Windows WARP clients pretty quickly (less than 60 seconds) so happy there.
What’s not working for me is the DNS (New) Policies, which I did discover after I made the last post, but I cannot get them to overwrite for local names.
In Teams → Configuration → Lists I’ve created a list call local servers, where I have:
Server1
Server1.domain.local
domain.local
In Teams → Gateway → Policies → DNS (New) I have two policies:
Domain → In List → Override with 192.168.1.x
Host → In List → Override with 192.168.1.x
It’s not quite working. It will resolve server1.domain.local but I also need it to resolve server1
Lastly, I uploaded my Teams plan to get 24/7/365 Support Chat, but cannot find the chat option anywhere.
Alright, think I found the problem. Even through I’m doing a DNS lookup on server1, and there are no suffixes set up in my TCP/IP settings, for some reason, either Windows or WARP is adding .mshome.net to the lookup name. Adding server1.mshome.net to my Domain Hosts list fixed lookups for just server1.
@dom5 no problem re: the docs - the tools are there to modify them if you’re that way inclined but I am going to raise the feedback internally for all of the points you’ve raised. Re: the command switches for cloudflared.exe if you have any specific examples, feel free to send these to me.
For the chat support - that should be entitled automatically - I don’t see a subscription for Teams against your account so I’ll message you directly to get more information.
a) Still haven’t got live chat in the Teams console. No idea where I’m even looking for it.
b) I believe I have the correct config.yml for running both Warp Routing and RDP Proxying, but can’t test it, because I’m not getting 2FA emails from CloudFlare right now. I’ve tried 4 times over a period of an hour, the emails I always get are just not arriving.
c) Can’t get Cloudflared.exe to run as a service. It will install, it finds the config file I’m using when I run it as a command line, it doesn’t log anything in the log file, even with log level debug. In event viewer is just states that it’s starting, and that’s it. cloudflared.exe starts for a second and then closes again. No crash logs in Windows.
This is exhausting. Wish you guys would stop racing unfinished products to market and concentrate on fixing issues with the products you have.
OK, so I found the fix for (b), I have multiple groups of users and hadn’t applied the test group to the application. However, this is still a CloudFlare bug, because when a user does not have permissions to access a resource, CF should finish the 2FA, and then say “Access Denied”. At present, it just doesn’t send the email for 2FA. This needs to be fixed.
I’ll try it on Friday but we didn’t have to specify that previously, what other commands other than tunnel run is the service going to do? Or are you enabling access as a service?
Plus my config file is in the default service location, so shouldn’t need specifying.
This highlights another issue with your documentation:
It says to install the service, and that the config file should be in the default location.
Optional Step 2, if you want to specify a location, it explains how to do so in the registry.
Then it jumps to configuring a tunnel. Why would you have that section in the bit about running as a service, when there’s a whole separate section for creating and configuring a tunnel. So most of us stop reading here.
Then under that, in “start the service”, and every network admin knows how to manage services, so we don’t read it, you have a section about configuring a service, that really needs to be done immediately after installing the service (in fact should probably be part of the command line or the default). So you have an addendum to “Install cloudflared” in the “Start the Service” section.
Then you have “Start on reboot” which goes on about editing the location of the cloudflared binary. How does this have anything to do with Start on Reboot? Further, Automatic is the default when it creates. Plus it creates the link to the binary in the service settings for the location of the binary when you use the binary to create the service in the first place. WTF?
Can you just hire an experience documentation person? It’s like someone who’s never used the product, has copied and pasted out of multiple documents.
“cloudflared tunnel run” — for named tunnels, recommended, and mandatory for WARP routing to tunnel
“cloudflared” (tunnel can be added, but it’s picked up from the config) — for legacy tunnels, not recommended
The service in Windows just installs as “cloudflared”, so you have to change it as noted on the docs that I linked above.
We have internal plans to improve the service command to make this configurable with subcommands or flags so that you can control which service is rendered to install.