[FEATURE] Support local Connection Origin for RDP/VNC/Telnet on Desktop

Title

Allow RDP/VNC/Telnet connections to originate from the Desktop client

Platform

Desktop App - Windows / macOS / Linux

Is it related to an issue?

The Termix server and the Termix Desktop client may have access to different networks.

For example:

• Termix Server cannot reach an internal RDP/VNC/Telnet host.
• Termix Desktop is running on a computer that can reach the host directly.
• The same host is therefore reachable from the Desktop client, but not from the Termix server.

For SSH hosts, Termix Desktop already provides the "Connection Origin" option:

• Default
• This Device
• Remote Server

This makes it possible to choose whether the connection should originate from the local Desktop client or from the remote Termix server.

RDP/VNC/Telnet do not currently provide the same behavior. In the current Desktop Beta, these connection types are effectively forced to use the remote server.

As a result, an RDP/VNC/Telnet host may be perfectly reachable from the user's computer but impossible to open in the embedded Termix client because the Termix server/guacd cannot reach it.

A common example would be:

Termix Desktop
    |
    | can reach
    v
Internal RDP/VNC/Telnet host

Termix Server / guacd
    |
    | cannot reach
    X
Internal RDP/VNC/Telnet host

The Solution

Extend the existing "Connection Origin" functionality to RDP, VNC and Telnet connections on the Desktop app.

Ideally, these protocols should support the same per-host options already available for SSH:

• Default
• This Device
• Remote Server

For example:

Remote Server

Termix Desktop
    -> Termix Server
    -> guacd / protocol backend
    -> RDP/VNC/Telnet host

This Device

Termix Desktop
    -> local protocol backend/transport
    -> RDP/VNC/Telnet host

The exact implementation does not necessarily need to use the same backend architecture as SSH.

For embedded RDP/VNC, one possible implementation could be a local guacd instance or another local transport bundled/managed by the Desktop application.

For Telnet, a local transport could similarly be used when "This Device" is selected.

The important part from the user's perspective is that selecting "This Device" causes the actual connection to originate from the machine running Termix Desktop, whether the Desktop client is running on Windows, macOS or Linux.

The existing global/default Connection Origin setting could also apply, with a per-host value overriding it just as it does for SSH.

This would allow Termix Desktop to access hosts that are available only from the local network without requiring network connectivity from the central Termix server.

Additional Context

On Windows, there is currently a partial workaround for RDP: opening the host using "Windows Remote Desktop".

This works in my scenario because the native Windows RDP client originates the connection from the Desktop PC, which has network access to the destination host.

However, it is not equivalent to using the embedded Termix RDP client.

There are also usability issues with this workaround.

When launching a host using "Windows Remote Desktop", Windows first displays the Remote Desktop security warning and then asks for credentials again.

This happens even though the RDP username and password are already configured for the host in Termix.

So the current workflow is approximately:

1. Open the host in Termix.
2. Select "Open in Windows Remote Desktop".
3. Confirm the Windows RDP security warning.
4. Enter the username/password again.
5. Connect.

Ideally, Termix could also improve this fallback by passing the configured username and securely providing the saved credentials to the native Windows RDP client where possible.

For example, an implementation could potentially use Windows Credential Manager for the target host before launching the native RDP client and remove the temporary credential afterwards, rather than exposing the password on the command line.

However, improving the native Windows RDP launcher is secondary to this feature request.

The main request is to support a true local "Connection Origin = This Device" for embedded RDP/VNC/Telnet sessions on Windows, macOS and Linux, similar to the functionality already available for SSH.

Start by tracing the existing SSH Connection Origin implementation in the Desktop app, then compare how embedded RDP, VNC and Telnet sessions currently connect. Done means Default, This Device and Remote Server work per host and globally, with This Device originating embedded sessions from Windows, macOS and Linux; the issue suggests local guacd or another local transport as possible approaches.