Support - I don't know what to do

I’ve been trying to get help from support since last Thurdsay. I’ve even upgraded my account so I could get email support. I’m confident I’m so close to this working, the tunnel is installed and active, HTTP2 is enabled, the CNAME points to the ID (although, I’ve also read the IP address should be set), I’ve got warp-routing enabled in the yml file, WARP is installed on the pc and it is logged in to our team.

But the end result doesn’t work. The pc doesn’t get an ip from the range.

Honestly, I’m really frustrated. I feel like I’m so close to this working, I just need someone who knows how it should be setup to help me out.

Thank you

Can you walk us through whats wrong? What’s your setup?

The PC doesn’t get an IP from the range… I saw the previous post you had and mentioned that there too. That isn’t what Warp does, so I am confused.

What specifically are you trying to achieve?

I’m trying to put Cloudflare between the outside world and our remote desktop. Right now we connect through the standard Server 2016 gateway, which works fine, but we need to add more security to this. So, I need Cloudflare to establish a tunnel between the server and the user pc. Like a VPN, but without the downsides of a VPN. My understanding was then that I could connect to the remote desktop as if I was connected to a pc locally on our network. I thought that was the point of seting the ip address range when setting up the tunnel. If that isn’t the case, then that is fine, but I though the Zero Trust could be used like a VPN.

Am I incorrect?

Thank you so much!

I was also reading this article about installing Cloudflare.exe on the pc trying to connect remotely, but when I run the exe file it just opens a command prompt window and does nothing. It doesn’t create a folder on the C drive or appear to install anything. Is this different than WARP?

Thank you

This is what I’m trying to achieve.

Sorry for the delay (real life intrudes sometimes).


So, I’ll try to break this down into testable parts from the processes I’ve used in the past when troubleshooting Teams/One/ZeroTrust/WhatAreWeCallingItThisWeek deployments.

Assumptions I am going to make, you are using the default config (include everything but private networks by default) and that things are running on ‘normal’ ports.

  1. We’ve got a server (A) we want to install cloudflared on to provide access to one or more applications internally. We want to start with RDP access to a server (B).
  • Ensure we can telnet from A to B on port 3389 using the IP address of B.
  • Ensure we can telnet from A to B on port 3389 using the FQDN for B (that FQDN can be or we’re just not using netbios names here because netbios and the internet don’t get along).
  1. We configure cloudflared with a YML file that supports Warp to tunnel (e.g.)
tunnel: 8e343b13-a087-48ea-825f-9783931ff2a5
credentials-file: /root/.cloudflared/8e343b13-a087-48ea-825f-9783931ff2a5.json
  enabled: true

I’d personally add (maybe in a better location I knew was writable than the root drive):

loglevel: debug
logfile: C:\tunneldebug.log

Configuring it as a service is harder than it needs to be, but I think this is accurate … copy paste/follow all steps carefully:

  1. Expose the CIDR range. So you can add the entire network, or you could just add this particular host. There’s a whole level of ‘what should I expose when and what network rules should I use’ that becomes a consulting level question so I am going to skip it… mostly.

But you’ve exposed your CIDR range for the tunnel and restarted the service afterwards.

  1. Remove the private network from the Cloudflare dashboard (by default private networks are routed locally, we want to send the traffic through Warp to Cloudflare’s edge.

  2. Make sure the Cloudflare client cert is installed.

  3. Enable the Cloudflare proxy AND TLS decryption.

Wait 5-10 mins for propagation changes. Restart the Warp client that you’ve signed into your teams instance (probably not necessary but eh…)

Telnet by (private IP address that you tested above to the host in question) on port 3389 it should connect.
Try by FQDN it should connect. If Ip connects and name doesn’t you have a name resolution issue… so that may be resolved in a number of ways, but for the moment you could modify your host file and confirm that you can then connect by FQDN.

Stopping there to see what works/doesn’t as the troubleshooting tree grows significantly from there.

1 Like

I completely understand. Thank you so much, I’m going to try this all right now.

So, right now, I’ve got Cloudflare on the server that is our remote desktop computer. It can currently be reached through or by using the Gateway setting in windows remote desktop client. We have also a server that acts as our domain controller, would that be a better place to install cloudfare?

Again, thank you so so much for your help.

1 Like

So, I can successfully telnet from our domain controller to the remote desktop server (where Cloudflare is currently).

I’ve started the tunnel and have the logfile if need be.

I have a question about the DNS and applications.

Firstly, should the CNAME point to OR to the external IP where the server is located?

Secondly, do I need to setup a Self-Hosted application that uses the same name as the CNAME? Or is the tunnel enough?

Thanks again,

Neither? It should point to the same IP you confirmed you can telnet to, which should be the same IP address (CIDR) that you are allowing with the route add command.

No, you’re mixing modes in this instance. You’d (eventually) potentially put a network policy in place to lock down which of your users logged into your team can access resources on the CIDR range(s) you’re exposing.

So you confirm, the CNAME should point to the internal ip address where cloudlare is running?

{redacted} | Operations Manager

Also, does it matter what the cname is called?



Generally it shouldn’t matter what it is called as long as it would work when you’re connecting from the same machine that is running the tunnel (or another machine on the internal network).

The DNS record should resolve to the host you want to connect to (so if I have server A running the tunnel and server B has the RDP server, you want to point to the IP at server B with the DNS record).

If I try to put the local IP address I get this error: DNS Validation Error (Code: 1004) Content for CNAME record is invalid.

If you’re pointing to an IP you’ll want to use an A record instead of a CNAME.

Get this error DNS Validation Error (Code: 1004) This record type cannot be proxied.

Yes sorry for got to mention it should be set to DNS only regardless of whether it is a public or private IP as the client is going to resolve to the real address.

Okay, some progress I think. I can telnet to the ip addres at 3389, but not the FQDN. Also this happens in the logs

2022-03-10T16:49:58Z DBG rpcconnect: tx (finish = (questionId = 0, releaseResultCaps = false))

2022-03-10T16:49:58Z DBG rpcconnect: rx (return = (answerId = 1, releaseParamCaps = false, results = (content = , capTable = )))

2022-03-10T16:49:58Z INF Connection 5824469b-b5fe-452b-91c6-d2026c1484be registered connIndex=3 location=MSP

2022-03-10T16:49:58Z DBG rpcconnect: tx (finish = (questionId = 1, releaseResultCaps = false))

2022-03-10T16:52:01Z DBG tunnel->origin copy: readfrom tcp> stream error: stream ID 3; CANCEL

2022-03-10T16:52:01Z DBG origin->tunnel copy: read tcp> use of closed network connection

Thank you!

Ok so now it’s a name resolution question (probably). On the client running warp if you open a command line tool and do a dig or nslookup for the hostname in question is it resolving to (to confirm… it looks like you are running the cloudflared client on the same machine that you’re trying to RDP to correct?)

Yes, cloudflared client is on the same machine as the RDP. So, yes the

The nslookup on the WARP machine returns:


Address: can’t find 10.1.40: non-existent domain