In this context it appears SMB on QUICQuic is a kind of modern "SMB VPN" that encapsulates the classic Windows file-sharing protocol within QUIC, using TLS 1.3 encryption and improved tolerance to unreliable networks, completely changing how we access shared resources over the internet. Throughout this article, you'll see, in considerable detail, how it works, what you need to set it up, how to manage it, and how to further strengthen the security of your environment.
What is SMB over QUIC and why does it change the game?
SMB on QUIC It is the evolution of SMB transport that replaces the classic TCP 445 with QUIC over UDP 443. Instead of exposing the traditional SMB port to the Internet, a secure tunnel is established with TLS 1.3 on top of QUIC, so that all packets are always encrypted and authenticated from the very beginning.
The QUIC protocol, standardized by the IETF, offers very clear advantages over TCPEncryption is mandatory in all packets, the handshake protocol uses authenticated TLS 1.3, it allows reliable and unreliable parallel flows on the same connection, it sends application data at 0-RTT to reduce initial latency, improves congestion control and drop recovery, and supports IP or port changes without dropping the session.
When we use SMB inside this QUIC tunnelSMB traffic—including authentication, authorization, and data—is never exposed in plain text to the underlying network. The client sees a standard SMB share, with multichannel access, signing, compression, high availability, directory leasing, and other common features, but everything travels encapsulated and encrypted over UDP port 443, which is much more compatible with firewalls and public networks.
In practice, SMB over QUIC provides a VPN specifically for files Designed for remote workers, mobile devices, branch offices, and organizations with high security requirements. The user works exactly as if they were on the internal network, but without setting up a general-purpose VPN and without opening port 445 to the outside.
An important point: SMB over QUIC does not activate itselfIt is the administrator who must enable it on the file server. SMB clients on Windows still use TCP by default and only attempt QUIC if TCP access fails first, or if the transport is explicitly forced with commands such as NET USE /TRANSPORT:QUIC or New-SmbMapping -TransportType QUIC.
Prerequisites for deploying SMB on QUIC
Before activating anything, you need to check the basic infrastructure requirementsIt's not particularly complicated, but it's still a good idea to be clear about it to avoid silly mistakes in production.
For SMB serverYou need to run an edition that supports QUIC, such as Windows Server 2022 Datacenter: Azure Edition or later, and configure it as an edge file server or similar. It can also be used in Azure On-premises scenarios and on future versions like Windows Server 2025.
On the side of customersWindows 11 Enterprise Edition is required, as the SMB capabilities over QUIC are designed for corporate environments. The device must be able to resolve the server's public name via DNS or, failing that, have it defined in its HOSTS file.
In terms of identity, the recommended scenario is that The SMB server and client are joined to an Active Directory domainThe server must be able to contact at least one domain controller for authentication, although these controllers do not need internet access. Workgroup configurations with local and NTLM accounts are also supported, as well as servers joined to Microsoft Azure IaaS, but with certain limitations on remote security operations.
Regarding connectivity, the server must be accessible from the Internet through its public interfacewith a firewall rule that allows incoming UDP/443 traffic. It is crucial not to expose TCP port 445 from the Internet; if you need alternative ports, Microsoft allows you to change the SMB port settings, but the general philosophy is: UDP 443 yes, TCP 445 no.
For the safety plan, a public key infrastructure (PKI) that issues valid certificates for the QUIC server. This can be Active Directory Certificate Services or a trusted external authority (DigiCert, GlobalSign, Let's Encrypt with the appropriate profile, etc.). And, of course, the administrator who will configure SMB on QUIC must have administrative privileges on the server.
Server certificate installation and preparation
The core of security in SMB over QUIC is the server TLS certificateWithout a properly issued and installed certificate, the QUIC tunnel will not be established correctly and the client will not trust the connection.
That certificate must meet several specific technical requirements: use of digital signature key, server authentication purpose (EKU 1.3.6.1.5.5.7.3.1), signature algorithm at least SHA256RSA, SHA256 hash or higher, and public key preferably ECDSA_P256 (although RSA with a minimum of 2048 bits is supported). Additionally, the Subject Alternative Name (SAN) must contain all the complete DNS entries that will be used to access the SMB server.
The certificate must include the associated private key and be issued by an entity that customers consider trustworthy. The issuer's CN field can be flexible, but the chain of trust must be valid and complete. In environments with a Microsoft corporate CA, it's common practice to create a specific template for SMB over QUIC and allow administrators to specify DNS names when requesting the certificate.
In scenarios with Microsoft Enterprise CA, the typical process involves opening MMC on the server, adding the certificate snap-in for the team account, and, in the Personal store, launching a application for a new certificateThe Active Directory enrollment policy is chosen, the appropriate template is selected, and the Subject and SAN fields are filled in with the DNS names that the clients will use.
Once registration is complete, the certificate will appear in the local equipment store. From that moment on, it can be used in both SMB on QUIC as well as in complementary functions such as the KDC proxy if it is decided to implement it later.
SMB configuration over QUIC on the server
Once you have the certificate ready, it's time to Activate and configure SMB over QUICMicrosoft allows you to do this from either Windows Admin Center (WAC) or PowerShell, depending on your preferences and system version.
By enabling the feature, the server associates the TLS certificate selected for the QUIC endpoint which will listen on UDP 443. From that moment on, clients capable of using SMB over QUIC will be able to establish an encrypted tunnel to the server as long as they resolve the certificate's DNS name and can reach port 443/UDP.
Windows Admin Center usually has a "Configure" or similar button for SMB on QUIC. However, there are reported cases where the button is unresponsive, typically due to outdated versions of WAC, broken extensions, or unmet requirements (For example, the machine might not be Azure Edition, roles might be missing, or the certificate might be invalid.) In these cases, it's recommended to check versions, verify that the server meets the requirements, and, if necessary, proceed with configuration via PowerShell.
In addition to the basic configuration, it is possible apply access policies to limit which clients can use QUIC, combine it with Azure Automanage to manage certificates and monitor configuration status, and link it with other advanced features such as client access control and KDC proxy.
Connecting clients to shared SMB resources over QUIC
For the end user, the idea is that access should be as easy as possible. transparent and familiar It's possible, as if it were within the corporate network. However, there are several configuration points that should be reviewed.
The first step is to join the Windows 11 device to the domain (if applicable) and ensure that the DNS names of the server defined in the SAN of the certificate These correspond to valid entries in DNS or the HOSTS file. From outside the internal network, the client will no longer see the private IPs, so the published external name must be used, or alternatively, Use OneDrive to share files in scenarios where publishing SMBs is not feasible.
When testing, it's advisable to move the equipment to a external network where there is no direct access to the domain or internal IPsThis verifies that access is actually made through QUIC and not via the classic LAN route.
From Windows File Explorer, you can type the UNC path to the shared resource, such as \\fsedge1.contoso.com\ventas, and confirm that you can access it without problems. If you want to explicitly force the use of QUIC, you can use commands like NET USE /TRANSPORT:QUIC o New-SmbMapping -TransportType QUIC, indicating the desired UNC path.
For example, a mapping command can first attempt TCP and, if that fails, switch to QUIC, or it can be limited exclusively to QUIC. New-SmbMapping also makes this simple. assign drive letters to remote resources, something very convenient for the user who is used to working with classic network drives.
SMB audit and administration through QUIC
Once SMB over QUIC is operational, it is essential to have Visibility into who is connecting, how, and from whereTo achieve this, Microsoft has incorporated auditing capabilities on both the client and server sides.
In Windows 11 (starting with version 24H2), the SMB client includes specific events for the QUIC transport. The Event Viewer allows you to view these logs in the path Application and Services Logs\Microsoft\Windows\SMBClient\Connectivity, where events such as ID 30832 related to SMB connections over QUIC are generated.
On the SMB server, you can activate a more detailed audit by running Set-SmbServerConfiguration -AuditClientCertificateAccess $trueFrom that moment on, the logs Applications and Services Logs\Microsoft\Windows\SMBServer\Audit show events that report whether access was allowed or denied, including client certificate data (subject, issuer, serial number, SHA1 and SHA256 hash) and the access control rules that have been applied.
These events incorporate a connection identifier This makes it easier to correlate what is seen on the client with what is recorded on the server, greatly simplifying troubleshooting tasks when something fails or when you want to review suspicious behavior.
Optional use of KDC proxy to maintain Kerberos
By design, when a client connects from the Internet to a SMB server on QUICIt typically does not have direct access to Active Directory domain controllers. In that scenario, authentication tends to fall back to NTLMv2, with the file server authenticating on behalf of the client, always within the QUIC tunnel encrypted with TLS 1.3.
Although NTLMv2 is protected inside the tunnel and does not exit to the network in clear text, good security practices recommend continue using Kerberos Whenever possible, avoid creating new NTLMv2 dependencies. This is where the KDC proxy comes in, forwarding Kerberos ticket requests on behalf of the user over an internet-compatible HTTPS channel.
To configure it, the following are first created on the file server: HTTP URL reservations for the proxy service Using NETSH, the KPSSVC service registry values are adjusted to allow the desired authentication type, and the SMB certificate fingerprint over QUIC is bound to the HTTPS endpoint 0.0.0.0:443 with Add-NetIPHttpsCertBinding.
It is also necessary to add Alternative names for the SMB server over QUIC, such as SPN In Active Directory, for example using NETDOM, so that the server can correctly represent the service identity in Kerberos. Finally, the KDC proxy service is set to automatic startup and started.
On the client side, a group policy is configured in Computer Configuration\Administrative Templates\System\Kerberos\Specify KDC proxy servers for Kerberos clients, where the internal domain (e.g., corp.contoso.com) is mapped to the external HTTPS URL of the QUIC server (e.g., https fsedge1.contoso.com:443:kdcproxy/). This way, the client knows that if a user from that domain connects to an externally published file server, they should Use the KDC proxy to get the tickets.
Certificate lifecycle management in SMB on QUIC
Certificates don't last forever, and in the case of SMB on QUICEach renewal brings with it a new digital fingerprint. Even if automatic renewal mechanisms are used with Active Directory Certificate Services, the fact that the fingerprint changes means that the certificate assignment in the QUIC configuration must be updated.
When the certificate is about to expire or is being renewed, you must reselect the certificate in Windows Admin Center For the existing configuration, or run the PowerShell cmdlet Set-SMBServerCertificateMapping pointing to the new fingerprint. If this step is omitted, SMB connectivity over QUIC may be unexpectedly interrupted.
To avoid surprises, Microsoft recommends supporting this management with tools such as Azure Automanage for Windows ServerThis system monitors the status of certificates and alerts (or even corrects) issues before a service outage occurs. In high-availability and critical remote access environments, this makes all the difference.
Customer access control with certificates
Beyond simple authentication, SMB over QUIC can also apply client certificate-based access controlIt is an additional layer of security that restricts which devices can establish a QUIC tunnel with the server, even if they know the credentials.
The process works as follows: the server requires the client to present a valid and trusted certificate chainFrom that chain, an access control list is checked which may contain permission or block entries, both for specific certificates (identified by their SHA256 hash) and for complete issuers (intermediate or root CAs).
For this to work, the client authentication requirement is first enabled with Set-SmbServerCertificateMapping -RequireClientAuthentication $trueNext, the registration of allowed or blocked client certificates begins using cmdlets such as Grant-SmbClientAccessToServer, Revoke-SmbClientAccessToServer, Block-SmbClientAccessToServer, and Unblock-SmbClientAccessToServer.
This model allows, for example, authorize an entire corporate CA And, at the same time, deny access to a specific certificate that is considered compromised. Or vice versa: block an entire CA but authorize a very specific individual certificate. Denial rules take precedence over permission rules, which helps to mitigate risks.
From the customer's point of view, it is sufficient to have a certificate issued for client authentication installed in their local store (EKU 1.3.6.1.5.5.7.3.2) by a CA trusted by the server. The administrator can retrieve the certificate fingerprint or Subject from PowerShell (Get-ChildItem Cert:\LocalMachine\My, filters by Subject, etc.) and use it later to configure the access list on the server.
Connectivity testing and troubleshooting
A good practice when implementing SMB on QUIC is to follow a series of controlled tests before opening it to the entire organization. This way, certificate, DNS, or firewall problems are detected early, and guides can be consulted when necessary. troubleshoot file access problems.
From the client, you can start with an explicit mapping using `NET USE \\server\resource /TRANSPORT:QUIC` or `New-SmbMapping -RemotePath \\server\resource -TransportType QUIC`. If instead of connecting you receive a message that the server has denied access, it's probably because... Certificate assignment and QUIC tunnel reception are workingHowever, client access control needs to be configured or permissions need to be reviewed.
In parallel, it is important to review the client connectivity event logs and server audit discussed earlier. There you will see both successful and failed attempts, with detailed information about the certificate chain and the rules that were applied in each case.
It's also advisable to check from the server that the firewall rules They allow inbound UDP 443 and TCP 443 for scenarios where KDC proxy or other associated HTTPS services are used, and that TCP 445 has not been accidentally exposed to the Internet.
Best practices for SMB traffic segmentation and isolation
Although SMB over QUIC provides robust protection for file traffic over the Internet, it is still advisable to implement segmentation and isolation techniques to reduce the attack surface between devices on the network.
A basic guideline is block incoming TCP port 445 from the Internet on perimeter firewalls. If you need to expose file resources at the perimeter, the secure option is to publish them using SMB over QUIC on UDP port 443, not by directly opening a classic SMB connection.
Conversely, blocking outbound TCP port 445 to the Internet prevents internal computers from sending SMB data to uncontrolled external servers. Only in very specific scenarios such as Azure Files or Office 365 It may be necessary to allow this traffic, and even then it is recommended to channel it through VPNs or very strict rules by IP ranges.
In networks with many devices, it's worth doing a inventory of actual SMB usageThis involves analyzing which servers actually need incoming SMB, which clients require file sharing, and from which subnets each server is accessed. Tools like Get-FileShareInfo can be used for this purpose, as well as enabling file share audits for a limited time to observe which resources are in use.
Based on this analysis, much more precise inbound and outbound firewall rules can be designed, blocking unnecessary SMB traffic and limiting the lateral movements of a potential attacker within the network.
Reinforcement with Windows Defender Firewall and IPsec
Windows Defender Firewall with advanced security acts as second line of defense around SMB traffic. Rules can be created to block incoming and outgoing connections by default, allowing only the necessary exceptions for domain controllers, file servers, and critical services.
A common strategy is to define outbound rules that prevent the use of SMB to any destination except one allowed list Based on IPs or names, with the action "Allow connection if secure". This option can be customized to use Kerberos authentication and null encapsulation in IPsec, forcing only authorized domain users and computers to take advantage of these exceptions.
For this approach to work, it is essential to create connection security rules on all involved devices, so that firewall exceptions are based on IPsec. Otherwise, the blocking could end up being arbitrary or inconsistent.
In recent versions such as Windows 11 24H2 and Windows Server 2025, Microsoft has adjusted the built-in firewall rules to stop automatically opening ports NetBIOS (137-139) when creating SMB2 or higher shared resources, reflecting a stricter policy aligned with modern deployments.
In environments where SMB1 is no longer relied upon, it is highly recommended. close these legacy portsOnly in cases of exceptional compatibility should they be reopened manually, preferably limiting the scope through very specific rules.
Disable the SMB server where it is not needed
Many Windows clients and some servers on the network don't actually need the SMB server service active, since they never share files with other computers. Keeping the service enabled unnecessarily only expands the attack surface.
Before disabling it, it's advisable to check if any applications or processes depend on it. Once verified, the SMB server service can be disabled on selected computers, for example with group policy preferences that apply this configuration in a massive and controlled manner.
This measure, combined with SMB over QUIC for remote access and well-tuned firewall rules, helps build a much more robust file sharing architecturewhere only the nodes that need to expose SMB do so, and in the most secure way possible.
SMB over QUIC allows offering remote users, branches, and mobile devices a access to encrypted files, resistant to unstable networks and without the need for traditional VPNs, while the certificate tools, client access control, KDC proxy, firewall and network segmentation provide the necessary scaffolding for this “SMB VPN” to work reliably and with security guarantees in real environments.
