RDM 2026.2.1.2 (macOS): RDP-via-RD-Gateway always fails — network monitor loops "Network transition detected - Pausing connections"

RDM 2026.2.1.2 (macOS): RDP-via-RD-Gateway always fails — network monitor loops "Network transition detected - Pausing connections"

avatar

Environment

  • Remote Desktop Manager 2026.2.1.2 (64-bit), macOS (Apple Silicon)
  • Embedded RDP engine: …/Remote Desktop Manager.app/Contents/MonoBundle/libDevolutionsRdp.dylib
  • Connection type: RDP (Microsoft Remote Desktop) through an RD Gateway (WebSocket-based, open-source rdpgw)
  • Gateway server: stage-rdpgw.oneclick.services:443 (valid Let's Encrypt cert, reachable, /remoteDesktopGateway/ returns HTTP 401 as expected)
  • Connection Host: a per-session hostname (e.g. u3wsva2djj-stage.oneclick.services) that is only resolvable through the gateway, not via local/public DNS (by design — the gateway resolves it internally)


Problem Every connection attempt fails within ~3 seconds with:
ERROR Could not establish a secure connection to the host (0x00020008)
(occasionally Connection failed (0x00020006)). Nothing ever reaches the gateway server (verified server-side: no handshake/auth is logged).

Root cause (from RDM debug+verbose log) RemoteDesktopManager.debug shows, in the same second as the error:
DEBUG Network monitoring initialized for host: u3wsva2djj-stage.oneclick.services
DEBUG Network transition detected for host: u3wsva2djj-stage.oneclick.services - Pausing connections
DEBUG Certificate verification skipped: Network transition in progress
→ ERROR Could not establish a secure connection to the host (0x00020008)
The network monitor then loops endlessly, emitting dozens of identical lines per second and never settling:
DEBUG Network restored for host: … - Starting stabilization period
DEBUG Network transition detected for host: … - Pausing connections
It appears the network monitor performs a reachability check tied to the connection's Host, and because that Host is only resolvable via the gateway (not local DNS), the check fails permanently → it perpetually reports a "network transition" and pauses the connection, so the actual connect never proceeds (TLS/cert verification is explicitly skipped).

Proof this is RDM-specific (not network/gateway/target)

  • The native Microsoft RDP client (Windows App / mstsc) connects successfully to the same gateway + same Host from the same Mac and network.
  • A FreeRDP 3.x-based client also connects successfully to the same gateway.
  • Gateway endpoint reachable from the Mac (TCP/TLS OK via openssl/nc); macOS Application Firewall is disabled; no Little Snitch / network-filter extensions.
  • This connection worked previously (January 2026) on an older RDM version (which used the separate FreeRDPSandboxed.app engine and did not have this network-monitoring behavior). On 2026.2.x no SessionLogs/*.log is written for these attempts — the engine aborts before a session starts.

Already tried (no effect)

  • Clean reinstall of RDM 2026.2.1.2
  • Recreating the connection entry from scratch
  • Gateway Transport = Auto and = HTTP
  • Stopping Tailscale/VPN (the monitor kept flapping for 90s+ afterwards)
  • No user-facing toggle for this in RemoteDesktopManager.cfg

Questions / request

  1. How can the RDP network-monitoring / "network transition" pausing behavior be disabled?
  2. This looks like a false-positive when the RDP Host is only resolvable through the RD Gateway (common with gateway-brokered/per-session hostnames). Can the monitor be fixed to not block such connections (e.g. check the gateway reachability instead of the inner Host)?


All Comments (5)

avatar

Confirmed regression (version bisect)

  • Works: RDM 2025.3.9.2 (macOS, Jan 2026) — same Mac, same network, same connection entry, same gateway. Connects normally; the "Network transition / Pausing connections" log entries do not appear.
  • Broken: RDM 2026.1.12.4 and 2026.2.1.2 — every connect fails instantly (0x00020008 / 0x00020006) due to the network-monitor loop described above.
  • Last known-good was Jan 2026 on 2025.3.x; the regression is present in the 2026.1.x line and remains in 2026.2.x.

Conclusion: A change introduced between RDM 2025.3.9.2 and 2026.1.x added the RDP "network monitoring / network-transition pausing" behavior that breaks connections whose Host is only resolvable through the RD Gateway. Downgrading to 2025.3.9.2 is the current workaround.
Updated request: Please identify the change between 2025.3.9.2 and 2026.1.x that introduced this behavior, and provide a fix or a setting to disable the RDP network-monitoring/transition pausing — so we can run a current RDM version against gateway-brokered hosts.

avatar

Hi,

Thank you for the detailed report, the debug logs and version bisect were very helpful in tracking this down.
I was able to reproduce the issue and have applied a fix. This will be included in the 2026.2.2.0 release.

Best regards,

Samuel Oliveira Martel

avatar

Hi,

thank you very much for the fast response and the fix. Do you already know when version 2026.2.2.0 will be released?

Best regards,
Pascal Poschenrieder

avatar

Hi,

I'm using Remote Desktop Manager 2026.2.2.1 (64-bit) on macOS (Tahoe 26.5.1), and I'm having the same problem.

I've noticed that this happens when connecting via RDP to older versions of Windows, resulting in error 0x00020008.

I’ve already tried a few approaches, such as disabling NLA in the host’s RDP settings, disabling TLS, or disabling RDP security, but when I do that, I get the error “Security negotiation failed (0x0002000C)”.


I also tried downgrading RDM to versions 2025.3.9.2 and 2025.3.10.2, but there was no change in behavior.


Unfortunately, I’m having to use the “Windows App” on macOS to gain access to these servers running older operating systems.

avatar

Hello

I'm sorry to hear about the issue. I took a good look at this yesterday and I came to the conclusion that the network monitor and pre-flight reachability checks were both workarounds for bugs that don't exist any more. I've taken out all the related code and submitted it for 2026.2.4 so assuming it passes the QA the problem should be fully resolved at that point. Unfortunately it might be a few weeks before a release as we are juggling developer and QA resources around the summer vacation period.

In the meantime, I have some suggestions that I think should help concretely.

First, in Settings > Types > Remote Desktop (RDP), ensure that “Test for reachability before attempting to connect” is unchecked

Second, we want to prevent RDM from prompting for an untrusted certificate. This can be the Gateway certificate, the RDP server certificate, or both. Two ways to do that:

  • Ensure that the certificate(s) are trusted locally in Keychain Access
  • In the RDP session "Authentication" tab, under "if the actual verification does not meet policy requirements" choose "Connect and don't warn me". Note that this will just suppress the prompt and can be considered a security downgrade.


If the connection still doesn't work, ensure you are providing explicit working credentials for both the Gateway and the RDP server. We want to be sure that RDM is not prompting you for credentials at connection time.

Please, let me know if that helps or you have other questions or problems. I apologize for the inconvenience and thank you for your patience

Kind regards,

Richard Markievicz