SMB over QUIC on ONTAP

Why SMB over QUIC exists

Classic SMB (TCP/445) is dangerous to expose directly to the internet — it is the transport of choice for wormable exploits and credential relay attacks. Traditional answers were VPNs or RD Gateway-style tunneling. SMB over QUIC instead puts the entire session inside a TLS 1.3 encrypted stream on UDP/443:

• Encryption is mandatory — there is no cleartext fallback; the QUIC handshake is always TLS 1.3.
• Certificate-based server identity — clients validate the SVM's certificate like any HTTPS endpoint.
• UDP/443 only — one port through firewalls; no TCP/445 exposure.
• Better behavior on lossy WAN links — QUIC stream multiplexing avoids head-of-line blocking that plagues TCP-based SMB over high-latency links.
• Client support: Windows 11 22H2+/Windows Server 2022+ as client; Windows Admin Center can also manage client allow-lists. macOS and Linux clients generally do not yet support SMB-over-QUIC — plan accordingly.

Typical use cases: contractor/partner file shares, mobile-worker home directories, branch offices without VPN infrastructure, and disaster-recovery access paths when corporate networking is unavailable.

Prerequisites checklist

• ONTAP 9.14.1 or later (SMB over QUIC server support); confirm your exact release in the ONTAP release notes before designing around it.
• An SVM with an existing CIFS/SMB server joined to Active Directory (workgroup mode is not the target scenario).
• A server authentication certificate whose subject CN or SAN matches the FQDN clients will use (e.g. smb.corp.example.com), installed in the SVM's certificate store.
• The issuing CA chain trusted by both the SVM and every connecting client (enterprise CA or public CA).
• Firewall path allowing UDP/443 from client networks to the data LIFs serving the share.
• DNS record pointing the FQDN at the data LIF IP (or a load-balanced VIP).

Step 1 — Get a certificate onto the SVM

In production, generate a CSR from ONTAP and have your CA sign it. Self-signed certificates are acceptable only for lab testing because every client must be given the CA cert out of band:

# Generate a key + CSR on the SVM (subject must match the client-facing FQDN)
security certificate generate-csr -vserver svm1 -common-name smb.corp.example.com \
  -organization "Example Corp" -department IT -location Raleigh -state NC -country US

# Send csr_output to your CA (AD CS Web Server template or public CA),
# then install the signed server certificate:
security certificate install -vserver svm1 -type server \
  -certificate "-----BEGIN CERTIFICATE-----..." \
  -private-key "-----BEGIN PRIVATE KEY-----..."

# Install the intermediate/root chain so ONTAP can serve it during the handshake
security certificate install -vserver svm1 -type server-ca \
  -certificate "-----BEGIN CERTIFICATE-----..."

# Verify
security certificate show -vserver svm1

If you use AD CS, export the enterprise CA root into each client's Trusted Root store via Group Policy (Computer Config → Policies → Windows Settings → Security Settings → Public Key Policies) — clients refuse the QUIC handshake if the chain doesn't validate.

Step 2 — Enable the QUIC server on the SVM

# Enable SMB over QUIC for the SVM, binding the certificate
vserver cifs security modify -vserver svm1 \
  -smb-over-quic enabled

# Map the server certificate used for the QUIC listener
vserver cifs security modify -vserver svm1 \
  -certificate-for-smb-over-quic smb.corp.example.com

# Review effective SMB security settings
vserver cifs security show -vserver svm1

# Confirm the data LIFs that will receive UDP/443 traffic
network interface show -vserver svm1 -role data

ONTAP listens for QUIC on UDP/443 of the SVM's data LIFs once enabled. If your environment restricts outbound/inbound flows with intercluster or management firewall policies, add an explicit rule:

# Example: allow UDP/443 to the SVM data LIFs
network interface firewall-policy show
firewall policy create -policy quic-smb -service https_udp -protocol udp \
  -destination-port 443 -allow-list 203.0.113.0/24
# (verify exact firewall-policy syntax against your ONTAP man pages;
#  many deployments instead filter upstream on perimeter firewalls)

Step 3 — Prepare the Windows client side

SMB over QUIC is off by default on Windows clients and is controlled by two knobs:

1. Trusted servers list. Clients only connect to explicitly trusted QUIC servers. For non-domain-joined machines use Windows Admin Center → the client's SMB over QUIC section to add the FQDN. For managed fleets, push Group Policy: Computer Configuration → Administrative Templates → Network → Lanman Workstation → Configure SMB over QUIC trusted servers (list of FQDN suffixes/FQDNs).
2. Enable the feature. On current Windows builds the client capability ships enabled but may be gated by policy; verify with:

# Check whether the client can do QUIC at all (run as admin)
Get-SmbClientConfiguration | Select EnableSMBQUIC

# If disabled:
Set-SmbClientConfiguration -EnableSMBQUIC $true -Force

# Add the server to the trusted list locally (non-GPO alternative)
Set-SmbClientConfiguration -SmbServerNameHardeningLevel 0 -Force   # only if needed
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" `
  -Name "QuicTrustedServers" -Value "corp.example.com" -PropertyType String -Force

Registry values vary between Windows builds — cross-check against Microsoft's current SMB-over-QUIC client documentation before scripting fleet-wide changes.

Step 4 — Connect and verify end-to-end

# Connect using the FQDN (must match the certificate)
net use Q: \\smb.corp.example.com\projects /user:CORP\jdoe *

# Confirm the session came in over QUIC, not TCP 445
Get-SmbSession | Select ClientComputerName, Dialect
Get-SmbConnection | Select ServerName, ShareName, Dialect

# Show the QUIC-specific connection details
Get-SmbMultichannelConnection | Format-List

# ONTAP-side verification: active SMB sessions on the SVM
vserver cifs session show -vserver svm1

# Look for the QUIC flag/connection details in the session output,
# plus overall CIFS statistics
statistics start -object cifs -sample-id quic_check
statistics stop -sample-id quic_check

# EMS events if handshakes are failing
event log show -message-name *quic* -severity * -time 24h
event log show -message-name *tls* -severity * -time 24h

A packet capture on the perimeter should show UDP/443 flows to the data LIF and no TCP/445 from untrusted networks. From the client, Test-NetConnection smb.corp.example.com -Port 443 validates TCP reachability of the front door but not QUIC itself — rely on Get-SmbSession/ONTAP session output for proof.

Troubleshooting quick matrix

Security design notes

• Still authenticate normally. QUIC secures transport only; Kerberos/NTLM inside the tunnel behaves exactly like LAN SMB. Kerberos requires line-of-sight to domain controllers, so remote-only deployments often fall back to NTLM — prefer Kerberos where feasible and audit NTLM usage.
• Least privilege shares first. Expose dedicated partner/mobile shares, not broad DFS roots. Combine with ONTAP FPolicy wire filtering and file-extension restrictions for defense in depth.
• Rate-limit and monitor. Watch EMS auth failures and consider blocking repeated offenders upstream; UDP/443 is discoverable by scanners even though the payload is opaque.
• Certificate lifecycle matters. An expired server certificate breaks all QUIC clients at once — set expiry monitoring on the SVM certificate like any public TLS endpoint.
• VPN-free does not mean authorization-free. Pair with dynamic DNS hygiene: revoke the FQDN record when a third-party engagement ends.

Related pages

• SVM administration — CIFS server setup and scoping
• ONTAP security hardening checklist — baseline controls before exposing any share
• ARP & Cyber Vault — detection layers for internet-reachable shares
• CIFS/SMB troubleshooting — classic 445-side diagnostics