First RDP launch sometimes does not establish the SSH tunnel connection, second launch works

Hello,

Thank you for the detailed explanation. Based on what you've described, it sounds like the SSH tunnel is being established successfully, but the RDP session may be attempting to use it before everything is fully ready.

Could you try the following?

1. Open the VPN settings for your SSH Tunnel entry.
2. In the SSH settings, enable or increase the Delay before reconnecting option.
3. Then go to Advanced and increase the Delay after execution to around 10 seconds.

This will give the SSH tunnel additional time to become fully available before the RDP client attempts to connect.

Please let us know if increasing the delay resolves the issue or if the behavior remains the same. If it still occurs, we can investigate further with additional logging.

Best regard

Hello,

thanks for your reply.

The "Delay before reconnecting" is already set to 30 seconds.

The "Delay after execution" is already set to 3 seconds but I see clearly in the log the the SSH Tunnel is established and ready in the 1 second.

Hello,

Thanks for the extra detail the fact that the SSH server never receives the forwarded connection request on the first attempt (but does on the second) is very useful, and rules out the tunnel-establishment delay.

Could you try the following, in this order, and let us know which one changes the behavior?

1. Switch off "Use dynamic port" on the SSH Tunnel VPN and set a fixed local port instead. Dynamic port assignment adds a small readiness window between the local listener being bound and the forwarder being wired to the SSH channel — using a fixed port eliminates that race entirely.
2. Change the VPN connection mode on the folder from Open at folder level to Open before session / Close after session (or vice-versa, whichever you are not currently using). This changes when the tunnel is created relative to the RDP launch.
3. Enable RDM advanced diagnostic logs: Help → Diagnostic → Advanced Logs → Enable, reproduce the failing first launch and the working second launch, then send us:
   • the RDM diagnostic log,
   • the SSH Tunnel log (found under the same Diagnostic menu),
   • and the corresponding time-window from your SSH server log.
4. The timestamps between "listener bound" in the RDM tunnel log and the first direct-tcpip request on the SSH server side are what we need to confirm the race.
5. Confirm the SSH engine used by the tunnel (Devolutions SSH vs. PuTTY/plink vs. OpenSSH) in the VPN's advanced tab. If it's currently Devolutions SSH, please retest once with PuTTY or OpenSSH to see if the behavior changes.

The step that's most likely to resolve it outright is #1 (fixed port). Steps #3 and #4 will let us pinpoint the root cause if #1 and #2 don't fix it.

Best regards,

Hello,

thanks for the troubleshooting steps.

It is not possible for me to go with option 1 since the RDP entries in the folder inherit the VPN config from the folder and I need to be able to open multiple RDP connections in the folder simultaneously.

Option 2 and 3 I can not find them in RDM

I can't find "VPN connection mode" in the VPN options of the folder.
Also I don't have Diagnostic in the Help Tab in the ribbon

Best regards,

Tim

Hello,

Thanks for the follow-up and for clarifying your setup.

You're right—the fixed-port suggestion isn't suitable since you need multiple RDP sessions running in parallel through the same SSH tunnel.

A workaround that has helped in similar cases is to move the SSH Tunnel link from the folder to each individual RDP entry.

For each RDP entry:

• In VPN/Tunnel/Gateway, set Type to Session link.
• Select your existing SSH Tunnel entry.
• Set Connect to Always connect.
• Set Close to On session close.

This keeps dynamic ports while avoiding potential conflicts caused by folder-level inheritance.
If you'd prefer to keep the tunnel at the folder level, could you try setting:

• Connect: Always connect
• Close: Never

This keeps the tunnel open between launches and may avoid the issue.

Could you also send us a screenshot of Help > About in RDM? That will confirm your exact version and edition so we can provide the correct logging instructions.

Best regards,

Hello,

I would prefer to keep the tunnel at the folder level.

The settings was already at Always connect for the connect setting.

For the Close setting in don't have "Never" but "Manually later"

I can try it but it likely wont help since the problem sometimes happens also on the first connection of the day.

If I know were to activate the logs we hopefully can find better insights on the problem.

Hello Tim,

Thank you for the screenshots.

The log controls are still under the Help tab; the button may be hidden if the ribbon is in compact mode.

Please expand the ribbon (double-click any tab header if minimized) and use the following buttons in the Help tab:

• Application Logs > Report tab > Send to Support.
• Performance profiling > refresh the workspace while holding Ctrl, reproduce one failing launch and one successful launch, then use Send trace to support.

Could you also confirm which SSH engine is selected in the SSH Tunnel entry's Advanced tab (Devolutions SSH, PuTTY, or OpenSSH)?

The direct-tcpip behavior differs between engines and this detail will help narrow the cause.

As an interim workaround, adding a small pre-warm step on the SSH Tunnel entry, such as a short SSH shell command executed on tunnel open, often masks this timing issue by triggering the forwarded channel before the RDP client starts.

Finally, is the failure limited to the first launch of the day, or does it also happen intermittently later on?

Reference: https://docs.devolutions.net/rdm/knowledge-base/how-to-articles/send-application-logs/

Best regards,