KB5127936 (build 26300.9818) breaks Remote Desktop through Barracuda SSL VPN local tunnel (error 0x204)

Question

KB5127936 (build 26300.9818) breaks Remote Desktop through Barracuda SSL VPN local tunnel (error 0x204)

khaled awik 0

After installing the optional preview update KB5127936 (OS build 26300.9818, Windows 26H2 Pro) on 29/10/2026, Remote Desktop connections launched through the Barracuda SSL VPN Agent stopped working. Uninstalling KB5127936 (rollback to KB5127648) immediately fixed the problem.

Setup:

Barracuda SSL VPN Agent creates a temporary local TCP tunnel on 127.0.0.1:<random port> and launches mstsc.exe pointing to 127.0.0.1:<port>.
The remote RDP host does not support TLS (event 1028: "Server supports SSL = not supported"); the .rdp uses "negotiate security layer:i:1", "authentication level:i:0", "EnableCredSSPSupport:i:0".

Behavior with KB5127936 installed:

Event 1024: "RDP ClientActiveX is trying to connect to the server (127.0.0.1)"
About 2 seconds later, Event 1026: "RDP ClientActiveX has been disconnected (Reason= 1289)". Event 1028 (SSL negotiation) never occurs.
The client retries, and about 16 seconds later: Event 226 "RDPClient_TCP: ... TcpEventConnectionTimeout (error code 0x80004004)", followed by Event 1026 Reason= 516.
mstsc displays: "Remote Desktop can't connect to the remote computer", Error code: 0x204, Extended error code: 0x0.
The VPN tunnel itself remains established, only the RDP loopback session fails.

Behavior after uninstalling KB5127936:

The connection succeeds immediately (events 1024 -> 1028 SSL not supported -> 1025 connected -> 1027 connected).
Note: mstscax.dll is version 10.0.26100.8875 both before and after uninstalling KB5127936, so the issue appears to originate from a networking, loopback, or TLS fallback regression introduced in KB5127936 rather than mstscax.dll itself.

Steps to reproduce:

Install KB5127936 on Windows 11.
Launch an RDP connection via local tunnel (127.0.0.1) using standard RDP security.
mstsc fails with error 0x204.
Roll back KB5127936, and the connection works immediately.

0 comments

2 answers

Your answer

Answer 1

Keep KB5127936 removed and remain on KB5127648 until Microsoft or Barracuda supplies a corrected build, because the available Microsoft release information does not document this Barracuda localhost-tunnel failure or provide a matching Known Issue Rollback.

KB5127936 is an optional non-security preview update for Windows 11 25H2/26H2, so deferring it is the appropriate short-term mitigation rather than changing a previously working RDP security configuration.^1^

Recommended mitigation

Leave the affected clients on KB5127648 / build 26300.9711, where the tunnel works.^2^
In Settings > Windows Update, pause updates temporarily so KB5127936 is not immediately offered again.
If updates are centrally managed, do not approve this optional preview for clients that use Barracuda SSL VPN published RDP resources. Optional updates are not enabled by default under Windows Update client policies unless the organization enables them explicitly.^3^
Continue installing the next applicable security cumulative update only after testing the Barracuda loopback-RDP workflow on a pilot device.

There is no documented KIR for this symptom. Do not deploy the KIR mentioned in other October release-health entries: that rollback addresses a different black-screen/Explorer issue, not localhost RDP through Barracuda.

What the evidence establishes

The published Remote Desktop issue associated with earlier builds is not this case. It affects non-admin users connecting to hosts with Administrator protection and produces 0xC000000D; KB5127936 is documented as resolving that issue.^4^

Your failure instead occurs before event 1028 and ultimately records disconnect reason 516 (0x204). Microsoft defines reason 516 as disconnectReasonSocketConnectFailed, meaning the Winsock connect call failed.^5^ That supports locating the break at the client-to-local-tunnel connection stage, but it does not establish whether Windows networking, a filtering component, or Barracuda’s local listener is responsible.

The controlled result—

same device and Barracuda workflow,
failure only on build 26300.9818,
immediate success after returning to build 26300.9711,
tunnel remaining established,
unchanged mstscax.dll version—

is sufficient to report a reproducible post-update compatibility regression. It is not necessary to repeat generic checks for port 3389, remote-host firewall rules, RDP enablement, or VPN establishment.

Capture a support-ready reproduction

Use one test device where KB5127936 can be reinstalled temporarily. Capture the failing and working states using the same Barracuda bookmark and remote host.

Download and extract Microsoft’s TroubleShootingScript (TSS) tool.
Open an elevated PowerShell window on the RDP client.
Start the RDP-client scenario:

Set-ExecutionPolicy -Scope Process Bypass
cd C:\Path\To\TSS
.\TSS.ps1 -Scenario UEX_RDScli
# Wait for the reproduction prompt.
# Launch the Barracuda-published RDP connection.
# Stop collection immediately after error 0x204.

