Devolutions Gateway farm - Faster failover

Hello,

Thank you for your request. Yes, it is possible to change the Gateway Health check interval to seconds and allow users to set it accordingly. I will create a ticket to address this.

However, I would like to understand more about the second part of your request:

The idea is that users should be able to instantly reconnect in case of a gateway failure.

Even if the health check is sent more frequently, if a user is disconnected due to a gateway failure, the user must attempt to reconnect themselves.

Best regards,

Sorry, perhaps i was a bit unclear.

"The idea is that users should be able to instantly reconnect in case of a gateway failure". - i've only meant, that the health check interval is too long, and user will not wait for 1 minute before trying to reconnect. They will send us a ticket instead.

But if the health interval could be reduced to 1-5 seconds, that should be satisfactory.

Hi, do you think that this change from minutes to seconds will be released soon?

Hello,

That improvement should be released with our next major version 2025.1, and that version should be available in February/March.

However, I'm wondering what exactly your issue is because a gateway being down should not require a successful health check to attempt a new connection. Therefore, I'm not sure why you receive an error when you try to connect through the gateway, even if the last health check was a failure. Could you let me know what the error message is that you receive when you try again to open a session through the gateway?

Best regards,

Hello

We have 2 gateways in a farm.

We execute connection which is using gateway as a farm. We note down that connection is established via gateway #1.

We stop the Gateway service on the gateway #1. RDP connection is dropped. We close the connection. We try to execute the same connection. It keeps trying to establish connection over the gateway #1, even though we several times close/re-launch the connection. It does not automatically change to establish connection over gateway #2 until the health check is triggered, or we manually trigger gateway scan through web UI.

Hello,

Thank you for that feedback. I had not realized that you were associated with a farm. That explains the behavior. In your situation, if you have 2 gateways, we will select one gateway that is operational. The problem is, as you mentioned, the fact that the server doesn't know until the next health check if gateway #1 is down, so it continues to direct traffic to that gateway.

We don't think that setting the health check interval to 1-5 seconds would be the solution. It is probably too aggressive. I don't know how many gateways you have, but it could be an issue with many gateways. We plan to support seconds in health check intervals, but I had in mind to set a minimum of 10-15 seconds, otherwise, I'm not sure of the impact on the system.

But to improve the connectivity in your situation, we discussed and we would suggest this: The server, before sending back to RDM the token used to do the connection, could perform a health check on the selected gateway. It means that in your situation, the server would select gateway 1, attempt a health check, detect that it is down, search for another gateway, select gateway #2, and send it back to RDM. With such a solution, each connection could be a little bit longer since the server will perform health checks, but it would never send back a gateway that can't be reached. I think it would be very helpful to avoid situations like you described. Let me know if that would help, we could probably plan that improvement for the next major version as well.

Best regards,

Hi Francois,

That would be even better!

Hello,

Thank you for your confirmation. I'm creating a ticket, and we will work on that soon. It should be included in the next major version, available in February/March.

Best regards