Using Cloudflare proxy with ManageEngine DesktopCentral

Hello Community !

I have a question about CloudFlare proxy
I saw that the list of HTTPS network ports compatible with Cloudflare’s proxy are the following :

  • 443
  • 2053
  • 2083
  • 2087
  • 2096
  • 8443

Do you know any limitation from CloudFlare’s proxy if I try to use ManageEngine DesktopCentral agents using some of theses ports to communicate with my DesktopCentral Server (which already uses CloudFlare DNS) ?

Thank you !

From me being curious, as I am not familiar with this app, may I ask is it more similar to Zabbix, or rather more like TeamViewer / AnyDesk?

I think, from my understanding, except the Cloudflare plan you are using, it could be:

  • maximum upload filesize limit (100MB)
  • request timeout limit for HTTP(S) request (100s)

Which service? UDP / TCP (HTTPS), WebSockets or?

Are you also going to use Cloudflare WARP or Teams / Gateway or not?

1 Like

I am not familiar with Zabbix neither, but from my researches it is a little bit similar
DesktopCentral is an ITAM solution to manage all my IT infrastructure, from software deployement and patch management to remote control

My server DNS is not actually administrated by this CloudFlare account, it has a Cloudflare Pro plan

Are the limitations the same ?

It uses TCP (HTTPS) and WebSockets, depending on the tool

For example, I belive that the Chat tool uses a WebSocket
However, basic agent communication with the server uses HTTPS

I am not very familiar with all Cloudlare solutions, so I do not plan to use any of these for now (besides from maybe Cloudflare WAF)
However as I continue to discover all Cloudflare product, it may change in the future

Thank you for your help !

It sounds like it can be proxied (ports & protocol). Have you tried?

It doesn’t sound like there would be much traffic. If so, then it’s highly unlikely it’d be flagged for excessive non-website traffic (ToS 2.8)

1 Like

Yes I have tried, and unfortunately when I activate Cloudflare proxy, all my agent are reported down on my server

I also think it can be, so I believe it must be an issue with DesktopCentral server directly
I will reach with their support to try to solve the issue

If you can confirm they only use the ports from that list, that would help.

Can you also double check the Network tab for your domain at and make sure Websockets is enabled?

Consider using a WARP tunnel for DesktopCentral. Works like a charm.

Well I can actually specify which ports the server use to communicate with the agent, so I assigned the ports 443, 2087, 2053 and 2096 which are all in the HTTPS supported by Cloudflare ports list.

I don’t have access to the account that manage my server right now, but I will double check as soon as I can and get back to the topic.

I’ll try, I do not know how it work, nor what it is, but I will do my researches, thanks !

1 Like

So I did some researches about WARP, and if I understand well it is pretty much Cloudflare VPN right ?
As one of my end goal is to use Cloudflare WAF, I saw that you first need to use Cloudflare Proxy, but can I use Cloudflare Proxy with WARP ?

Also, I’ll then need to install WARP on every computer that run my agent, won’t I ?

Cloudflared really isn’t a VPN, and WARP isn’t a requirement to use Cloudflared.

It’s more of a tunnel from your server into Cloudflare. It replaces Cloudflare’s standard browser-like requests to the origin to proxy that to visitors.

Again, WARP isn’t required, and since you’re using standard ports using HTTP/S, you don’t need any special setup at the client end.

1 Like

Oh ok, thank you for the explanation !

What are the advantages of using the tunnel instead of Cloudflare’s standard browser-like requests ?

Does it replace Cloudflare’s proxy ? Or is it the same thing ?

There are two advantages, neither of which probably apply to most people:

  1. It can portmap. For example, I use Ghost, but it uses a custom port and generally requires a reverse proxy in front of it, like NGINX. With Cloudflared, I can have the tunnel connect directly to Ghost, yet respond on Port 443 at the Edge.
  2. I can firewall off all external access to my server since Cloudflared is initiating the connection to my local Cloudflare POPs. No inbound connections required.

It replaces the origin connection. Excuse my crude drawing, but I circled the typical Cloudflare-initiated connection to the origin and replaced it with a server-initiated connection to Cloudflare via cloudflared.


I should have been more clear on why I chose to go with the WARP client/tunnel in our Manage Engine/Desktop Central scenario - we are dropping our ancient Cisco VPN solution (no slight to Cisco, their product is amazingly stable) for a more flexible solution due to the company’s move to support WFH more broadly.

