Sub-connection below jump server opens correctly but cannot be relaunched after timeout

I am using the inherit option by the way rather than specifically selecting a jump host.

Hello,

Thank you for contacting us on that matter!

Unfortunately, we cannot see your screenshot, could you please send it to us again in your next reply? As for the connection not working after timing out, I suspect that this is due to the fact that RDM does not consider it as "closed".

For this reason, I would like you to test the "Keep-alive" feature on your RDP entries. I suspect that with this option enabled, you won't have to close and launch your RDP entries once more to establish the connection. To enable this option, please go to the properties of your RDP entry, under the "Experience" section and set a value:

Let me know if that helps!

Best regards,

Thanks for getting back to me, unfortunately the image was pasted into my original message but got lost along the way. Please see an example below.

The parent RDP connection to the agent (ending in @personal) is connected, plus two SSH connections launched successfully via the agent through inheritance of the jump session (ending ~200GB). However the next two connections are marked with a green play symbol but were not successful because the SSH service wasn't running on the host at the time.

However therein lies the rub.. the agent doesn't report the status of the failed connection back to the parent jump server so you cannot relaunch the connection without first logging out of the RDP jump session and reopening it. You cannot close the session within RDM, nothing happens, and you cannot choose Reconnect either.

If you imagine a scenario where we have lots of different connections, indeed some may timeout and could be extended using TCP keepalives, but other times hard session time limits outside of our control will expire the connection. We're building out a management cluster where almost all of the infrastructure will be managed through one jump server, and therefore it's getting to be unreliable if we are forced to close a jump session in order to relaunch something via the agent.

Hello Steve,

Thank you for your swift reply and for sending me your screenshot again!

If you head over to the "Opened Sessions" section of your Navigation Pane, are you able to close one of these sub-connections and then launch it through the jump without issue?


Best regards,

I can close running sessions from within the jump host session using this method, but not from the parent RDM instance. That just lists the connection to the jump server but not the subordinate sessions. I can also confirm that it's not possible to close a session launched via a jump server from the parent RDM instance. I've tried converting the sub-connection from 'inherited' to a named jump session, this doesn't fix it either. So back to my original question - how does RDM communicate sub-connection state between the parent RDM instance and the jump host's RDM instance? It looks like that's not working how I think it's intended - should be simple to reproduce.

Hello Steve,

After having a discussion on that matter with our Engineering Department, they have confirmed that this issue is caused by a bug. A ticket has been opened with them to fix this.
We will inform you once we will have an update to provide on this case.

Best regards,

Sorry to keep firing back updates, but I find it strange that when you use the 'Open via Jump' menu option and traverse the menu structure as example below, the sub-connections (and their current state according to the parent RDM) are shown as eligible jumps - even though actually the jump server is the one preceding those sub-connections. Perhaps it could occur that a customer has a double-jump, but shouldn't this menu option only expose the connections defined as 'Jump'?

Hello Steve,

Our Engineering Department has just informed me that in the latest version of RDM, 2021.2.18.0, you should be able to close sub-connections manually. They are still working on a fix that will update the states of the connections automatically. I will inform you once I will have an update to provide on this second fix.

Best regards,

Thank you James - I was away last week so wasn't able to test until now.

I can confirm that the new version resolves the inability to close/reopen sub-connections from beneath the jump server entry. However in 2021.2.20.0 (I skipped the intervening two releases) the Close, Reconnect actions on the sub-connection do not actually change the state of an existing session. If choosing Close the session status under the jump server does change from open to unopened within the navigation pane but the actual session status remains unchanged.

So to summarise, we have improvement as it's now possible to reopen a sub-connection which was closed either manually or timed out
However it is not possible to alter the state of an existing sub-connection from the parent RDM which controls connection to the jump host.

Feels like progress, but certainly behaviour that I recall was well established doesn't seem to work fully currently. Any chance you can bounce this back for a second look?

Hello Steve,

Glad to see that 2021.2.20.0 has fixed a part of this issue.

As mentioned in my last reply, our Engineering Department is still working on finding a fix that will update the states of the connections automatically. I will be in touch as soon as I will have an update to provide on that matter.

Best regards,

Hello,

We've made a fix to properly synchronize the sub-connections states with the jump host. It will be included in version 2021.2.22.0.

Regards