Cloudflare's standard proxy service only supports HTTP/HTTPS-based traffic and does not inspect or protect native RDP traffic. Since RemoteApp uses the native RDP protocol, enabling the standard Cloudflare proxy prevents the connection from being established. This is why HTML5 access continues to work while RemoteApp connections fail.
If you want to keep Cloudflare enabled while allowing RemoteApp connections, we recommend configuring TSplus Remote Desktop Gateway (RDG), which tunnels RDP traffic over HTTPS.
When configuring RD Gateway, please ensure that the following requirements are met :
- A valid DNS record must point to your TSplus server, and a trusted SSL certificate matching this DNS name must be installed and bound to Terminal Services. Self-signed, expired, or mismatched certificates will cause RDG connections to fail.
- TLS 1.2 must be enabled in AdminTool\WEB\HTTPS.
- If using RemoteApp through the web portal, enable "remoteapp2_useasrdg" in "C:\Program Files (x86)\TSplus\Clients\www\software\remoteapp2.js" to force RemoteApp sessions through RD Gateway.
- If .connect files are used, regenerate them with the option "Use the targeted server as a Remote Desktop Gateway (RDG) to encrypt data transfer" enabled.
- If RDP forwarding is disabled on the web ports, configure the following settings in "C:\Program Files (x86)\TSplus\Clients\webserver\ settings.bin" and restart the TSplus web server :
disable_rdp=true
avoid_disable_rule_of_local_rdp_on_rdg=true
In a farm environment, ensure that all servers share the same SSL certificate and that application servers are configured to use their RDP ports rather than web ports for RDG communications.
Since you are using Cloudflare, please also verify that your Cloudflare configuration supports RD Gateway traffic. You will need to ensure that Cloudflare allows the HTTP methods required by the RD Gateway protocol ("RDG_OUT_DATA" and "RDG_IN_DATA"). Otherwise, RDG connections may still fail even though HTTPS access is working.
If these prerequisites are not met, users may experience protocol errors or connection failures when attempting to establish RemoteApp sessions through Cloudflare.
Here are links to articles that will provide you with more details :
https://support.tsplus.net/a/solutions/articles/44001910887?lang=en
https://support.tsplus.net/a/solutions/articles/44002610364?lang=en
However, using RD Gateway may allow RemoteApp connections to work through Cloudflare, but Cloudflare WAF protection will only apply to the HTTP/HTTPS layer. A WAF can inspect the web layer, but not the underlying RDP protocol unless it is exposed as HTTP/WebSocket traffic that Cloudflare can actually understand.
If you require Cloudflare protection specifically for RDP traffic, you should consider using Cloudflare Spectrum or Cloudflare Zero Trust.
However, while RD Gateway allows RemoteApp connections to work through Cloudflare, it is important to understand what Cloudflare can and cannot protect in this configuration. Since RDG encapsulates RDP traffic inside HTTPS, Cloudflare WAF will apply to the HTTP transport layer, it can inspect request headers, URIs, and HTTP methods, and block malformed or abusive requests at that level. What it cannot do is inspect the RDP payload itself, as Cloudflare has no visibility into the protocol running inside the tunnel.
If you require deeper protection for RDP traffic, you should consider the following Cloudflare options :
- Cloudflare Spectrum extends Cloudflare's DDoS protection and IP proxying to raw TCP traffic, including native RDP. This allows you to keep RDP exposed without Cloudflare proxy blocking it, while still benefiting from network-level protection.
- Cloudflare Zero Trust (Access + WARP) takes a fundamentally different approach : rather than exposing RDP publicly at all, it routes remote desktop connections through an encrypted Cloudflare tunnel, enforcing identity-based access policies before any connection is established. This eliminates the exposed attack surface entirely.