Browser based RDP sessions not launching via WebUI

Good Afternoon @jm2 ,

Thank you for bringing this issue to our attention. I will open a ticket to investigate this behavior. I will keep you updated as soon as I have an update on this.


Regards

Hello @jm2,

Could you please provide the PAM and Gateway services logs please.
Best,

Hi Yevgeniy,

Thanks for assisting with this. Further investigation identified that the issue was being caused by WAF policies in Cloudflare which proxies the gateway traffic.

The browser based sessions were working with the existing WAF policies prior to a recent release, so perhaps something may have changed so that now when a user launches a browser rdp session it immediately upgrades to a websocket without sending any preliminary https requests. The absence of the initial https request to the gateway fqdn from the client inhibits the ability for cloudflare to enforce pre-authentication on the connection before it upgrades to websocket. Is it possible to restore that preliminary https request to the gateway before upgrading to websocket?

Please let me know if you would like any additional info.

Thanks
Joe

Hello @jm2,

Our team is currently investigating this issue. Thank you for the additional investigation on your end. We will keep you posted if there are any updates or if we need more information.

Have a good day.
Best regards,

Hi Yevgeniy,

Wondering if there was any update on this one?

Thanks
Joe

Hello @jm2,

This issue was investigated by one of my colleagues. I am waiting for their response to see the result of the investigation.

Thank you for your understanding.

Hi @jm2,
Sorry for the delay. After further internal discussion and investigation, we largely agree with your diagnosis.
In an earlier update, we moved the browser-side Gateway preflight request to the PAM service for security reasons. As a result, the browser now connects directly to /jet/rdp without first sending a standard HTTPS request to the Gateway FQDN.
There is one experiment you can try:

1. Using the same browser, edit the affected entry and open VPN/SSH/Gateway.
2. Click Check Health and confirm that it succeeds.
3. Without closing the browser or clearing its cookies, immediately launch the entry using Open in Web.
4. Let us know whether the session launches successfully.

If this works, it would strongly support the theory that the preliminary HTTPS request establishes the Cloudflare pre-authentication state required by the subsequent WebSocket connection.
Regardless of whether the experiment succeeds or fails, could you please send us the following information from the same time window?

1. A HAR capture starting before Check Health and ending after the launch attempt. Please ensure it includes:
   • /jet/health
   • /jet/rdp
   • Response headers
   • Timestamps
   • Cloudflare Ray IDs
2. Gateway TRACE logs.
3. The exact Gateway node and version.
4. A packet capture from the Gateway host.
5. The Cloudflare Security or Firewall Events associated with the Ray IDs.

Please also confirm:

• Whether the entry uses a virtual or physical Gateway
• The last known successful date
• The first known failure date

These files may contain cookies, tokens, or internal hostnames. Please redact sensitive information while preserving timestamps and correlation IDs. Do not post the raw files publicly.
Please reach out to us so that we can arrange a secure upload method.
Best regards,

Hi @oujunyiirving ,

Thanks for assisting with this.

Preauth is currently disabled for /jet/health and /jet/diagnostics/logs, so the health check works ok. Ideally these urls could also be protected by Cloudflare Access pre-auth, but I imagine that would require hub/cloud to support using a static authorization token in order for the platform to independently monitor gateway status.

The browser based RDP sessions launch fine if /jet/rdp is also excluded from pre-auth, but not when its enabled. Browser developer mode trace shows that /jet/rdp connection is initiated via wss:// connection which doesn't succeed because pre-emptive https:// connection hasn't occurred.

I don't know when specifically, the issue started to occur, but it was working with pre-auth enabled for /jet/rdp a few months ago.

Could hub/cloud be updated to do a simple GET https://gateway.domain.tld/jet/rdp call (or something equivalent) prior to upgrading to wss://, which will inherently trigger the pre-auth process?

If a HAR file is required for further analysis, please DM an upload link, but not sure it should be necessary since its already confirmed recent change resulted in browser making direct websocket connection to /jet/rdp, and google search (shown below) indicates that beforehand browser needs to obtain CF_Authorization cookie.

Please let me know if you would like any additional information.

Thanks
Joe

Hey @jm2

Nice — that exclude-vs-enable test nails it. Matches what I saw in the code: browser jumps straight to wss://…/jet/rdp with no HTTPS first, so it never grabs the CF_Authorization cookie before Cloudflare sees the socket.

Your GET-before-upgrade idea is the right call. Taking it to the Hub/Cloud team. Skip the HAR for now.

Quick one — is the Gateway on that entry virtual or physical? Trying to match "worked a few months ago" to a build.

Thanks
Irving

Sounds good, thanks @oujunyiirving.

The gateways are non-virtual, and as far as I recall the last time I tested that it was working was with one of the 2026.1.x releases

Joe