Continuous reconnects (Probably since Microsoft switched to Windows App?)

Hello David,

First, I just want to make sure you are at the latest version of RDM Mac. We had some issues with the switch to Windows app, but the issue was supposed to be solved a little while ago.
After, do you have any logs documenting the connect-disconnect-reconnect loop?

best regards,

Hello,

I'm running 2024.3.4.4 since 11/10.

I'll attach the application log with the events from the last 60 days in a .zip. I was unable to attach the log directly.

Let me know if you're interested in any other logs :)

//David

Hello,

we are looking through the logs,
Now I have one last question, when you are opening your sessions, are they in External or embedded?

Best regards,

Hello,

I'm always opening sessions embedded :)

I have a colleague which is experiencing the same behaviour. Also on macOS.

//David

Hello

If you're using the embedded mode, it's unrelated to the Microsoft RDP application. We embed our own RDP implementation (sadly the Microsoft client cannot be embedded in another application on Mac, like it can on Windows).

Two things that would help:

• First, try to disable the sandboxing mode temporarily to see if it helps. You can configure it "per session" in the "Advanced" tab ("Activate Sandboxing") or application-wide in Settings > Types > Remote Desktop > Advanced
• Second, enable session logging and reproduce the behaviour, then send the log to us (either direct to me by PM or to service@devolutions.net, mentioning this forum thread in the subject). You can find instructions for that here.

Please, don't hesitate to post back if something isn't clear or you have other questions

Kind regards,

Hello again,

I tried disabling sandbox mode but the issue was still present.

I noticed 3.5.1 was released recently so I will try to update and see if my issues have been resolved :)

Either way I'll try to enable session logging.

//David

Quick update,

Issue is still present on 3.5.1 as well. This stands out in the session logs, exactly when the connection drops:


[13:39:41:714] [21030:762bf000] [DEBUG][com.freerdp.core.heartbeat] - [rdp_recv_heartbeat_packet]: received Heartbeat PDU -> period=1, count1=8, count2=8
[13:39:41:714] [21030:77743000] [DEBUG][com.freerdp.core.heartbeat] - [rdp_recv_heartbeat_packet]: received Heartbeat PDU -> period=1, count1=8, count2=8
[13:40:24:649] [21030:77743000] [WARN][com.freerdp.core.transport] - [transport_ssl_cb]: Unhandled SSL error (where=16392, ret=532 [fatal, bad record mac])
[13:40:24:650] [21030:77743000] [ERROR][com.freerdp.core.transport] - [transport_read_layer]: BIO_read retries exceeded
[13:40:24:650] [21030:00393240] [ERROR][com.freerdp.core.transport] - [transport_default_write]: BIO_should_retry retries exceeded
[13:40:24:650] [21030:00393240] [ERROR][com.freerdp.core] - [transport_default_write]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:40:24:650] [21030:77743000] [ERROR][com.freerdp.core] - [transport_read_layer]: ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
[13:40:24:650] [21030:77743000] [ERROR][com.freerdp.core] - [transport_read_layer]: TODO: Trying to set error code ERRCONNECT_CONNECT_TRANSPORT_FAILED, but ERRCONNECT_CONNECT_TRANSPORT_FAILED already set!
[13:40:24:650] [21030:77743000] [DEBUG][com.freerdp.core.transport] - [transport_check_fds]: transport_check_fds: transport_read_pdu() - -1
[13:40:24:650] [21030:77743000] [DEBUG][com.freerdp.core.rdp] - [rdp_check_fds][0x3b50a3200]: transport_check_fds() - -1
[13:40:24:650] [21030:77743000] [DEBUG][com.freerdp.core] - [freerdp_check_fds]: rdp_check_fds() - -1
[13:40:24:650] [21030:00393240] [ERROR][com.freerdp.core.transport] - [transport_default_write]: BIO_should_retry retries exceeded
[13:40:24:655] [21030:77743000] [DEBUG][com.freerdp.core.rdp] - [rdp_finalize_reset_flags][0x3b50a3200]: [CONNECTION_STATE_ACTIVE] reset finalize_sc_pdus
[13:40:24:655] [21030:77743000] [DEBUG][com.freerdp.core.rdp] - [rdp_client_transition_to_state][0x3b50a3200]: CONNECTION_STATE_ACTIVE --> CONNECTION_STATE_INITIAL

