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?

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/

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 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.

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...

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.

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.

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?

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

[flagged]

How did you work around WireGuard's encryption and multiqueue bottlenecks? Jumbo frames?

25G is a lot for WireGuard [1].

1. https://www.youtube.com/watch?v=oXhNVj80Z8A

When macsec exists?

This is a flex!

The problems with all not-SV HDLs are:

1. None of the commercial tools support them. All other HDLs compile to SV (or plain Verilog) and then you're wasting hours and hours debugging generated code. Not fun. Ask me how I know...

2. SV has an absolute mountain of features and other HDLs rarely come close. Especially when it comes to multi-clock designs (which are annoying and awkward but very common), and especially verification.

The only glimpse of hope I see on the horizon is Veryl, which hews close enough to SV that interop is going to be easy and the generated code is going to be very readable. Plus it's made by very experienced people. It's kind of the Typescript of SystemVerilog.

Amusingly, after the commentaries about niche HDLs, the authors seem to have turned to PipelineC in this project.

It's an educational project. No need to put it on blast over that. CE/EE students can buy a board for a couple hundred bucks and play around with this to learn.

A hypothetical ASIC implementation would beat a CPU rather soundly on a per watt and per dollar basis, which is why we have hardware acceleration for other protocols on high end network adaptors.

Personally, if I could buy a Wireguard appliance that was decent for the cost, I'd be interested in that. I ran a FreeBSD server in my closet to do similar things back in the day and don't feel the need to futz around with that again.

There’s a strong air of grantware to it. The notion that it could be end-to-end auditable from the RTL up is interesting, though, and generally Wireguard performance will tank with a large routing table and small MTUs like you might suffer on a VPN endpoint server while this project seems to target line speed even at the absolute worst case routing x packets scenario.

Amusingly, a lot of people have always been convinced that doing 10 Gbps is impossible on VPN. I recall a two-year old post on /r/mikrotik where everyone was telling OP it was impossible with citations and sources of why but then it worked

https://old.reddit.com/r/mikrotik/comments/112mo4v/is_there_...

Why would you even need dedicated hardware for just 40 Gb/s? That is within single-core decryption performance which should be the bottleneck for any halfway decent transport protocol. Are we talking 40 Gb/s at minimum packet size so you need to handle ~120 M packets/s?

I can see this as a hardened VPN in a mission-critical deployment, which could not be as easily compromised as a software stack.

If a PC can do 10Gbps, are there any cycles left for other stuff?

My dude: As far as I know, it's the first implementation of Wireguard in an FPGA.

It does not have to be all things for all people today. It can be improved. (And it appears to be open-source under a BSD license; anyone can begin making improvements immediately if they wish.)

Concepts like "This proof-of-concept wasn't explored with multiple 10Gbps ports! It is therefore imperfect and thus disinteresting!" are... dismaying, to say the least.

It would be an interesting effort if it only worked with two 10Mbps ports, just because of the new way in which it accomplishes the task.

I don't want to live in a world where the worth of all ideas is reduced a binary concept, where all things are either perfect or useless.

(Fortunately for me, I do not live in such a world that is as binary as that.)

IMO it would be cool if they added Wireguard to Corundum but it would be expensive enough that they wouldn't get any hobbyist cred.

> (although the license seems proprietary?)

Hm, "BSD 3-Clause License" is seems really proprietary to you?

But you are right: do the personal license in many(most?) Verilog files[1] overrules the LICENSE file[2] of a repo?

[1] https://github.com/chili-chips-ba/wireguard-fpga/blob/main/1...

[2] https://github.com/chili-chips-ba/wireguard-fpga/blob/main/L...

Seems like you just haven’t been paying attention. Even commercial VPNs like PIA and others now use Wireguard instead of traditional VPN stacks. Tailscale and other companies in that space are starting to replace VPN stacks with Wireguard solutions.

The reasons are abundant, the main ones being performance is drastically better, security is easier to guarantee because the stack itself is smaller and simpler, and it’s significantly more configurable and easier to obtain the behavior you want.

Wireguard is slowly eating the space alive and thats a good thing.

Here's a very educational comparison between Wireguard, OpenVPN and IPSec. It shows how easy wireguard is to manage compared to the other solutions and measures and explains the noticeable differences in speed: https://www.youtube.com/watch?v=LmaPT7_T87g

Very recommended!

I wouldn't say they're running out of steam (they never had any) but OpenVPN was always poorly designed and engineered and IPSec has poor interop because there are so many options.

Interestingly tried out just now on one of my devices and Wireguard VPN speed was 5x faster on same configuration to OpenVPN.

IPSec isn’t running out of steam anytime soon. Every commercial firewall vendor uses it, and it’s mandatory in any federal government installation.

