SMB over QUIC: File Shares Without a VPN

Three years ago, if someone had told me we’d be handing out corporate file shares over the internet with no VPN, I’d have tapped my temple. File access from outside meant either IPSec/SSL VPN with its ritual dance, or workarounds like WebDAV and SFTP. Raw SMB straight to the internet? Only for the truly reckless. But it’s 2025, and the rules have changed.

SMB over QUIC has stopped being an Azure-edition curiosity and become a standard feature of Windows Server 2025. And with the release of Samba 4.23, this technology has become genuinely cross-platform. You can now give secure, stable, controlled file access on both Windows and Linux servers through plain old port 443/UDP.

In this article we’ll break down how it works, set it up step by step on both platforms, and build a checklist for migrating off VPN. No marketing fluff — just practice, commands, and the gotchas.

Prologue: the pain of a remote branch and the magic of RDP copy-paste

I think every admin has that one “cursed” branch office. I had one. A small office where the ISP blocked everything except ports 80/443. VPN was out of the question — “too expensive, too complicated, and it’s just three accountants over there.”

For years, working with files there looked like an elaborate form of torture:

1. RDP into the terminal server at the head office.
2. Find the document on the shared drive.
3. Copy it.
4. Minimize the RDP window, paste it onto the local desktop.
5. …and pray the session didn’t drop halfway through a 200 MB report.

When files were too big for the clipboard trick, corporate email with giant attachments took over, clogging up inboxes. Any attempt to mention “let’s just forward port 445” ran straight into a wall from both security and the ISP.

The fix arrived with upgrading the file server to Windows Server 2025. We issued it a certificate, opened 443/UDP outbound, and enabled SMB over QUIC with one command. That same evening, branch users just opened \files.company.comcommon in File Explorer and… it worked. No VPN, no drops, decent speed. To them it looked like magic. To us, it looked like the logical next step in engineering.

Why QUIC is the “SMB VPN” we’ve been waiting for

In short, QUIC is a modern transport protocol built on UDP, originally designed to speed up the web (HTTP/3), which turned out to be a great fit for other jobs too.

What makes it better than classic TCP for accessing files over the internet?

• Encrypted by default: QUIC is inseparable from TLS 1.3. All traffic is encrypted from the moment the connection is established. No need to separately configure IPsec or SMB Encryption.
• Runs over port 443/UDP: This port is almost never blocked by ISPs or corporate firewalls, unlike 445/TCP.
• Survives network changes: A user on a laptop can switch from Wi-Fi to LTE, their IP changes, and the QUIC connection doesn’t drop. TCP would stall in the same situation.
• Fixes head-of-line blocking: Losing one packet in a TCP stream stalls everything else behind it. In QUIC, streams are multiplexed, so losing data in one doesn’t block the others. This makes connections over shaky internet noticeably more responsive.

Microsoft isn’t exaggerating when it calls this technology an “SMB VPN.” It gives you a secure tunnel for file access, without needing to configure and maintain a full VPN client.

Hands-on #1: setting up Windows Server 2025

Let’s get to it. Setup on the Windows Server 2025 side is almost laughably simple, but demands attention to detail.

Step 0: prep

1. Server: You need Windows Server 2025, any edition (Standard or Datacenter).
2. Certificate: You need an SSL certificate (from a public CA or your own internal one) whose Subject Alternative Name (SAN) lists your file server’s FQDN (e.g. files.company.com). Never use IP addresses in the certificate! That forces a fallback to NTLM authentication. The EKU (Enhanced Key Usage) field must include Server Authentication.
3. Firewall: Open inbound UDP 443 on the server’s external interfaces. At the same time, external TCP 445 must stay closed.

Step 1: bind the certificate and enable QUIC

Log into the file server and open PowerShell as administrator.

PowerShell

# 1. Find our certificate in the LocalMachineMy store
$cert = Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -match "files.company.com"}

# 2. Bind (map) this certificate to the SMB server for use with QUIC
New-SmbServerCertificateMapping -Name files.company.com -Thumbprint $cert.Thumbprint -StoreName My

# 3. Enable SMB over QUIC on the server
Set-SmbServerConfiguration -EnableSMBQUIC $true

That’s it — the server is ready to accept connections.

Step 2: connecting a client

On the client machine (Windows 11 or Server 2025) you can connect as usual, and the system will automatically try QUIC if TCP/445 is unreachable. But to be sure, you can specify the transport explicitly:

PowerShell

# Map a network drive, forcing QUIC as the transport
New-SmbMapping -LocalPath Z: -RemotePath \files.company.comcommon -TransportType QUIC

Or good old net use:

DOS

net use Z: \files.company.comcommon /TRANSPORT:QUIC

Step 3: the “kill switch” and auditing 🕹️

If something goes wrong, you can always disable QUIC on the client for troubleshooting:

PowerShell

# Completely disable QUIC on the client
Set-SmbClientConfiguration -EnableSMBQUIC $false

The same setting is available via GPO. To monitor connections, check the event log: Applications and Services Logs > Microsoft > Windows > SMBClient > Connectivity. A successful QUIC connection is logged as event ID 30832.

