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,
