Summary
agent-rdp connect fails with TLS error: Connection reset by peer (os error 54) when the target is Windows Server 2008 R2 (RDP 6.x era, TLS 1.0 only). macOS's built-in Windows App (MSRDC) and FreeRDP connect to the same host without issue, so the constraint is on IronRDP's client-side TLS negotiation.
Environment
agent-rdp 0.6.3 installed via npm- macOS 15 (Darwin 25.2.0), Apple Silicon
- Target: Windows Server 2008 R2 SP2 (SQL Server 2008 R2 lab VM)
- TCP 3389 reachable; handshake initiated normally
Repro
$ agent-rdp --json connect --host 172.16.20.211 --username Administrator --password '***'
{"success":false,"error":{"code":"connection_failed","message":"TLS error: Connection reset by peer (os error 54)"}}
nc -z 172.16.20.211 3389 succeeds. openssl s_client -connect host:3389 shows the server does not accept TLS 1.2+ client-hello handshake the way IronRDP emits it.
Context
Red-team / database-compat test labs very frequently ship Windows Server 2003/2008/2008 R2 VMs — they're the "legacy driver / legacy protocol" targets that these labs exist to cover in the first place. These hosts cannot be upgraded past TLS 1.0 without replacing the OS, and enabling NLA does not help when the underlying TLS is already incompatible. Today the README's "target must have NLA enabled" line effectively excludes this entire class of targets. Meanwhile Microsoft's own Windows App and FreeRDP connect fine.
Ask
Any of the following would unblock agent-based automation against legacy Windows:
- Expose a
--security-layer {nla,tls,rdp} (or equivalent) flag mapping to IronRDP's negotiation preferences so the "Standard RDP Security" fallback is reachable.
- Opt-in
--allow-legacy-tls flag permitting TLS 1.0 / legacy cipher suites.
- Improve the error message to distinguish "peer rejected NLA/TLS 1.2+" from a generic
Connection reset by peer — right now this failure mode reads as a network glitch.
Happy to test any patch against a live Windows Server 2008 R2 target.
Summary
agent-rdp connectfails withTLS error: Connection reset by peer (os error 54)when the target is Windows Server 2008 R2 (RDP 6.x era, TLS 1.0 only). macOS's built-in Windows App (MSRDC) and FreeRDP connect to the same host without issue, so the constraint is on IronRDP's client-side TLS negotiation.Environment
agent-rdp0.6.3 installed via npmRepro
nc -z 172.16.20.211 3389succeeds.openssl s_client -connect host:3389shows the server does not accept TLS 1.2+ client-hello handshake the way IronRDP emits it.Context
Red-team / database-compat test labs very frequently ship Windows Server 2003/2008/2008 R2 VMs — they're the "legacy driver / legacy protocol" targets that these labs exist to cover in the first place. These hosts cannot be upgraded past TLS 1.0 without replacing the OS, and enabling NLA does not help when the underlying TLS is already incompatible. Today the README's "target must have NLA enabled" line effectively excludes this entire class of targets. Meanwhile Microsoft's own Windows App and FreeRDP connect fine.
Ask
Any of the following would unblock agent-based automation against legacy Windows:
--security-layer {nla,tls,rdp}(or equivalent) flag mapping to IronRDP's negotiation preferences so the "Standard RDP Security" fallback is reachable.--allow-legacy-tlsflag permitting TLS 1.0 / legacy cipher suites.Connection reset by peer— right now this failure mode reads as a network glitch.Happy to test any patch against a live Windows Server 2008 R2 target.