You may want to look at xRDP protocol binding, when installing if IPv6
is enabled it will bind it services to it and ignore IPv4.
Solution is to disable IPv6 and reinstall xRDP
*Thank You*
Sean Hulbert
On 4/1/2026 2:48 AM, Nick Couchman wrote:
On Wed, Apr 1, 2026 at 3:20 AM Makarem Dandouna
<[email protected]> wrote:
Hello everyone,
I am trying to connect to a Linux VM from Guacamole using the
RDP protocol to access the desktop environment. I have two
different configurations:
1. *Direct Connection*:
Guacamole connects directly to the Linux VM using the RDP
protocol. The Linux VM has xrdp installed and running.
This configuration works well, and I can successfully
access the desktop of the VM.
2. *Indirect Connection via Gateway*:
In this configuration, the network flow is restricted, and
direct communication between Guacamole and the target VM
is not allowed for security reasons. To overcome this, I
am using a gateway as an intermediary. The gateway can
communicate directly with the Guacamole server over the
network and can also establish a connection to the target
VM through a Google IAP (Identity-Aware Proxy) tunnel.
Below is a simple schema explaining the architecture of
this solution.
*Architecture*:
* The Guacamole server communicates with the gateway
using the RDP protocol on port 4200.
* The gateway has an Nginx reverse proxy that binds port
4200 to the local port 9200.
* A gcloud command is used to open an IAP tunnel from
the local port 9200 on the gateway to the remote port
3389 on the target VM.
* The target VM has an xrdp client listening on port 3389.
Does this configuration work with other RDP clients, like xfreerdp or
the Microsoft Remote Desktop client? While Nginx is a fine reverse
proxy, my experience is that it only proxies HTTP/S and WebSocket/S
traffic, and is not a generic TCP/UDP proxy. The configuration you
have, here, appears to be attempting to use Nginx to proxy RDP
traffic, something that I do not believe Nginx is capable of doing. I
could be wrong about that, but you might want to try something like
HAProxy, instead, as that provides more generic TCP proxying
capabilities. Or, if port 9200 is being opened to tunnel through to
the RDP server, why not just allow Guacamole to connect directly to
that port instead of the tunnel through Nginx/HAProxy? Some clarity on
why you've decided to use Nginx, here, would be helpful.
Also, depending on how the Google IAP tunnel operates, and, in
particular, how long it takes for that tunnel to be established, I
could foresee some timing issues between that and the attempted RDP
connection.
*Error message on xrp side:*
In /var/log/xrdp.log
2026-03-27T15:41:47.626+0000] [INFO ] Socket 14: connection
accepted from [::ffff:35.235.240.96]:46875
[2026-03-27T15:41:47.629+0000] [INFO ] Using default X.509
certificate: /etc/xrdp/cert.pem
[2026-03-27T15:41:47.632+0000] [INFO ] Using default X.509 key
file: /etc/xrdp/key.pem
[2026-03-27T15:41:50.631+0000] [ERROR] libxrdp_force_read:
header read error
[2026-03-27T15:41:50.633+0000] [ERROR] [ITU-T X.224]
Connection Sequence: CR-TPDU (Connection Request) failed
[2026-03-27T15:41:50.634+0000] [ERROR] xrdp_sec_incoming:
xrdp_iso_incoming failed
[2026-03-27T15:41:50.635+0000] [ERROR] xrdp_rdp_incoming:
xrdp_sec_incoming failed
[2026-03-27T15:41:50.637+0000] [ERROR] xrdp_process_main_loop:
libxrdp_process_incoming failed
[2026-03-27T15:41:50.638+0000] [ERROR] xrdp_iso_send:
trans_write_copy_s failed
[2026-03-27T15:41:50.640+0000] [ERROR] Sending [ITU T.125]
DisconnectProviderUltimatum failed
*In the gateway side: *
The gcloud command that creates the iap tunnel is closed with
just the message killed
I can see in the logs of the reverse proxy :
connect() failed (111: Connection refused) while connecting to
upstream, client: <ip of guacamole server>, server:
0.0.0.0:4200 <http://0.0.0.0:4200>, upstream: "127.0.0.1:9200
<http://127.0.0.1:9200>", bytes from/to client:0/0, bytes
from/to client:0/0,bêtes from/to upstream:0/
You probably need to look at the guacd log output along with
increasing the verbosity of the Nginx logs to further diagnose this.
Also, please be aware that your output posted from your xrdp logs has
a public Internet IP address listed in it.
-NIck
