So something new that came out with Windows Server 2025 is the option for hosting Windows File Sharing shares (aka Samba or SMB) over a UDP protocol, QUIC. Funnily enough, this has been named SMB over QUIC. The benefits being that it uses a newer TLS 1.3 connection and is a lot easier to secure, and so works really well as an alternative for normal Windows File Sharing over the older TCP connections and having to mess around with VPNs or other things to be able to get a secure connection. Also pretty cool is that SMB-over-QUIC is available in Samba server on Linux as of version 4.23.0.

OK Yes, I know the rest of the world has moved on with web access for file shares, eg through Sharepoint or Nextcloud or something else, but humour me here!

So I got thinking, is this really the bog-standard SMB protocol over a QUIC connection, or is it all marketing? The idea that it took a while to come out on Samba made me think there was some magic voodoo going on here. I mean, sure I probably could have just looked at the Samba source code and figured it out, but I’m a coder! I don’t have time to read other peoples code!

I couldn’t easily test out the new Samba because my Linux machine didn’t have the quic.ko kernel module, but coincidentally I had an old Windows Server 2012 server that I was decommissioning and a terrible nagging thought that wouldn’t leave me alone. Yes, it was: "could I make this new fangled silliness work with a 14 year old server?" It was as if all the dark evils of the world possessed me for a brief moment, and the madness seemed to make sense.

So out I jumped out and slapped QUIC on top of my server with what was effectively a QUIC proxy: GOST, a Golang project that routes traffic between different protocols and it had support for QUIC. I redirected QUIC UDP port 443 to my TCP 445 Windows File Server then connected through from my Win11 client using net use Z: \\server.example.com\share /TRANSPORT:QUIC /SKIPCERTCHECK aaand it didn’t work. Darn. So, I fired up Wireshark and found that the Windows client would try to set up the TLS1.3 connection with a unique ALPN of "smb" but my GOST instance wasn’t configured with that. Tweaking the GOST config file still didn’t work, and it turned out to have a hard-coded ALPN of "h3, quic/v1" baked into the source.

I spun off a GitHub ticket, but didn’t let the thought go.

Instead, I vibed up a little wrapper utility that would provide the same, and it sorta kinda mostly worked!… but only on my Linux box. Turns out the C# libs for QUIC need OpenSSL but that’s only used on the Linux builds and there were lots of hoops to jump through to get that building on Windows. I could run the relay on my Linux box and point it at the old Windows Server, but: Blegh. No one really wants to have to run a whole extra server just to do a nasty hack, right? Just imagine the carbon-miles on that extra server hop!

But then the GOST devs changed up their code pretty quick, and spinning up a GOST server (with a free wildcard cert from LetsEncrypt) it worked! The net use works great!

The downside was that throughput was a lot slower. Likely because the protocol relaying was happening in software using CPU rather than any direct low-level kernel/service, but it did prove that yes, it was actually just the old SMB protocol running over QUIC and not some magic new protocol with a fancy marketing term. Huzzah!

(Yes, this is a terrible idea, no you shouldn’t use it in production. grim just negged me into writing a blog post after pointing out the last one was a million years ago or something.)