thomas.geens

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.

Dear all,

This post was helpful for allowing me to connect to a NetScaler device, using the following additional settings;

Other parameters: -rawsettings Shell=shell

Kind regards

Dear Hubert,

Following this matter we're now experiencing the same kind of issues with event-macro's using telnet/putty sessions.

For example when we program an after connect event to send a password or username. E.g. When it would contain numbers then different keystrokes are being sent.

This used to work however in the past.

Kind regards

Dear Olivier,

Still seems to be an issue... Changing it from PowerShell doesn't affect anything. Also powershell shows the wrong value.

ScreenSizingMode set in RDM Application to SizeWindow

XML View

<ScreenSizingMode>FitToWindow</ScreenSizingMode>

...

<ID>a6400da7-2b95-4509-9ced-3221dc5c8729</ID>

Powershell View

PS C:\Program Files (x86)\Devolutions\Remote Desktop Manager> write-host $item.ID => $item.RDP.ScreenSizingMode

a6400da7-2b95-4509-9ced-3221dc5c8729 => FitToWindow

ScreenSizingMode set in RDM Application to Smart Reconnect

XML View

<ScreenSizingMode>AutoScale</ScreenSizingMode>

...

<ID>a6400da7-2b95-4509-9ced-3221dc5c8729</ID>

Powershell View

PS C:\Program Files (x86)\Devolutions\Remote Desktop Manager> write-host $item.ID => $item.RDP.ScreenSizingMode

a6400da7-2b95-4509-9ced-3221dc5c8729 => FitToWindow

Dear David,

I must apologize, I wasn't aware you were talking about an RDM option; disable DPI scaling on high DPI. I was trying the Windows disable DPI scaling option on the RDM application.

Once I disabled the "disable DPI scaling" option inside RDM it seemed to work again.

Kind regards

Dear David,

I'm having issues with this suddenly since the last update 12.0.2.0 using a 4K screen on a laptop.

The disable DPI scaling on high DPI option doesn't change anything for me. (hadn't even tried this before version 12.0.2.0)

I'm now having the issue on 2008 and 2012 servers.

The properties are still set the same as before:

$item.ScreenSize = "Default"

$item.RDP.ScreenSizingMode = "FitToWindow"

Playing with all the options from RDP and windows disable DPI Scaling doesn't change anything.

Kind regards

Dear Olivier,

Works perfect this way!

Thanks

Dear Devolutions,

It seems we can't set sub properties using the powershell cmd-lets. Below is an example of what's going wrong.

PS C:\Program Files (x86)\Devolutions\Remote Desktop Manager> Get-RDMSessionProperty -ID $myitem.ID -Property RDP.ScreenSizingMode

FitToWindow

PS C:\Program Files (x86)\Devolutions\Remote Desktop Manager> Set-RDMSessionProperty -ID $myitem.ID -Property RDP.ScreenSizingMode -value "FitToWindow"

WARNING: Path or property not found. Value not set.

Kind regards

I had the exact same issue. When I tried the option "Open External" it did function however. So I knew the settings were correct.

Thanks to the hint from @Izak van den Nieuwendijk I got it working by using the x64 version of RDM.

Dear Hubert,

Maybe you could replace the special characters before you send them, and enclose them in {} braces.

The plus sign (+), caret (^), percent sign (%), tilde (~), and parentheses ()

Kind regards

Dear Hubert,

We're using the latest versions of RDM and OpenVPN.

Instead of the "%" signs we receive "5". I believe it has something todo with our keyboard setup (Belgian Period - Azerty). The 5 on our keyboard is located where the "%" sign is on a QWERTY keyboard.

We don't use any lockkeys such as TAB, SHIFT, SCROLL etc.

Could it be that you have some special handling for the % sign, since this normally stands for the ALT-Key?

Kind regards

Dear Support,

We've noticed when using the Automatic Authentication feature within the OpenVPN AddOn the passwords aren't transferred correctly when they include a "%" (percentage) sign.

Our localisation is nl-BE and the % sign is transferred as a 5 when we redirect it to Notepad.

Kind regards