We still utilize classic, locally hosted file sharing in our data centers around the world, so while Cloudflare’s WAF is great for web applications, we still rely on classic VPN for access to internal resources that are not web connected. Not to mention, we also have mesh ipsec tunnels between our sites as well.

As for Manage Engine’s Desktop Central, it works amazingly well over internal networks/ipsec tunnels. In addition to the main DC server we have 6 DC distribution servers handling over 10k clients. On the internal network there are zero issues getting timely updates and new configurations thanks to the distribution servers. Once a machine leaves the network, this is where the problems start - especially if you have a lot of machines.

MangeEngine provides a “Secure Gateway Server” for Desktop Central, that already acts like a reverse proxy. It’s the best way to secure your main DC server without exposing all ports. It’s actually the correct answer here as what you want to put behind WAF - not the DC server itself. (this way you only need to expose a single port, not all). More information here: Link

However - and this is why I recommend the tunnel - the “Secure Gateway Server” for Desktop Central was designed for a small remote workforce. The implementation was never intended to cover a large use case as it completely ignores the use of Desktop Central distribution servers. When COVID hit, within 2 weeks, most of the 10,000 internal machines became remote workers and we had several issues with the Secure Gateway Server being overloaded. Not to mention, the geographical issue of clients in different countries getting updates from our main DC server in the UK. Our infrastructure was not originally designed to handle this, let alone redirecting thousands of clients through one endpoint.

For one, without a VPN connection the Desktop Central agent will not be able to talk to any of the servers (distribution or main) without a hole punched in our firewall - and a prolonged disconnect on the agent causes significant delays in configuration changes in the long run.

Since we need access to internal resources anyways (AD authentication, classic file sharing and other non web based apps), the WARP tunnel serves as a great tool to access all of our Desktop Central distribution servers and main server on top of being a great replacement for Cisco.


So if I understand well, your whole infrastructure looks like something like this ?

(I draw a lot to understand better :sweat_smile:)

My issue was still that my agents could not communicate with the DC Server with Cloudflare’s Proxy, and I don’t think that adding the WARP in this configuration would solve my communication problem, same as adding a secure gateway.

What is your DC server port configuration to make it work with CloudFlare’s Proxy ?

Right now, the network architecture I am trying to achieve to begin is something like this :

Hi @RaphaelVI

Yes, similar setup, except the distribution servers are not on my clients networks but rather in co-location centers in 3 countries. Before COVID we would have IPsec tunnels running from these co-locations into our client sites as all of their desktops would never leave their building. After COVID, when all of the workforce went to work from home - we needed a better solution as the Secure Gateway could not handle the load of all the agents. Distribution servers cannot live outside of the secure gateway - they need a direct connection to the DC server.

The WARP client allowed us to extend the distribution server network to all of the machines without worrying about VPN as well as setup strict firewall policies.

1 Like

Thank you for your answer !

I do understand the added value of the WARP client, yet I believe that in my case it is not an issue for the moment, as the workforce I am trying to manage is rather small ( at best 50 computers for now, all in the same country )
I will keep the WARP option as it will be a great solution when the workforce will increase in size.

However, I still don’t know how to solve the fact that, when trying to activate CloudFlare proxy on my DC Server and switching all its ports to supported CloudFlare ports, my agents are not able to communicate with him anymore
Do you have any advice for it ?

You really need to consider the Secure Gateway that is designed for this exact purpose.

1 Like

You are right, I should implement it in the begining, as I intend to do it at some point anyway
However, the purpose of using Cloudflare proxy is to first of course, secure my DC server, but one of my concern is about web certificates

With CloudFlare proxy, I do not have to renew any certificate for my DC server as it uses CloudFlare’s, which is an issue not solveable by the secure gateway
I tried to use LetsEncrypt to auto-generate it, however after some exchanges with DC Support, it is not possible to automaticaly add a certificate to my DC server, I need to upload it by hand in the web console

My goal is to never have to put any certificate manually to my DC server, as I believe that this should not be something someone has to do by hand in 2022
This is why I am trying to use CloudFlare proxy on my DC server ( or my secure gateway, but I believe I would encounter the same issue )

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.