RDM 2026.3.1.2 (macOS): Hub connection times out when hostname has unreachable IPv6 (AAAA) addresses, no fallback to IPv4
Title: RDM 2026.3.1.2 (macOS): Hub connection times out when hostname has unreachable IPv6 (AAAA) addresses, no fallback to IPv4
Remark
This bug report mostly serves for logging purposes and possible circumvention proposals in case any other Devolutions’ customers may experience related issues.
Environment
- RDM for macOS 2026.3.1.2 (.NET 10.0.12), updated 05/10/2026 from 2026.2.5.1
- macOS Tahoe 26.6.2
- Data source: Devolutions Hub Business (`example.devolutions.app`)
- Network: dual-stack (native IPv4 + IPv6)
Problem
Every HTTP call from RDM fails: the Hub login, the update check, and so on. Other apps on the same Mac work fine. RDM throws a connect timeout:
System.Threading.Tasks.TaskCanceledException: OperationCanceled ---> System.TimeoutException: net_http_connect_timedout at System.Net.Http.HttpConnectionPool.ConnectToTcpHostAsync(...) at System.Net.Sockets.SocketAsyncEventArgs.<DnsConnectAsync>g__Core|113_0(MultiConnectSocketAsyncEventArgs ...) ... at Devolutions.RemoteDesktopManager.Business.DataSources.HubClientDelegate.SendWithTimeoutAsync(...) at Devolutions.Hub.Clients.HubClient.GetServerConfigurationAsync(...) at Devolutions.RemoteDesktopManager.Business.DataSources.HubConnectionDataSource.Login()
Cause
The local DNS resolver had DNS64 enabled without a NAT64 gateway. That's a misconfiguration on my side, now fixed. It caused the Hub hostname to resolve to unreachable IPv6 addresses alongside the working IPv4 ones:
$ dig +short AAAA example.devolutions.app 64:ff9b::8d65:5a60 (x4, unreachable) $ curl -6 https://example.devolutions.app -> connect timeout $ curl -4 https://example.devolutions.app -> HTTP 200
curl, browsers and other macOS apps fall back to IPv4 within milliseconds. RDM keeps trying the IPv6 addresses one after another (MultiConnectSocketAsyncEventArgs) until its own timeout in HubClientDelegate.SendWithTimeoutAsync expires, so it never reaches IPv4.
Workaround
Remove the unreachable AAAA records: disable DNS64, or turn off IPv6 on the Mac. RDM then connects immediately.
Request
The same failure will happen on any network with broken or partial IPv6, such as hotel, guest and some corporate networks. Could you:
1. Check whether something changed in 2026.3.1.2 in the HTTP handler or the connect timeout? I didn't see this with 2026.2.5.1.
2. Consider IPv4/IPv6 fallback ("Happy Eyeballs", RFC 8305) in the Hub client. For example, use SocketsHttpHandler.ConnectCallback to race the addresses, or use a short per-address connect timeout instead of one overall timeout.
Hello Thomas,
Thank you for the very detailed report, and for sharing the root cause (DNS64 without a NAT64 gateway) and your workaround. This is helpful for us and for any other user who may run into the same situation.
We compared your findings with our source code. The Devolutions Cloud connection uses the standard .NET HTTP handler with a 20 second connect timeout and no IPv4/IPv6 fallback logic (Happy Eyeballs). We also compared 2026.2.5.1 and 2026.3.1.2: the connection logic is the same in both versions, so we did not find a change there that explains why it only appeared after the update.
For this reason, we will send your report and your suggestion (Happy Eyeballs, or a shorter timeout per address) to our developers for review. I cannot promise if or when a change will be made, but I will keep you updated here in the forum with their answer.
Since the issue is solved on your network, you do not need to do anything else for now. If anything changes, please reply here.
Best regards,
Alexis Geller Peiro