Maximum security: Client Access Control (CAC) 🛡️

Just enabling encrypted access is good. Controlling exactly who can connect is better. This is where Client Access Control comes in — allowing or blocking access based on client certificates.

This is the ideal scenario for corporate laptops: you issue them certificates via auto-enrollment and allow access only to those. A random device off the internet, even knowing a valid login and password, won’t be able to connect.

Here’s how to set it up:

PowerShell

# On the server: require clients to present their certificate
Set-SmbServerCertificateMapping -Name files.company.com -RequireClientAuthentication $true

# Enable auditing so access decisions show up in the logs
Set-SmbServerConfiguration -AuditClientCertificateAccess $true

# Now create a rule. For example, allow access for a client with a specific certificate
# (you can get the hash from the client certificate's properties)
Grant-SmbClientAccessToServer -Name files.company.com -IdentifierType SHA256 -Identifier "client_cert_hash"

# View all the rules
Get-SmbClientAccessToServer -Name files.company.com

Audit events land in SMBServerAudit (ID 3007-3009). There are also commands for blocking (Block-SmbClientAccessToServer). This is a genuinely powerful tool that turns your file server into an actual fortress.

Hands-on #2: taming Samba 4.23 on Linux

Historically, Samba and Windows have moved in lockstep, and SMB over QUIC support is no exception. As of version 4.23, it’s here.

Step 0: prep

1. Version: Make sure you’re on Samba 4.23 or newer.
2. Dependencies: The official docs note that the server side needs kernel-level QUIC support on Linux. The client side can work through userspace libraries. Check your distro’s documentation for specifics.
3. Certificates and firewall: Same requirements as Windows: a valid certificate (key+cert+ca) and open 443/UDP.

Step 1: configuring smb.conf

Open /etc/samba/smb.conf and add a couple of new parameters to the [global] section:

Ini, TOML

# /etc/samba/smb.conf (fragment)

[global]
   # Add QUIC to the list of allowed transports. Keep TCP for the local network.
   server smb transports = tcp, quic

   # If this machine will also act as a client, set it here too
   client smb transports = tcp, quic

   # TLS settings needed for QUIC
   tls enabled = yes
   tls keyfile  = /etc/samba/ssl/server.key
   tls certfile = /etc/samba/ssl/server.crt
   tls cafile   = /etc/samba/ssl/ca.crt

   # ... the rest of your global settings

[common]
   path = /srv/samba/common
   read only = no
   # ...

After saving the config, restart the Samba services (smbd and nmbd). The server is ready — Windows clients will be able to connect by FQDN exactly like they would to Windows Server.

VPN migration checklist and common pitfalls

Switching to SMB over QUIC doesn’t mean you need to throw out VPN immediately. It’s just a different tool for a specific job.

When it’s worth switching:

• Remote employees and branch offices: the main scenario this was built for.
• Access from mobile devices: surviving network changes is the killer feature.
• Simplifying infrastructure: if VPN was only there for file access, you can drop it.

When you shouldn’t disable TCP/445:

• Inside the local network: TCP transport is still faster and simpler for internal traffic. QUIC gives you nothing extra here.
• Legacy clients: old Windows versions or third-party clients may not support QUIC.
• DFS-N setups: Be careful! External clients may not resolve internal DFS target names. Microsoft is working on this, but for now it’s a known limitation.

Common pitfalls (and how to avoid them): 🧐

1. “It doesn’t work by name!” — 99% of issues live here. Check:
   • The server’s DNS name resolves correctly to the external IP.
   • That same FQDN is listed in the certificate’s SAN.
   • You aren’t trying to connect by IP address.
2. “It’s slower than VPN” — Check MTU and any UDP traffic shaping policies along the whole path. Some ISPs throttle UDP.
3. Kerberos issues — For “clean” Kerberos authentication from outside, Microsoft recommends deploying a KDC Proxy. Without it, authentication most likely falls back to NTLMv2 (inside the encrypted TLS tunnel, so it’s still secure, but still).
4. Samba won’t start with QUIC enabled — Check the version, that the required libraries and kernel modules are present, and file permissions on the certificate files.

Epilogue: the future is already here

SMB over QUIC isn’t a “silver bullet” — it’s a powerful, elegant tool in a sysadmin’s arsenal. It solves the long-standing problem of secure, convenient file access from anywhere in the world, without needing an elaborate VPN setup.

By 2025, this technology has finally matured and become available on both Windows and Linux. It’s the rare case of a new feature that doesn’t complicate your life — it lets you rip out a dozen workarounds and make your infrastructure simpler and more reliable.

The key is rolling it out thoughtfully: test it, lock down the security, and have a rollback plan. The magic for users takes care of itself.

Tags: #windows #linux #samba #networking #security

🚀 Want to become tomorrow’s architect instead of just an admin? This article is only the tip of the iceberg. On our Telegram channel “Admin Future” we publish systems-thinking guides, ready-to-use scripts, AI tips, and checklists every day that you won’t find on Google. We don’t just post commands — we’re building a knowledge library for people who want to grow from admin to architect. Subscribe and become the expert in the room: Admin Future