Best practices for Devolutions Server & Gateway deployment

Hello,

From what we understand, the Devolutions Gateway needs to be installed at the customer’s location, and the RDM client connects to it directly. This seems to require opening the gateway’s port to the entire internet,

Correct. Indeed, it requires exposing the necessary listening ports in some way or another.

which in our view defeats the purpose of adding an extra security layer.

This is a requirement you can’t get around, even if you decided to use a VPN instead: typically UDP 1194 or TCP 443 for OpenVPN, and UDP 51820 for WireGuard. Of course, you need to trust the exposed service to be hardened enough for this use case, be it OpenVPN, or Devolutions Gateway.

Similar to VPN solutions, the purpose is to bring down a "N to N" into a "1 to N". Instead of exposing your whole infrastructure (N) to the internet, you merely expose a single, hardened service designed for this purpose (1). In contrast, many of the N services you want to keep protected inside your private network are not designed with internet exposure in mind. Even if they were, you would need to trust all of them.

The Gateway is designed to be a modern, secure alternative to traditional VPN setups.
A few core properties:

• Built in Rust, which helps mitigate many common memory safety vulnerabilities.
• Open source, so it’s fully auditable by security-conscious teams.
• TLS-encrypted tunnels, even for older/less secure protocols like HTTP or Telnet.
• Designed for internet exposure, and many users (including us at Devolutions) run it exposed directly, no major known vulnerabilities at this time. Of course, it’s audited by our internal security team for that.

How are other users handling this scenario? Are there recommended approaches or alternative configurations that avoid exposing the gateway directly to the public internet while still allowing remote RDM client connections?

While it is safe to expose the Gateway directly to the internet, here are a few tips depending on your comfort level:

• Default config is hardened, but you can still layer it:
  • Some users place the Gateway behind reverse proxies (e.g., Cloudflare Tunnel or nginx with mTLS) or inside VPNs, for additional peace of mind.
• Use strong authentication and permissions via Devolutions Server (or Hub) to control access paths and limit what users or vendors can see/do.
• Monitor logs and enable session recording if you’re handling sensitive environments.
• Keep Gateway, RDM and Devolutions Server up to date, of course.

Let us know if you have any question.

Best regards,

Hello Benoit

we have deployed a Devolution Server opening https 443 port only that work great for RDM client without need of a VPN.
The goal in a side-by-side approach for the gateway would be to use same port - but the documentation ask for 7171 and 8181 ports.

The biggest problem is that we often find ourselves connected to networks that don't allow direct calls to non-standard ports, and these two do. If, however, those ports are answered after a call to a legitimate port, then it might work without problems, but I don't think so.

Any ideas?
Thanks

Hello,

If you install the Devolutions Gateway in side by side with Devolutions Server and IIS using the Devolutions Console, IIS will act as a reverse proxy for the HTTP calls directed at the Devolutions Gateway, and as a result you don’t need to expose the port 7171 directly, and you don’t need to configure a TLS certificate on the Devolutions Gateway as HTTPS will be handled by IIS.

As for the port 8181, unfortunately, it’s currently not possible to go around that for many protocols such as RDP today, but we have a low-priority feature planned to allow using a special tunnel going through the HTTP listener only.

I don’t think we have a topic on this specific matter as of today. Do you think you could open a separate topic, as a feature request, for this specific feature?

Thank you!

Done!
Thanks

Thank you!