Microsoft documents UEX_RDScli for RD-client investigation and recommends collecting client and server data when reproducing an issue.^6^

Include:

the generated TSS archive;
exported TerminalServices-ClientActiveXCore event log;
exact timestamps for events 1024, 1026, and 226;
winver output for both builds;
the .rdp file with hostnames and credentials removed;
Barracuda Agent version and diagnostic logs;
the generated loopback port;
failing and successful packet traces, if permitted;
confirmation that mstscax.dll remains 10.0.26100.8875.

Submit the reproduction through Feedback Hub > Report a problem, select Recreate my problem, record the failure, attach the sanitized logs, and retain a local copy of the diagnostics.^7^ Provide the resulting feedback link to both Microsoft Support and Barracuda Support so each vendor can correlate the same trace and timestamps.

Avoid weakening the remote host’s security settings further: the failure precedes the logged SSL-negotiation stage, so changing negotiate security layer, CredSSP, or certificate settings is not currently supported as a remedy.

References

Answer 2

Welcome to Microsoft Q&A!

Thank you for providing such a detailed investigation, particularly the event sequence, RDP configuration, mstscax.dll comparison, and the before-and-after testing with KB5127936.

I appreciate the time you have taken to isolate the behavior, and the rollback test is especially helpful in narrowing down where the issue occurs.

Based on the behavior you described, the failure appears to occur very early in the RDP connection and security-negotiation sequence, before the connection reaches the point where the remote RDP host's security capabilities are evaluated.

With negotiate security layer:i:1, RDP uses negotiation to determine a security protocol supported by both the client and server. Microsoft documents this negotiation-based sequence as one in which the client advertises the security packages it supports and the server selects the package to use.

The important difference in your traces is that, with KB5127936 installed, the connection reaches Event 1024 for 127.0.0.1 but disconnects before Event 1028 occurs. After KB5127936 is removed, the expected sequence continues through Event 1028 and the RDP session connects successfully.

Considering that:

the Barracuda SSL VPN tunnel itself remains established,
the failure occurs when MSTSC connects through the local 127.0.0.1:<port> tunnel,
RDP negotiation does not progress to Event 1028 with KB5127936 installed,
uninstalling KB5127936 immediately restores the connection, and
the reported mstscax.dll version is unchanged,

Your testing provides strong evidence of an update-dependent compatibility issue in the Windows client-side RDP/network/security path used with the Barracuda local tunnel.

However, I would be cautious about concluding that this is specifically a TLS fallback, loopback, or mstscax.dll regression. The available events show where the connection stops, but they do not provide enough information to identify the underlying Windows component responsible for the failure.

At this time, the published documentation for KB5127936 does not document this particular Barracuda SSL VPN/local-loopback RDP scenario as a known issue. Therefore, based on the information currently available, I cannot confirm that this is an officially recognized Windows regression.

Since KB5127936 is a Preview update and you have already confirmed that removing it restores the connection, I recommend remaining on the previous working Windows build and not reinstalling KB5127936 on the affected systems for now.

I would not recommend weakening or changing the RDP security configuration as a workaround, particularly because Microsoft recommends using Network Level Authentication where the environment supports it.

When the next cumulative Windows 11 update that supersedes KB5127936 becomes available, test it first on one non-production device using the same Barracuda 127.0.0.1:<port> tunnel.

I suggest keeping the validation as close as possible to your existing test:

Barracuda tunnel → MSTSC to 127.0.0.1 → compare the TerminalServices RDP client events

If the connection progresses through Event 1028 again and the RDP session succeeds, that would indicate that the compatibility issue is no longer present on the newer Windows servicing level.

If the same behavior remains reproducible on the latest cumulative update, further investigation would require deeper diagnostic traces and product-level analysis.

This is also where I would like to be transparent about the limitation of Microsoft Q&A. Microsoft Q&A can help analyze the documented behavior, review the evidence, and suggest troubleshooting based on publicly available Microsoft documentation. However, the forum does not provide the product-level diagnostic access required to determine exactly which Windows component changed in KB5127936 or to confirm an undocumented Windows defect.

Because your scenario shows a reproducible difference between Windows builds while also involving a third-party Barracuda VPN tunnel, a definitive root-cause determination would need to be investigated through an official Microsoft support case, with Barracuda support involved if necessary. Your update → rollback → retest results, together with the TerminalServices event sequence you have already collected, would be valuable evidence for that investigation.

I understand that this may not provide the definitive confirmation you were hoping for, especially when you are planning a production deployment. However, I would rather be transparent about what the available evidence supports and what cannot yet be confirmed than present an assumption as an established Microsoft product issue.

I hope this helps clarify the likely scope of the problem and gives you a safe path forward while waiting for the next servicing update.

References: October 28, 2026— KB5127936 (OS Builds 26300.9818 and 26200.9818) Preview | Microsoft Support

[MS-RDPBCGR]: Security-Enhanced Connection Sequence | Microsoft Learn

Credential Security Support Provider - Win32 apps | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.