Update 2 (Nov. 8, 2019)

  • The bug is unfortunately still present in the first beta of macOS 10.15.2 (19C32e).
  • We updated the bug report that was sent to Apple to make them aware of that fact.
  • The FreeRDP team has implemented changes that allow implementors of the library (like us) to adjust the keep-alive settings. In the future, we can use this to let you disable TCP keep-alive altogether, which is another way to work around the bug.

Update 1 (Nov. 7, 2019)

There appears to be a bug since macOS 10.15 Catalina that causes all TCP keep-alive packets to be dropped when connected via a VPN.

Royal TSX' FreeRDP plugin uses TCP keep-alive packets to determine if the connection is still alive when no other traffic is flowing at the moment. So, this behavior is only relevant for connections that are idle (no client-side interaction and no server-initiated traffic).

This ensure that the connection can "fail fast" instead of appearing to still be connected while the underlying connection has already been lost. That means that when you unplug your ethernet cable, Royal TSX will notice this change in connectivity within a few seconds and close the connection.

Microsoft Remote Desktop on the other hand doesn't send keep-alive packets. This results in broken connections staying open for way longer than in Royal TSX. If there is no client-side interaction and no server-initiated traffic this can keep the connection open indefinitely although it has already been broken for minutes, hours or even days!

These keep-alive packets are very useful to determine the connection's state while it is idle. Without them, there's no way for Royal TSX to know if the connection is alive or broken while idle. When the connection is busy though, for instance when you're using the keyboard or mouse to interact with the session or when the remote side sends screen updates, no keep-alive packets are sent and the connection works properly, even through a VPN.

Here's a summary of the circumstances required for the problem to occur:

  • You're using at least macOS 10.15 Catalina (10.15.1 also suffers from the same bug)
  • You're connected to a VPN using the VPN client built into macOS
  • The Remote Desktop (RDP) host you're connected to is behind the VPN, so RDP traffic flows over the VPN network interface
  • The session is idle for a couple of seconds (around 45 seconds)

When these conditions are met, Royal TSX starts sending keep-alive packets. A total of 3 of these special TCP packets are sent. If none of them arrive at their destination, the connection is assumed to be broken and Royal TSX will close the connection tab.

At the moment we don't know why these packets are dropped by macOS' VPN implementation. The problem isn't present in macOS 10.14 Mojave for instance. It also doesn't occur when not connected via a VPN. We will submit a bug report to Apple soon and hope that they fix this issue quickly.

In the meantime, here's a convenient workaround to actually keep the connections alive:

Workaround

Royal TSX supports an additional method to keep connections alive while they're idle. This keep-alive feature is NOT based on sending TCP keep-alive packets, so it doesn't suffer from the macOS Catalina bug. Instead, it sends small mouse movements at a user-configurable interval to trick the remote host into thinking you're interacting with the session. Now, when this is enabled, and the interval is configured to a low enough interval, the TCP connection will not become idle and thus no keep-alive packets are ever sent, resulting in the connection staying alive.

To configure the keep-alive interval, open the properties of your Remote Desktop (RDP) connection and navigate to "Advanced - Connection". Enable "Keep-alive" and set the interval to 4 seconds.

If you have more than a handful of RDP connection that are affected by the bug, you might want to make use of our "Overrides" feature to globally enable keep-alive for all of your RDP connections.

Next Steps

As previously mentioned, we will submit a bug report to Apple soon and will update this blog post with any new information we're able to gather.

We also posted a detailed description of the problem on FreeRDP's Github issue tracker.

We're sorry about the inconvenience this causes for you and hope to have a permanent solution soon.

Previous Post