[HN Gopher] Wireguard FPGA
___________________________________________________________________
Wireguard FPGA
Author : hasheddan
Score : 278 points
Date : 2025-10-12 17:12 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hnspammers wrote:
| I'll need someone more into this to break it down for me - how
| does VPN work on this and why do you need an FPGA version of it?
| Is this an internal VPN or one for connecting to the internet?
| turtletontine wrote:
| 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.
| kaoD wrote:
| 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.
| a-dub wrote:
| 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. :)
| asimeqi wrote:
| 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.
| numpad0 wrote:
| "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.
| immibis wrote:
| 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.
| jauntywundrkind wrote:
| SpiralHDL is so cool. There's been so so much consolidation in
| the semiconductor market, and that's scary. But it feels like
| there's such an amazing base of new open design systems to work
| from now, that getting new things started should be so possible!
| There's just a little too much gap in actually getting the
| Silicon Foundry model back up, things all a bit too encumbered
| still. Fingers crossed that chip making has its next day.
|
| > _However, the Blackwire hardware platform is expensive and
| priced out of reach of most educational institutions. Its
| gateware is written in SpinalHDL, a nice and powerfull but a
| niche HDL, which has not taken roots in the industry. While
| Blackwire is now released to open-source, that decision came from
| their financial hardship -- It was originaly meant for sale._
|
| Here's some kind of link for the old BlackWire 100Gbe wiregaurd
| project mentioned: https://github.com/FPGA-House-
| AG/BlackwireSpinal
| bri3d wrote:
| Amusingly, after the commentaries about niche HDLs, the authors
| seem to have turned to PipelineC in this project.
| IshKebab wrote:
| 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.
| danhor wrote:
| What are the benefits of SV for multi-clock design? I found
| migen (and amaranth) to be much nicer for multi-clock
| designs, providing a stdlib for CDCs and async FIFOs and
| keeping track of clock domains seperately from normal
| signals.
|
| My issue with systemverilog is the multitude of
| implementation with widely varying degrees of support and
| little open source. Xsim poorly supports more advanced
| constructs and crashes with them, leaving you to figure out
| which part causes issues. Vivado only supports a subset.
| Toolchains for smaller FPGAs (lattice, chinese, ...) are much
| worse. The older Modelsim versions I used were also not
| great. You really have to figure out the basic common subset
| of all the tools and for synthesis, that basically leaves
| interfaces and logic . Interfaces are better than verilog,
| but much worse than equivalents in these neo-HDLs(?).
|
| While tracing back compiled verilog is annoying, you are also
| only using one implementation of the HDL, without needing to
| battle multiple buggy, poorly documented implementation.
| There is only one, usually less buggy, poorly documented
| implementation.
| mlhpdx wrote:
| I haven't tinkered with an FPGA in years but this has my
| curiosity up. I'd love to separate the protocol handling from the
| routing and see how light (small of an FPGA, power efficiency) it
| could be made.
|
| The routing isn't interesting to me - but protecting low power
| IoT traffic certain is.
| nocman wrote:
| "With traditional solutions (such as OpenVPN / IPSec) starting to
| run out of steam" -- and then zero explanation or evidence of how
| that is true.
|
| I can see an argument for IPSec. I haven't used that for many
| years. However, I see zero evidence that OpenVPN is "running out
| of steam" in any way shape or form.
|
| I would be interested to know the reasoning behind this.
| Hopefully the sentiment isn't "this is over five years old so
| something newer must automatically be better". Pardon me if I am
| being too cynical, but I've just seen _way_ too much of that
| recently.
| vlovich123 wrote:
| 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.
| _joel wrote:
| I use and advocate for wireguard but I don't see it's
| adoption in bigger orgs, at least the ones I've worked in.
| Appreciate this situation will change over time, but it'll be
| a long tail.
| awakeasleep wrote:
| Yeah itll be running out of steam not only when regulators
| _understand_ wireguard, but when its the recommendation and
| orgs need to justify their old vpn solution
| danudey wrote:
| If you use Kubernetes and Calico you can use Wireguard to
| transparently encrypt in-cluster traffic[1] (or across
| clusters if you have cluster mesh configured). I wonder if
| we'll see more "automatic SDN over Wireguard" stuff like
| this as time goes on and the technology gets more proven.
|
| Problem is IIRC if you need FIPS compliance you can't use
| Wireguard, since it doesn't support the mandated FIPS
| ciphers or what-have-you.
|
| [1]https://docs.tigera.io/calico/latest/network-
| policy/encrypt-...
| _joel wrote:
| sure, but I mean "road warrior" client. Typical, average
| company VPN users. Ironocally getting a technology like
| wireguard in k8s is easier than replacing an established
| vendor/product that serves normal users.
| vlovich123 wrote:
| It'll take a little bit of time. But for example
| Cloudflare's Warp VPN also uses Wireguard under the hood.
|
| So while corp environments may take a long time to switch
| for various reasons, it will happen eventually. But for
| stuff like this corp IT tends to be a lagging adopter,
| 10-20 years behind the curve.
| BuildTheRobots wrote:
| Bigger orgs for the most part use whatever vpn solutions
| their (potentially decade old) hardware firewalls support.
| Until you can manage and endpoint a Wireguard tunnel on
| Cisco, Juniper, Fortigate (etc) hardware then it's going to
| take a while to become more mainstream.
|
| Which is a shame, because I have a number of problematic
| links (low bandwidth, high latency) that wireguard would be
| absolutely fantastic for, but neither end supports it and
| there's no chance they'll let me start terminating a tonne
| of VPNs in software on a random *nix box.
| ted_dunning wrote:
| The anti-FIPS position of the wireguard implementors is a
| big problem for adoption.
| IlikeKitties wrote:
| 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!
| IntoEquanimity wrote:
| Interestingly tried out just now on one of my devices and
| Wireguard VPN speed was 5x faster on same configuration to
| OpenVPN.
| wmf wrote:
| 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.
| jbverschoor wrote:
| Unfortunately (luckily?) I don't have enough knees about
| IPsec, but usually things make a lot more sense once you
| actually know the exact architecture and rationale behind it
| smcleod wrote:
| 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.
| shadowpho wrote:
| Same here. With openvpn my somewhat modern cpu takes out a
| whole core @100% at like 200 megabits/s.
|
| With WireGuard I instead max out the internet bandwidth with
| like 20% cpu usage if that.
|
| I really don't understand why. We have AES acceleration. AES-
| NI can easily do more bps... why is openvpn so slow?
| tw04 wrote:
| 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.
| mrb wrote:
| I can't think of a scenario where this is useful. They claim "
| _Full-throttle, wire-speed hardware implementation of Wireguard
| VPN_ " but then go on implementing this on a board with a puny
| set of four 1 Gbps ports... The standard software implementation
| of Wireguard (Linux kernel) can already saturate Gbps links
| (wirespeed, check) and can even approach 10 Gbps on a mid-range
| CPU: https://news.ycombinator.com/item?id=42172082
|
| If they had produced a platform with four 10 Gbps ports, then it
| would become interesting. But the whole hardware and bitstream
| would have to be redevelopped almost from scratch.
| bri3d wrote:
| 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.
| asimovDev wrote:
| what do you mean by grantware?
| roywashere wrote:
| The project got a grant from NLnet. I think they do a great
| job, they gave grants to many nice projects (and also some
| projects that are going nowhere, but I guess that is all in
| the game). NLnet really deserves praise for what they are
| doing!! https://nlnet.nl/thema/NGI0CommonsFund.html
| renewiltord wrote:
| 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_...
| Hikikomori wrote:
| They're discussing mikrotik hardware specifically? Enterprise
| stuff or a powerful server can easily do it.
| esseph wrote:
| It's highly going to depend on the hardware in use.
| Avamander wrote:
| Mikrotik's hardware often can't even do linespeed beyond
| basic switching, not to mention VPN, so yeah.
| wmf wrote:
| 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.
| brcmthrowaway wrote:
| If a PC can do 10Gbps, are there any cycles left for other
| stuff?
| soneil wrote:
| bps are easy. packets per second is the crunch. Say you've
| got 64 bytes per packet, which would be a worst-case-scenario
| - you're down to 150Mpacket/sec. Sending one byte after
| another is the easy bit, the decisions are made per-packet.
| jasonwatkinspdx wrote:
| 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.
| bri3d wrote:
| This is conceptually interesting but seems quite a ways from a
| real end to end implementation - a bit of a smell of academic
| grantware that I hope can reach completion.
|
| Fully available source from RTL up (although the license seems
| proprietary?) is very interesting from an audit standpoint, and
| 1G line speed performance, although easily achieved by any recent
| desktop hardware, is quite respectable in worst case scenarios
| (large routing table and small frames). The architecture makes
| sense (software managed handshakes configure a hardware packet
| pipeline). WireGuard really lacks acceleration in most contexts
| (newer Intel QAT supposedly can accelerate ChaCha20 but trying to
| figure out how one might actually make it work is truly mind
| bending), so it's a pretty interesting place to do a hardware
| implementation.
| louwrentius wrote:
| I think Wireguard is awesome and I use it exclusively.
|
| That said, when traveling - on hotel wifi - for internet to work,
| TCP port 443 is always open, thus OpenVPN will always work if you
| run it on that port.
|
| For Wireguard, there isn't a reliable always-open UDP port. Port
| 123 or 53 could work sometimes, but it's not as guaranteed.
|
| For any other application though, Wireguard would be my first
| choice.
| CaptainOfCoit wrote:
| > 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.
| commandersaki wrote:
| 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
| coppsilgold wrote:
| 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.
|
| Performance would of course suffer but it's not likely that
| whichever service is blocking UDP is going to be offering high
| performance.
|
| 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.
| eptcyka wrote:
| QUIC will hopefully help with this.
| exabrial wrote:
| Here's a dumb question, tangentially related, since they have a
| 10gig L2 switch mentioned... How come nobody (almost) makes L2
| 10gig switches? Ubiquiti has a 8port L2, that really seems to be
| it.
| denotational wrote:
| Do you mean specifically as consumer products?
|
| There are loads of 10GbE switches from Cisco/Juniper/Arista/et
| al.
| phatfish wrote:
| I'd guess so.
|
| The last time I was checking (which was over 5 years ago now
| admittedly) there were no 10GbE switch options for reasonable
| prices. Juniper had good 16 port options with 1GbE interfaces
| at not crazy prices (which I have two of).
|
| Going to 10GbE was many multiples of the 1GbE price. They
| just seemed way too expensive and were not dropping.
|
| As it goes, maxing out 1GbE is fast enough for the sort of
| data and IOPS I send over my LAN. So 10GbE would probably
| have been overkill.
| jasonwatkinspdx wrote:
| The 10Gb twisted pair cable requirements can bite you also.
| You may be working with who knows what installed cable that
| can't push it reliably. Or as a DIY person you may not
| understand exactly what to buy or limitations on running
| it.
|
| 1Gb is fast enough, cheap, and basically foolproof.
| Hikikomori wrote:
| Enterprise 10G SFP+ switches has been pretty cheap on eBay
| for longer than that. While you can plug in an rj45 SFP
| it's just cheaper and better to use DAC cables.
| comboy wrote:
| Mikrotik has quite a few, I've been happily using CRS306 and
| CRS312 for some years now.
| Hikikomori wrote:
| 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.
| hackmiester wrote:
| 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.
| c0l0 wrote:
| Very cool project - hoping to see follow-up designs that can do
| more than 1Gbps per port!
|
| I recently built a fully Layer2-transparent 25Gbps+ capable
| wireguard-based solution for LR fiber links at work based on
| Debian with COTS Zen4 machines and a purpose-tailored Linux
| kernel build - I'd be curious to know what an optimized FPGA can
| do compared to that.
| Hikikomori wrote:
| When macsec exists?
| bc569a80a344f9c wrote:
| No kidding.
|
| Just to elaborate for others, MACSec is a standard (802.1ae)
| and runs at line rate. Something like a Juniper PTX10008 can
| run it at 400Gbps, and it's just a feature you turn on for
| the port you'd be using for the link you want to protect
| anyway (PTXs are routers/switches, not security devices).
|
| If I need to provide encryption on a DCI, I'm at least
| somewhat likely to have gear that can just do this with
| vendor support instead of needing to slap together some Linux
| based solution.
|
| Unless, I suppose, there's various layer 2 domains you're
| stitching together with multiple L2 hops and you don't
| control the ones in the middle. In which case I'd just get a
| different link where that isn't true.
| ur-whale wrote:
| > When macsec exists?
|
| When you say "exists" ... is there an OpenSource high-quality
| implementation ?
| Hikikomori wrote:
| https://man7.org/linux/man-pages/man8/ip-macsec.8.html
|
| Generally its used when you have links going between two of
| your sites, so you typically only need it on your switch or
| router that terminate that link.
| soupbowl wrote:
| This is a very cool project! I had never heard of SystemVerilog
| until today.
| altairprime wrote:
| Project page: https://nlnet.nl/project/KlusterLab-Wireguard/
| geoctl wrote:
| 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 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.
| wmf wrote:
| 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.
| azalemeth wrote:
| 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...
| geoctl wrote:
| WireGuard-over-QUIC does not make any sense to me, this
| lowers performance and possibly the inner WireGuard MTUs. You
| can just replace WireGuard with QUIC altogether if you just
| want obfuscation.
| AnthonyMouse wrote:
| 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.
| geoctl wrote:
| QUIC isn't really about the web, it's more of a TCP+TLS
| replacement on top of UDP. You can build your own custom L7
| on top of QUIC.
| contact9879 wrote:
| 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/
| BAPHOMETA88F wrote:
| Aside from Blackwire prococols, the sector for FPGA's that are in
| the AMD architectural framework, Xilinx acquisition is the
| tangential key-management software for VPN tunneling, which is
| contingent on whether ASIC [application-specific integrated
| circuits] can successfully test binaries.
___________________________________________________________________
(page generated 2025-10-12 23:00 UTC)