Reverse Proxy for Gateway Agents

Hello @Lars

Just to clarify the use case: is the goal to install an Agent at a customer or remote site, have it establish an outbound connection to Gateway, and then let Gateway route sessions through that Agent to private resources behind it?

In other words, are you referring to something like a remote-site outbound connector or tunnel? Something that would allow you to use a central Devolutions Gateway to manage access to many internal networks behind Devolutions Agents?

Best regards,

Hello @Benoit Cortier
As we understood the Gateway is a way to connect to servers and services on edge networks without VPN.
But we do requiere those connections to be on-demand and the protection a reverse proxy offers.

I see you support 3- party Reverse Proxy Solutions, but this another layer of complexity to the solution.
the addition of a native Reverse Proxy in the Gateway solution would make it a viable option for us to make use of.

A typical example of a use case for us would be to connect to a server (RDP) or a service (SSH/HTTPS) at a customer location. Today we use VPN for this.
But we're looking into a way to do this simpler and more secure.
What we want would be the option to deploying one Reverse Proxy Agent that would handle incoming network connections to the different servers in that given network. (RDP, SSH, HTTPS etc).
Allowing only connections coming from our Public IP.

Thanks, that helps.

I want to make sure I’m really understanding your request correctly.

You are asking for a native site connector / outbound tunnel capability in Devolutions Gateway, where a component deployed inside the customer network would:

• establish an outbound connection to Gateway, simplifying network configuration at the customer site,
• allow Gateway to securely relay RDP / SSH / HTTPS connections to internal systems behind it,
• and do this without requiring a separate third-party reverse proxy or VPN solution such as Cloudflare tunnel or Ngrok.

If that is what you mean, then I believe I understand the use case correctly.

I’m also glad to let you know that we are currently experimenting with such a feature and have already made good progress. It is currently planned for v2026.2 on our roadmap.

I’ll attach the ticket to this thread.

Best regards,

Correct, that is what we are looking for in functionallity.
Of course with central mangement of these Gateway agents, so we can bulk update them from the Gateway server.

Glad to hear that, do you have a timeframe for when v2026.2 will be available?

Perfect.

The 2026.2 iteration will also ship self updates and scheduled updates for Devolutions Agents.

The feature is already part of Devolutions Agent and Gateway v2026.1.2 released yesterday:

However, we still need to make this easy to manage centrally via Devolutions Server.

As for the timeframe, YYYY.2.0 versions are typically released in June, so I would say in 1 or 2 months from now.

Best regards,

Thanks, we'll keep our eyes peeled!

This sounds really interesting if this is truly an "call home" network design Devolutions is working on.

We're an MSP company which POC'ed your software around 2-3 years ago, and the main reason we did not choose you was because as an MSP with many customers where we manage our servers in their site/network, we always have a hard requirement for the software we use needs to be able to call home in order for us to be able to use it.

Back then you also license per gateway which would have costed way to much for us, I can see the licensing has changed and this is no longer the case.

@Benoit Cortier I've quickly sketched this on draw.io, is it correct that this is the flow of traffic that will hope to support is the upcoming release?

Other questions

• Will you support that we can place an reverse proxy (NGINX) in front of the Devolution server?
• Can the port be changed to simply be 443, this makes outbound port requirement on the customers network much easier since almost everybody has 443 open
• Will this work for all types of your Gateway servers? (Windows, Linux and Docker)
• We are running af trial on the software now. I've configured some gateway servers, it seems they needs to be signed with trusted certs as far as I understand? Also the CRL also needs to work or can we simply just use the "Publish revocation list" once and everything will just work? (I'm thinking of the challenge of deploying + maintaining around 50 gateway servers)

Regards.
Gert

Hello @gertvanniekerk

I’m glad you’re evaluating our products again.

As for the diagram, it’s slightly different in the details: you would install a Devolutions Gateway in your infrastructure or in the cloud (it could be anywhere as long as you’re able to reach it from your infrastructure and from the customer infrastructures), and you would install a Devolutions Agent in each customer’s infrastructure. The Devolutions Agent will perform the "call home" against the Devolutions Gateway, and a VPN-like tunnel will be open between the Devolutions Gateway and each Devolutions Agent instance. In this configuration, the Devolutions Gateway will be used as a rendezvous server: the Devolutions Agent connects to it, RDM connects to it, and the session is relayed without ports being opened in the target infrastructure, which is what you are after as I understand it.

Will you support that we can place an reverse proxy (NGINX) in front of the Devolution server?

I think it’s already possible for you to have a reverse proxy in front of both Devolutions Server and Devolutions Gateway. You just need to forward HTTP traffic for Devolutions Server, and both HTTP and TCP traffic for Devolutions Gateway (there is a HTTP listener and TCP listener).

Can the port be changed to simply be 443, this makes outbound port requirement on the customers network much easier since almost everybody has 443 open

For Devolutions Server, the port can be changed to 443. In fact I think it’s already the default, as per this documentation page: https://docs.devolutions.net/server/kb/knowledge-base/ports-firewalls/
For Devolutions Gateway, I think the default ports are 7171 and 8181, but that’s also something that can be changed either during the installation or by modifying the configuration file.

Will this work for all types of your Gateway servers? (Windows, Linux and Docker)

Yes, it’s planned for all platforms, for both Devolutions Gateway and Devolutions Agent. (Although I don’t think we provide docker images for the agent yet, that’s something we’ll provide too in the future.)

We are running af trial on the software now. I've configured some gateway servers, it seems they needs to be signed with trusted certs as far as I understand?

Yes, we highly recommend using TLS for encrypting the HTTP payload, and this needs to be trusted certificates. However, you can have your own certificate authority as long as each client machine is configured to trust this authority.

Also the CRL also needs to work or can we simply just use the "Publish revocation list" once and everything will just work? (I'm thinking of the challenge of deploying + maintaining around 50 gateway servers)

The "Publish revocation list" button you see for the Devolutions Gateway is different from the CRL of the (HTTP) server certificates. It’s a revocation list for long-lived tokens that you may or may not need for using the KDC proxy feature of the Devolutions Gateway. It’s okay to not publish it if you don’t use that feature.


Please let me know if you have further questions.

Best regards,