While WireGuard makes every sense for an FPGA due to its minimal design, I wonder why there isn't much interest in using QUIC as a modern tunneling protocol, especially for corporate use cases. QUIC already provides an almost complete WireGuard-alternative via its datagrams that can be easily combined with TUN devices and custom authentication schemes (e.g. mTLS, bearer tokens obtained via OAuth2 and OIDC authentication, etc...) to build your own VPN. While I am not sure about performance, at least when compared to kernel-mode WireGuard, since QUIC is obviously a more complex state machine that's running in userspace and it depends on the implementation and optimizations offered by the OS (e.g. GRO/GSO), QUIC isn't just a yet another tunneling protocol, it actually offers lots of benefits such as working well with dynamic endpoints with DNS instead of just using static IP addrs, it uses modern TLSv1.3 and therefore it's compliant with FIPS for example, it uses AES which can be accelerated by the underlying hardware (e.g. AES-NI), it currently has implementations in almost every major programming language, it can work well in the future with proxies and load balancers, you can bring your own custom, more fine-grained authentication scheme (e.g. bearer tokens, mTLS, etc...), it masquerades as just another QUIC/HTTP3 traffic that's used by almost all major websites now and therefore less susceptible to dropping by any nodes in between, and other less obvious benefits such as congestion control and PMTUD.

Why would anyone want to use a complex kludge like QUIC and be at the mercy of broken TLS libraries, when Wireguard implementations are ~ 5k LOC and easily auditable?

Have all the bugs in OpenSSL over the years taught us nothing?

I've recently spent a bunch of time working on a mesh networking project that employs CONNECT-IP over QUIC [1].

There's a lot of benefits for sure, mTLS being a huge one (particularly when combined with ACME). For general purpose, spoke and hub VPN's tunneling over QUIC is a no-brainer. Trivial to combine with JWT bearer tokens etc. It's a neat solution that should be used more widely.

However there are downsides, and those downsides are primarily performance related. For a bunch of reasons, some just including poorly optimized library code, others involving relatively high message parsing/framing/coalescing/fragmenting costs, and userspace UDP overheads. On fat pipes today you'll struggle to get more than a few gbits of throughput @ 1500 MTU (which is plenty for internet browsing for sure).

For fat pipes and hardware/FPGA acceleration use cases, google probably has the most mature approach here with their datacenter transport PSP [2]. Basically a stripped down per flow IPsec. In-kernel IPsec has gotten a lot faster and more scalable in recent years with multicore/multiqueue support [3]. Internal benchmarking still shows IPsec on linux absolutely dominating performance benchmarks (throughput and latency).

For the mesh project we ended up pivoting to a custom offload friendly, kernel bypass (AF_XDP) dataplane inspired by IPsec/PSP/Geneve.

I'm available for hire btw, if you've got an interesting networking project and need a remote Go/Rust developer (contract/freelance) feel free to reach out!

1. https://www.rfc-editor.org/rfc/rfc9484.html

2. https://cloud.google.com/blog/products/identity-security/ann...

3. https://netdevconf.info/0x17/docs/netdev-0x17-paper54-talk-s...

The assumed mentality of “being flexible” is the very reason WireGuard was created to fight against in the first place, otherwise why bother? IPSec is already standardized and with wide-spread hardware implementation (both FPGA and ASIC) and flexible.

MASQUE[0] is the protocol for this. Cloudflare already uses masque instead of wireguard in their warp vpn.

[0]https://datatracker.ietf.org/wg/masque/about/

The purpose of Wireguard is to be simple. The purpose of QUIC is to be compatible with legacy web junk. You don't use the second one unless you need the second one.

Why are you taking from people their will to experiment and design new stuff? Are they using your money or time? Is this just out of grumpiness, envy, condescension or what?

Mullvad offers exactly the combination of wireguard in QUIC for obsfucation and to make traffic look like Https -- https://mullvad.net/en/blog/introducing-quic-obfuscation-for...

I think standards operate according to punctuated equilibrium so the market will only accept one new standard every ten years or so. I could imagine something like PQC causing a shift to QUIC in the future.

Quic is a corporate supported black hole. Corporations are anti-human. Its a wonder that there is still some freedom to make useful protocols on the internet and that people are nice enough to do that

I think with a comment like this you have absolutely no clue what is relevant for adoption.

Adoption is about offering something that is 1) correct 2) easy to install 3) has reasonable performance 4) stable.

Wireguard provides all of those. OpenVPN was not meeting criterium 1 even a few years ago and IMO, if it doesn't work after a decade of development, it's _never_ going to work.

Now, let's look at your comment, which is full of techno mumbo jumbo (don't worry, I know everything you talk about), doesn't even mention half of those.

I think an extremely naive, but popular position is that when someone comes out with some new tool that "works on their machine", that they assume that everyone else believes immediately that they are not just as stupid as everyone that came before them. This was even true for Wireguard, since Wireguard was _not_ bug free either. In fact, one could argue that Wireguard is still an amateur project despite it working stable for some of my systems.

The problem with software like Wireguard is that there is no incentive to actually make bug free software. If software always works and has all the required features, nobody will call the person or company associated with it anymore. When was the last time that the author of "grep" was recognized as a great programmer? Never. Now, I am not saying that grep is free of bugs, but I just took a fairly stable program as an example. An economy for software like SaaS has much better incentives in that regard (even though they often also do not reach bug free status). curl is also an excellent example of bug ridden software that an entire industry is using, while it is written by an amateur (that has no incentive whatsoever to produce something that doesn't need to have bugs fixed).

If humanity had somewhat more of a collective intelligence, a million people would come together and just all paid $100 to implement a wireguard replacement (possibly even using the same protocol) to perfection such that no new implementation would ever be needed and that would adapt to any hardware automatically. Instead we prefer to continue to fuck around with inferior shit all day long.