Azure Bastion SSH connections not working as expected since version 2024.2.21.0

Hello

It's very strange that this would only be failing for SSH connections; please can you try and gather some more information?

Open the "Profiler" window (in the "Help" section of the ribbon) and switch to the "Debug Only" tab. Set the "Debug Level" to "1"; and, leaving the profiler window open, try an SSH connection. After the connection fails (or after being stuck for a few seconds), switch back to the profiler and you can send me the output (either via PM or to service@devolutions.net, mentioning this forum thread in your message).

I would also appreciate it if you can check the "Application Logs" (also under "Help") for any unreported errors.

Please, let me know if something isn't clear or you have further questions.

Kind regards,

Hello Richard,

Looking at RDM release notes something was changed for Bastion in 2024.1.21.0 "Added support for any connection type through Azure Bastion" since that moment all our SSH terminal sessions through Bastion started to fail, I uninstalled latest version, reinstalled 2024.1.20.0 and they are working fine again with the old version. Issue has been reproduced on multiplle computers/users.

We are using Bastion in TCP tunnel mode, connecting to IP of target server.

Application logs show:
Date Version Type Message
4/9/2024 2:33 PM 2024.1.23.0 - 64-bit 2 "An attempt was made to access a socket in a way forbidden by its access permissions. (System.Net.Sockets.SocketException (10013): An attempt was made to access a socket in a way forbidden by its access permissions.
at System.Net.Sockets.Socket.UpdateStatusAfterSocketErrorAndThrowException(SocketError error, Boolean disconnectOnFailure, String callerName)
at System.Net.Sockets.Socket.DoBind(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.Sockets.Socket.Bind(EndPoint localEP)
at System.Net.Sockets.TcpListener.Start(Int32 backlog)
at Devolutions.Az.Bastion.WebSocketProxy.Start()
at Devolutions.Az.Bastion.Tunnel.Initialize(Host bastionHost, VirtualMachine virtualMachine, Int32 workloadHostPort, CancellationToken cancellationToken, Int32 localPort, WebContext webContext)
at Devolutions.RemoteDesktopManager.Business.VPNOpeners.VPNAzureBastionOpener.<>c__DisplayClass6_0.<DoOpen>b__0())"
[Devolutions.Az][Error][2024-04-09 14:34:26Z] System.Exception: the server closed the connection
at Devolutions.Az.Bastion.ClientWebSocketConnection.Receive()

I will send profiler output in a separate communication.

Hello

It's very strange; the change for the connection types literally just removed a check that prevented you from using Azure Bastion with certain connection types. None of the internals were changed. There was a bigger change to the Azure Bastion integration internals earlier in the release cycle, but I believe that landed in 2024.1.17. I'm going to check that, however.

Thank you for the log information, I'm investigating this and I'll post back once I have some news. Thank you for your patience.

In the meantime please don't hesitate with questions or other comments.

Kind regards

Hello again

I do have an idea about this; can you tell me more about the SSH session(s)? Specifically I'm interested in the port configuration: is it left a "default", explicitly set at 22 or a different port; or perhaps it's more complicated than that (for example, maybe you are using templates or host entries).

Please, let me know if something isn't clear.

Kind regards,

Thanks for your replies Richard,

Port is set to "Default".

Hello

I'm sorry, you were right: the change you noticed in the release notes is relevant. We removed the restriction for tunnelling arbitrary session types via Azure Bastion, but there was a regression in how the workload port is resolved on the RDM side.

I have fixed this and it will be in the next update (which should, all being well, be sometime later this week) but in the meantime you can workaround by explicitly assigning the port instead of leaving it as default (so, 22 in this case).

I apologize for the inconvenience.

Please, don't hesitate if you have further questions or comments.

Kind regards,

Many thanks Richard, yes I confirm switching port to 22 instead of "default" fixes the issue, great workaround and easy to apply, let me change all our SSH sessions to port 22 in our datasource, we don't have so many.

Looking forward to having new version with bug fixed.