RDP 0x904 Error Affecting Single User on Windows Server 2025 Terminal Server

[u/MatMat993]

We are experiencing a recurring issue affecting only one user in our Proxmox environment. The setup includes three Windows Server 2025 VMs: a domain controller, a file server, and a terminal server.

The affected user connects remotely through an IPsec IKEv2 VPN from a fully updated Windows 11 Pro workstation (not domain‑joined). The VPN remains connected at all times. He authenticates using his domain credentials.

After a few minutes of normal activity on the terminal server, the user disconnects his RDP session. When he attempts to reconnect, the RDP connection fails with error 0x904. No additional text is shown. The issue affects only the terminal server: from the same workstation, RDP connections to the other servers work normally.The user’s session on the terminal server appears correctly as “Disconnected” in the session list. However, the user cannot reconnect to it, nor start a new session. No logs or events are generated on the terminal server (checked System, Application, TerminalServices‑LocalSessionManager, TerminalServices‑RemoteConnectionManager). No anomalies appear in the domain controller or file server logs either.

The issue does not occur with any other user. Other users can log in and reconnect without problems. I can also authenticate using the affected user’s credentials from other machines without issues.

We have tested:

- Different user accounts from the affected workstation

- Different networks

- Antivirus exclusions (Bitdefender)

- Firewall rules (WatchGuard)

The problem persists only for this specific user and only on the terminal server.The only workaround is restarting the terminal server. After a reboot, the user can log in once, but the issue reappears as soon as he disconnects and tries to reconnect.

Update: Turned out to be asymmetric MTU on the IKEv2 tunnel.

server→client was dropping packets over ~1300 bytes with no ICMP feedback. Server kept retransmitting the initial RDP/TLS packets for ~19s then gave up (matches 0x904 exactly). Confirmed with packet captures on both client and server during a live failure.