Cloudflare for Teams on Private Networks

Zero Trust Gateway
,
1

Hi, I am configuring Cloudflare for Teams Warp to allow routing traffic to internal networks.
I’ve already configured cloudflared to route those internal networks.
The goal is to allow users using Cloudflare Warp access resources from internal networks.
To allow users to resolve internal domains I’ve configured override rules.
Example:
sampledomain.dev translates to IP 10.168.1.1
Those rules works however there’s a situation, sampledomain.dev uses a self signed certificate and when I attempt to access that domain it shows an error Insecure upstream. I’ve already installed the self signed certificate authority on the server running cloudflared.
Also, enabled the following options in the config.yml

no-tls-verify: true

Troubleshooting · Cloudflare Zero Trust docs.

I’ve also enabled debug logs, here’s an excerpt:

Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG tunnel to origin copy: readfrom tcp 10.168.1.254:33218->10.168.1.1:443: stream error: stream ID 23; CANCEL
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG Status: 101 Switching Protocols served by ingress warp-routing
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG CF-RAY:  Response Headers map[]
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG CF-RAY:  Response content length unknown
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG origin to tunnel copy: read tcp 10.168.1.254:33218->10.168.1.1:443: use of closed network connection
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG tunnel to origin copy: readfrom tcp 10.168.1.254:33220->10.168.1.1:443: stream error: stream ID 25; CANCEL
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG Status: 101 Switching Protocols served by ingress warp-routing
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG CF-RAY:  Response Headers map[]
Jul 20 09:45:32 CLOUDFLARED-SERVER-01 cloudflared[3749]: 2021-07-20T09:45:32Z DBG CF-RAY:  Response content length unknown

Is there a solution for this matter?
Thanks!

2

That’s a very interesting question.

First off, the no-tls-verify option does nothing in this case, as it’s used for service’s origins, when they are connected to the Tunnel, via cloudflared.

The error that shows is in the Cloudflare Gateway style, right? Another issue, .dev is a preloaded TLD, so it requires a valid certificate regardless of Cloudflare for Teams.

I would suggest solving it in a much easier way as I doubt, if you use the TLS decryption, it can even work, just add a valid certificate or connect that domain to Tunnel itself and access it via that.

3

Hi @matteo. Thanks for your reply. Yes, the error shows in the Cloudflare Gateway style just like the docs.
For now I’ve tested two things, using a .corp TLD and disable http to https in the Traefik (used as reverse proxy) and still no results. I might attempt to disable https at all in the reverse proxy and see the results. Can you specify more about the TLS decryption part?
Thanks!

4

That is by default split in Teams, you need to remove it in the dashboard.

By default Cloudflare Zero Trust decrypts TLS traffic, meaning you see a Gateway certificate for every domain and the origin connection is done by Cloudflare, just like if it was proxied in Cloudflare. As far as I know you can’t disable certificate check in this step. You might want to try with a Do Not Inspect rule…

Can you actually reach the network from Warp? Have you removed the private network of interest from the exclusion list?

5

I did already removed .corp TLD from the dashboard and I can reach the services properly (I did removed the private network addresses from the list also). I am already using Warp for SSH into the private network and I can access directly the IP address of the reverse proxy (inside the private network also) via Browser and it responds.
About the “Do Not Inspect Rule”, I attempt to configure it however no results so far. I attempted to create a rule matching a list of hosts and also a rule matching my own email address with the “Do Not Inspect Rule” enabled but so far no results.

6

Does this work when you are on the local network with this server w/o Warp involved? Assuming it does.

Create a https rule for host is sampledomain.dev → Action Do Not Inspect.

1 Like
7

Hi @cs-cf. It already works without the Warp involved. Currently I am trying to replace a legacy VPN with Cloudflare for Teams for accessing internal resources, mainly development environments.
The only problem that I am facing is dealing with the internal self signed certificates. I can access all the hosts (via ip address) that I exposed and they work without a problem.
Here’s the rule that I created (The domain in the screenshot doesn’t represent the real domain, omitted for security purposes)

image
image2520×1494 157 KB

Currently I am fetching the cloudflared repository and attempt to add some more verbosity, upload the custom binary to the server and try to find if I can find a way to shortcut this problem.

8

For some reason it started working. I will test on different computers also with different accounts.
Now it goes directly to the service and the browser exposes the certificate signed by my organization that’s installed on my machine, looks good!
Don’t understand why it started working, maybe because I restarted the cloudflared service on the server?
I will keep trying different policies and see the results

9

Is this the first rule in your http(s) rules list? Asking just to make sure another rule isn’t taking priority / precedence.