Intermittent SMB over QUIC Disconnects Despite UDP 443 Being Allowed

Question

Intermittent SMB over QUIC Disconnects Despite UDP 443 Being Allowed

Emily Johnson 45

Hello everyone,

We're seeing an issue where remote users can access SMB shares over QUIC initially, but the connection is lost shortly afterwards without any obvious network interruption. Since UDP port 443 is already open and routing appears to be functioning correctly, we're trying to determine whether a TLS 1.3 negotiation problem or certificate configuration could be causing the session to terminate. What logs or troubleshooting steps would help identify the root cause?

Many thanks

Emily

DC@CTD 91 Reputation points

2026-07-15T20:49:47.02+00:00

Started doing similar for me, but I'm using the 26H2 experimental channel. Noticed that MSFT did something with SMB/QUIC in the last month or two for the regular/public channel as well... running into random errors all of the sudden just mapping drives using QUIC transport... the workaround is to now specify the quicport as well. So annoying, but nothing as bad as what you and I are experiencing with the drops now introduced, which basically makes SMB QUIC unusable for now.
DC@CTD 91 Reputation points

2026-07-21T20:03:30.39+00:00

Might have a fix for you if the issue is still occurring: Set-NetAdapterRsc -IPv4Enabled $false -IPv6Enabled $false
That seemed to fix things up for me! Once disabled, after about 60 seconds connections reestablish and hold solid. If I revert that setting, chaos again. Hope that helps. Please share if it does.

Answer accepted by question author

0 additional answers

Your answer

DC@CTD 91 Reputation points

2026-07-15T20:49:47.02+00:00

Started doing similar for me, but I'm using the 26H2 experimental channel. Noticed that MSFT did something with SMB/QUIC in the last month or two for the regular/public channel as well... running into random errors all of the sudden just mapping drives using QUIC transport... the workaround is to now specify the quicport as well. So annoying, but nothing as bad as what you and I are experiencing with the drops now introduced, which basically makes SMB QUIC unusable for now.
DC@CTD 91 Reputation points

2026-07-21T20:03:30.39+00:00

Might have a fix for you if the issue is still occurring: Set-NetAdapterRsc -IPv4Enabled $false -IPv6Enabled $false
That seemed to fix things up for me! Once disabled, after about 60 seconds connections reestablish and hold solid. If I revert that setting, chaos again. Hope that helps. Please share if it does.

Answer 1

Hello Emily,

when SMB over QUIC sessions terminate shortly after initial connection, the most useful place to start is with the QUIC‑specific event logs. On the server, open Event Viewer and navigate to Applications and Services Logs\Microsoft\Windows\SMBClient\Connectivity and Microsoft\Windows\SMBServer\Connectivity. These logs capture QUIC handshake failures, TLS negotiation issues, and certificate validation errors. If the termination is tied to TLS 1.3, you will see explicit alerts about failed cipher suite negotiation or certificate trust chain problems.

You should also enable analytic and debug logs for SMB over QUIC. Run wevtutil sl Microsoft-Windows-SMBClient/Analytic /e:true and the same for Microsoft-Windows-SMBServer/Analytic. These channels provide detailed traces of QUIC packet flow and TLS session resumption. If the certificate presented by the server does not match the SPN or has an incomplete EKU (Server Authentication), the client will drop the session even though UDP 443 is open.

On the certificate side, confirm that the SMB over QUIC listener is bound to a certificate issued by a trusted CA, with the correct subject alternative names matching the DNS names clients use. You can check binding with netsh http show sslcert and verify that the certificate includes the 1.3.6.1.5.5.7.3.1 EKU. Misconfigured bindings or expired certs are a common cause of sessions dropping after initial handshake.

If you suspect TLS 1.3 negotiation, use Wireshark with QUIC decryption enabled to capture the handshake. Look for TLS Alert frames that indicate unsupported cipher suites or failed key exchange. This will confirm whether the disconnect is cryptographic rather than network‑level.

In short, the right troubleshooting path is to collect SMB over QUIC event logs, enable analytic channels, validate certificate bindings and EKU, and capture QUIC traffic to see if TLS alerts are causing the disconnect. That combination will pinpoint whether the issue is certificate trust, TLS 1.3 negotiation, or a driver‑level problem with the QUIC stack.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.