Enable RDM to dynamically execute cloudflared.exe tunnel for Devolutions gateways

Hi Joe,

I agree with you, it would be a lot simpler if Cloudflare TCP tunnels didn't require running cloudflared.exe client-side. TCP tunnels are better handled by ngrok, where you can obtain an assigned TCP endpoint and port mapped to your service: https://ngrok.com/docs/universal-gateway/tcp/

The problem is ngrok pricing is fairly different from Cloudflare pricing, and depending on how many Devolutions Gateway instances you need, it can be a problem. If you have a small amount of them, ngrok could be a suitable option - TCP tunneling is much simpler, requiring no client-side executable.

TCP-based tunneling is required for RDP and SSH from RDM on desktop platforms, everything else is using a WebSocket transport. Our RDP and SSH web clients use WebSockets instead of TCP in the web for obvious reasons. The problem is that TCP is really the simplest and most efficient way to make things work in the desktop, especially with the first-party RDP client on Windows.

There are a few ways we could potentially solve this, all of which feel like a compromise with some drawbacks:

1) Make TCP tunneling optional from Devolutions Gateway, but this would require RDP and SSH in desktop platforms to go through a WebSocket tunnel that requires a client-side executable similar to an SSH tunnel.
2) Wrap cloudflared.exe launching from RDM and other places where it is needed, but as you mentioned, it gets tricky quite fast, and auth requiring user interaction is a problem making it unsuitable

If you stick to web-based clients, then TCP access is not needed with Devolutions Gateway. If we were to force WebSocket usage from RDM, it would work, but with degraded performance due to the additional overhead. I feel like maybe the option we'll end up taking is adding support for using WebSockets at all times, with the degraded performance that comes with it.

Let me know what you think, I'm open to suggestions

Hi Marc-André,

Thanks for giving this some consideration.

Any non-VPN solution that accommodates using RDM efficiently along with pre-authentication for internet traffic before it reaches the gateway would be fantastic.

Agree that nGrok is great, however to my knowledge it lacks capability to do pre-authentication for the TCP tunnel/s.

Knowing that some organizations have security concerns about systems being directly exposed to the internet without any form of pre-authentication, I see the Cloudflare solution having an advantage in that context, being an externally managed service providing perimeter security.

I think your on the right track with adding websocket support to RDM for the connection types you mentioned. Would be an appealing solution if that was able to be used with a gateway behind Azure App proxy with EntraID pre-auth enabled.

Please let me know if you would like more info.

Joe

Hi Marc-André,

Another option that may optimize both security and performance would be a capability similar to Citrix HDX Direct for external users (https://docs.citrix.com/en-us/citrix-daas/hdx-transport/hdx-direct). How that works in simplistic terms is to initially establish a connection via a sub optimal performance route (i.e. websocket via a 3rd party tunnel with pre-auth), and then seamlessly transfer the connection over to a dynamic UDP port (i.e. Devolutions gateway tells RDM its current public IP and a dynamic UDP port its listening on for that specific connection). With this approach there is no inbound static NAT required to the gateway, but direct UDP/TCP would be possible).

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

Joe

Hi Joe,

The UDP approach is not suitable for TCP-based protocols like RDP or SSH, and would therefore require some kind of client-side tunnel, and additional work on the Devolutions Gateway side. If we are to tunnel the TCP connection into another kind of transport, WebSockets would be the easiest to deal with.

Technically speaking, Devolutions Gateway always uses a form of pre-auth, even when exposed in passthrough mode to the Internet. You have to request just-in-time tokens from DVLS or Hub and present that token at the beginning of the connection with Devolutions Gateway. This also applies to TCP-based connections. There's no HTTP-based redirection for authentication, you just have to be authenticated with DVLS or Hub to initiate the connection and get the tokens dynamically.

With ngrok, you can get a publicly expose TCP hostname and port. Now the main difference is that since ngrok acts in passthrough mode, then random people on the Internet can try reaching it, but Devolutions Gateway will reject any connection that doesn't present a valid token. When pre-auth is integrated at the reverse proxy level, then the same kind of check is done before it reaches Devolutions Gateway, and you effectively get two separate levels pre-auth (for instance: one with Cloudflare, one with Devolutions Gateway). This is very difficult to do with TCP-based protocols because you can't just use HTTP headers and redirects to handle this.

This being said, Devolutions Gateway does pre-auth for both TCP and WSS transports. They are meant to be safely exposed to an untrusted network - you can't brute force them because it doesn't perform authentication by itself, it checks for tokens that have been pre-authenticated and signed by DVLS or Hub.

Let's say Cloudflare could be made to support the same thing as ngrok (publicly-exposed TCP hostname and port without a client-side executable), would this fit your needs? That's what I want to ask Cloudflare about to see if they can match the ngrok feature for TCP.

Best regards,

Hi Marc-André,

Thanks for the detailed explanations. While the just-in-time tokens do provide a security barrier to brute force authentication attacks, some organizations are likely to prefer a second layer of defense for the following reasons:
1) Should there ever be a zero day vulnerably that could be exploited via either the gateway software or underlying OS, an external perimeter security service could mitigate risk until patching can be implemented.
2) Some organizations require internet exposed systems to go through a cybersecurity review, and in certain cases there maybe a higher degree of comfort using a technology with wide brand recognition (i.e. Cloudflare) as a secondary defense mechanism.
3) The technical capabilities of a cloud hosted perimeter security service are likely to exceed any inherent capability of the on-premise gateway software. For example detection of suspicious connectivity attempts and any automated remediation workflow.
4) Unlike common web services hosted in a DMZ with a zero trust set of firewall rules, typically a gateway server will be granted broad access to internal network devices, which if it were compromised could result an attacker being able to target many internal systems for secondary vulnerabilities.

Regarding the HTTP redirection for pre-authentication, this is where the cloudflared.exe daemon is unique in that it automatically launches a browser and processes the authentication before allowing traffic at the underlying network protocol level.

Perhaps at some point RDM and/or gateway will have a HTTP redirection capability for supplementary pre-auth capabilities, but until then, maybe the simplest solution is a small degree of native integration with the cloudflared.exe client side tunnel, as described in the initial feature request.

Hopefully all that makes sense, please let me know if you would like any additional info.

Joe