RDP does not work for any Windows clients

[billettg]

Describe the bug If you navigate to any Windows client then click the RDP Connect button and enter your RDP credentials, it shows setup, then disconnects immediately, for any client.

This was working perfectly up until a couple of weeks ago and VNC and terminal sessions work fine to both Windows, Mac and Linux clients, it's just RDP that now refuses to work.

I can RDP to all affected clients directly, and there are no restrictions or firewalls blocking the connection.

My domain has been replaced with example.com in any text below.

To Reproduce Steps to reproduce the behavior:

1. Go to ANY Windows client page
2. Click on RDP Connect
3. Enter RDP credentials
4. Setup is shown briefly
5. Disconnected is shown

Expected behavior RDP session to client.

Server Software (please complete the following information):

• OS: Ubuntu Server 22.04 LTS
• Virtualization: Docker (typhonragewind/meshcentral)
• Network: NPM reverse proxy and Cloudflare WAF (both of these bypassed, same issue)
• Version: 1.1.22 and 1.1.0
• Node version (inside container) v20.12.2

Client Device (please complete the following information):

• Device: Desktop / Server VM
• OS: Windows 11 / Server 2022 Standard
• Network: Local to MeshCentral - same subnet
• Browser: Google Chrome (tested in other browsers and Incognito)
• MeshCentralRouter Version: NA

Core info for Windows 11 client:

Current Core: Dec 9 2022, 3840084365
Agent Time: 2024-04-23 10:39:40.055+01:00.
User Rights: 0xffffffff.
Platform: win32.
Capabilities: 15.
Server URL: wss://mesh.example.com:443/agent.ashx.
OS: Microsoft Windows 11 Pro - 23H2/22631.
Modules: amt-apfclient, amt-lme, amt-manage, amt-mei, computer-identifiers, monitor-border, smbios, sysinfo, util-agentlog, wifi-scanner-windows, wifi-scanner, win-console, win-deskutils, win-info, win-securitycenter, win-terminal, win-virtual-terminal, win-volumes.
Server Connection: true, State: 1.
Application Location: C:\Program Files\Mesh Agent\

Additional context I have rebuilt MC completely from scratch and reinstalled Agents and the issue persists. All intermediate firewalls have been disabled for testing including Cloudflare proxy. No errors in the MC server log. I don't know if it's relevant but although I have the server in WAN mode and using an FQDN, all my clients are on my LAN and I have an A record on my DNS server which points my domain example.com to the server IP.

Tracing in MC server shows:

14:50:35 - RELAY: RDP: Browser websocket closed
14:50:35 - RELAY: RDP: Starting RDP client on loopback port 3934714:50:35 - COOKIE: Encoded AESGCM cookie: {"userid":"user//gareth","domainid":"","nodeid":"node//LOSr2aTNVmwMgBdoDvIR8whPNUgaw5caj2Go7V9XoZZmNMydo42EjbtijpNnGJ0U","tcpport":3389,"time":1713793835}
14:50:35 - RELAY: RDP: Request for RDP relay (172.21.0.1)

172 is the Docker subnet.

Docker-compose:

  meshcentral:
    container_name: meshcentral
    image: typhonragewind/meshcentral:latest
    environment:
      - REVERSE_PROXY=true
      - REVERSE_PROXY_TLS_PORT=443
    ports:
      - 4430:443
      - 800:80
    volumes:
      - ${docker}/meshcentral/data:/opt/meshcentral/meshcentral-data
      - ${docker}/meshcentral/user_files:/opt/meshcentral/meshcentral-files
      - ${docker}/meshcentral/backups:/opt/meshcentral/meshcentral-backups
    restart: always

Chrome developer network tab shows:

Request URL:wss://mesh.example.com/mstscrelay.ashx
Request Method:GET
Status Code:101 Switching Protocols

The NGINX proxy (Nginx Proxy Manager) points mesh.example.com to port 4430 (as this is mapped to 443 in Docker) and has HTTP/2 and websocket support enabled.

Your config.json file

{
  "settings": {
    "cert": "mesh.example.com",
    "wanonly": true,
    "port": 443,
    "aliasport": 443,
    "redirport": 80,
    "rediraliasPort": 80,
    "webrtc": true,
    "wscompression": true,
    "allowlogintoken": true,
    "trustedproxy": "CloudFlare",
    "tlsoffload": "127.0.0.1"
  },
  "domains": {
    "": {
      "newaccounts": false,
      "usernameisemail": true,
      "certurl": "https://mesh.example.com"
    }
  }
}

I have tested with different configurations including disabling wscompression, webrtc etc.

[billettg]

I rebuilt MC on another Linux box (Alpine) and it works now.

Any idea what the issue may have been?

[gitwittidbit]

I don't know what the issue might have been but I can report that I am experiencing similar issues:

I have xrdp installed on a linux VM and I can login remote using the MS Remote Desktop app (on my Mac). But I can't login via RDP from MC.

MC can connect to the linix VM (there is an MC agent installed and I can connect via the agent). The MC credentials screen goes black for a moment and then comes back. RDP from MC used to work a while ago.

[anthonyb800]

I have been experiencing the same exact issue over the last couple weeks. Also using the typhonragewind Docker image on Ubuntu 22.04 behind Nginx Proxy Manager, no Cloudflare proxy.

I ran the following tests (all through Nginx Proxy Manager, no Cloudflare proxy): Spun up an identical MC server in Docker with the typhonragewind image on a different Ubuntu 22.04 host - issue persisted immediately Spun up an identical MC server on Windows using NodeJS - issue did not occur Spun up an identical MC server in Docker with a custom image just using node as a base, installing, and running MC - issue did not occur

From what I've gathered, this issue only occurs with the typhonragewind Docker image. I can't say for sure if it is a combination of other things causing it, but that is what I have found.

Anyone else using the Docker image experiencing this as well? Curious what your setup looks like.

[si458]

@anthonyb800 have you tried using the offical docker github image? https://github.com/Ylianst/MeshCentral/pkgs/container/meshcentral

[anthonyb800]

Thank you for the link @si458 ! I can confirm the official image does not have this issue in my testing :)

[gitwittidbit]

I'm not using a docker image but the official npm install - if that makes a difference...

[gitwittidbit]

Is it better to open my own issue?

[sammyke007]

I can confirm that switching to official docker github image fixed the problem. I was also using typhonragewind's image...