Devolutions ForumDevolutions Forum

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

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

avatar
noeth

Hi,

I'm experiencing an issue when using an SSH Tunnel configured as the VPN for an RDP session.

The VPN (SSH tunnel) is configured on the folder and inherited by the RDP entry.

Sometimes the first attempt to open the RDP session does not establish a connection. The RDP client stays in the initialization phase and eventually times out. If I close both the RDP session and the SSH tunnel, then launch the exact same RDP entry again (which recreates the SSH tunnel automatically), it connects successfully.

Here are my observations:

  • I can confirm that the SSH tunnel itself is fully established before the RDP client is launched.
  • The RDP client definitely attempts to connect to a localhost port, as expected when using the SSH tunnel.
  • However, when the first attempt does not succeed, I can see in the SSH logs that the connection request for the destination host is never initiated. In other words, the SSH server never receives the request to open the forwarded connection for the RDP destination.
  • On the second attempt, the SSH tunnel behaves as expected: the forwarded connection request is triggered, the SSH server opens the connection to the destination host, and the RDP session connects successfully.
  • The SSH Tunnel VPN settings are configured with Use over a secure gateway, and Use dynamic port.


From what I can see, this doesn't appear to be an issue with the SSH tunnel failing to establish. Instead, it looks as though the first RDP launch sometimes doesn't trigger the forwarded connection through the existing tunnel, even though the RDP client is connecting to the local forwarded port.

Has anyone experienced something similar, or is this a known issue? Are there any additional RDM logs that would help determine why the first RDP launch doesn't appear to initiate the forwarded connection through the SSH tunnel?

Thanks!

All Comments (3)

avatar
Carl Marien

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

Carl Marien

avatar
noeth

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.

avatar
Carl Marien

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,

Carl Marien