WireGuard isn’t certified for any federal installation that I’m aware of and I haven’t heard of any vendors willing to take on the work of getting it certified when its “superiority” is of limited relevance in an enterprise situation.

OpenVPN has both terrible configuration and performance compared to just about anything else. I've seen it really drop off to next to no usage both in companies and for personal use over the past few years as wireguard based solutions have replaced it.

What exactly is the application you are thinking of? I also do IoT, but "low-power" can mean different things for different people.

Yep, I really want to dote on wireguard and have contributed a little bit to it in its early years, but I've always found dsvpn to work at any cafe/hotel/hospital/etc. where I roam (except Sydney Airport - fuck their hostile wifi).

[dsvpn]: https://github.com/jedisct1/dsvpn

Some VPN applications provide the means by which to tunnel WG over TCP. Some provide those as standalone tools: <https://github.com/mullvad/udp-over-tcp>

The one above has a very simple protocol:

    The format of the data inside the TCP stream is very simple. Each datagram is preceded with a 16 bit unsigned integer in big endian byte order, specifying the length of the datagram.

If you are doing it manually you can include two peers, one over UDP and one over TCP and prioritize traffic flow over the UDP one. Commercial VPN apps tend to handle that with "auto".

If you want to be fancy or you are confident that the UDP blocking service can offer high performance you can include a third peer using udp2raw: <https://github.com/wangyu-/udp2raw>

The reason why you may want to retain udp-over-tcp is that some sophisticated firewalls may block fake-TCP.

we run wg, star topology over port 443/udp with a specific ip in the center. never once had an issue on the road.

QUIC will hopefully help with this.

> For Wireguard, there isn’t a reliable always-open UDP port. Port 123 or 53 could work sometimes, but it’s not as guaranteed.

Couldn't you pipe it through something like udp2raw in those few cases? Probably performance would be worse/terrible, but then you say it's on hotel network so those tend to be terrible anyways.

Do you mean specifically as consumer products?

There are loads of 10GbE switches from Cisco/Juniper/Arista/et al.

Mikrotik has quite a few, I've been happily using CRS306 and CRS312 for some years now.

Do you mean like most vendors have moved onto faster port speeds? Mostly you can still use the slower 10G optics and the ports will clock down even if the nominal port speed is higher.

Not counting Cisco, juniper etc? Can probably get 32port 10G on eBay for cheap. There's also some on Amazon and AliExpress. And tons of white label options.

This part of the README answers the “why” pretty well:

> Both software and hardware implementations of Wireguard already exist. However, the software performance is far below the speed of wire.

> Existing hardware approaches are both prohibitively expensive and based on proprietary, closed-source IP blocks and tools.

> The intent of this project is to bridge these gaps with an FPGA open-source implementation of Wireguard, written in SystemVerilog HDL.

So having it on an FPGA gives you the best of both worlds, speed of a hardware implementation without the concerns of a proprietary black box.

"VPN" is just virtual emulated network cables that you would use to connect your laptops to Wi-Fi routers. It's just so happens that a lot of companies use that word for a paid, cloud based Internet-over-Internet service. It's as if taxi companies called themselves "wheels" companies that whether you're referring to the physical object or the service had become ambiguous.

VPNs are normally processed in software, and that processing is usually multi-step. So latency, jitter, processing time per types of packets, etc can vary. This is FPGA based, and FPGA can run some algorithms and programs that can be implemented as chained conditions at fixed latency without relying on function calling in software. Presumably this is faster and more stable than software approaches thanks to that.

Just a guess but I assume that this is (or rather, would be, judging by the README this isn't past the planning stage) for IoT and the like.

If you want your device to connect to a VPN you need something to implement the protocol. Cycles are precious in the embedded world so you don't want to do it in your microcontroller. You might offload it to another uC in your design but at that point it might make sense to just use an FPGA and have this at the hardware(-ish) level.

You can think of this as a "network interface chip" but speaking Wireguard instead of plain IP.

Not a member of the project but here is my take:

You run the WireGuard app on your computer/phone, tap Connect, and it creates an encrypted tunnel to a small network box (the “FPGA gateway”) at your office or in the cloud. From then on, your apps behave as if you’re on the company network, even if you’re at home or traveling.

Why the FPGA box: Because software implementations are too slow and existing hardware implementations cost too much.

Internal or Internet: Both.

Wireguard is a protocol and program for making point-to-point VPN connections. It's notable because it's simple (compared to alternatives like OpenVPN), so simple it became a kernel module which made it very fast. These guys implemented it in an FPGA because they could.

integration of some of the compute intensive bits into the nic itself. the reason to do it in hardware is to increase efficiency (or sometimes performance, although software/cpu wireguard is already pretty good). this could be baby steps towards lower power / miniaturized / efficient hardware that supports the wireguard protocol.

also just a fun project for the authors. :)