Hello David

Thanks for the information.

This is a failure decrypting an update from the server, at the TLS level. It's notable that this occurs while the connection is active rather than at handshake time, which would seem to rule out a TLS misconfiguration on the server. Typically this would occur because the data is corrupted by the time it arrives at the record decryption in OpenSSL, which could be a server bug (either in the TLS stack or elsewhere), network middleware interference or a client-side issue.

Normally I'd be inclined to point my finger at OpenSSL here, but we haven't had any changes in that area for quite some time. Do you normally stay current with your RDM version? i.e. Before this started happening, did you update from a much older release of RDM?

Can you share any more details of the network you're using? Are you traversing the LAN, internet; any kind of security devices like a proxy or firewall in the middle? Have there been changes recently? Any kind of client-side endpoint security being used?

Finally, do you notice this on all servers you connect to, or only some? What kind of server operating system(s) are you connecting to?

The more information you can provide, the more helpful it will be.

Please let me know fi something isn't clear or you have further questions

Kind regards

Hello,

No obvious change except for moving onto macOS 15 when it was released. The issue is not present on Windows-machines running any current RDM version.

I will ask our server technicians if they've made any changes in the recent month in regards to TLS handling.

We contiunally deploy the latest version of RDM, so we're trying to stay current.

We use RDP to a subset of tiered jumphosts which in turn allow for further access. We don't use a proxy for RDP traffic. We do have a firewall, but we do not block internal traffic on the specific vlan that we use to connect to jumphosts.

We do utilize M365 Defender, but logs show no traces of any blocks.

The issue is present when connecting to all of our jumphosts. I could try to set up a lab with direct access to another a more "open" server and try to see if the issue is reproduced there as well.

I would almost assume that the issue lies within our configuration somewhere, since there doesn't seem to be anyone else with this specific behaviour :/

//David

Hi David

Thanks for all the extra detail.

One thing you could try for me, since it sounds possible in your environment: on a Windows machine running RDM, could you temporarily change one of the affected sessions to use "FreeRDP" as the RDP backend, and see if you reproduce the issue on that OS?

In the RDP session options, you'll find it in "Advanced" > "RDP Version" (set to "FreeRDP (Latest)").

Please, let me know if something isn't clear

Thanks again,

Hello again,

I've had a colleague of mine switch to FreeRDP for the day, to see if he expereiences these drops on Window as well.

However, some very promising news..

I started googling around TLS and SSL issues starting with macOS 15 and stumbled on a multitude of articles describing problems in relation to a the changes made in the network stack, so the issue might just be Sequoia-sepcific.

Following that, I applied macOS 15.1 and have so far had two 2h sessions onto separate jumphosts simultaneously without a single drop, which is so far a day and night change..

I'll update later today :)

//David

Hello

Thanks for the update, that sounds promising indeed. Please let us know the outcome.

Thanks and kind regards,

Hello again,

Now we've had the chance to try macOS 15.1 over a few days and that seems to have resolved our issues completely!

Reading the release notes of 15.1 doesn't seem to shed any light on if anything bug-related to SSL or TLS was fixed.

There seems to be a couple of users in different parts of the internet as well that have had issues with SSL and TLS that have been resolved in 15.1

Thank you so much for the support! :)

//David

Hello

Thanks for the information! I would say that in my experience, it's somewhat common for major macOS releases to have regressions in networking (sadly).

I'm really glad that this seems resolved and we'll bear this in mind if someone else reports the same issue.

Thanks once again and best regards,