13 ms·

Wireguard FPGA

640 points by hasheddan 1y ago

hnspammers 1y ago
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 1y ago
  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.
  - ohdeardear 1y ago
    Unless you physically build the FPGA, you still have a black box, but you just shifted the problem (now, I am not saying that this is a bad thing, since if you run Linux on Intel, it's still proprietary and people still run Linux).
- kaoD 1y ago
  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 1y ago
  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 1y ago
  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.
  - deleted 1y ago
    [deleted]
- numpad0 1y ago
  "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 1y ago
  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.
  - johnthescott 1y ago
    i think of wg more as point-to-point, encrypted network interfaces cards than a vpn.
    - immibis 1y ago
      That's what a vpn is - a virtual private network. You can make a private network by adding more network interface cards and wiring. If you do it with software instead, it's virtual.
jauntywundrkind 1y ago
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 https://github.com/FPGA-House-AG/BlackwireSpinal
- bri3d 1y ago
  Amusingly, after the commentaries about niche HDLs, the authors seem to have turned to PipelineC in this project.
- IshKebab 1y ago
  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 1y ago
    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 1y ago
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.
- ohdeardear 1y ago
  What exactly is the application you are thinking of? I also do IoT, but "low-power" can mean different things for different people.
nocman 1y ago
"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 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
      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-cluster-pod-traffic https://docs.tigera.io/calico/latest/network-policy/encrypt-...
mrb 1y ago
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 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 1y ago
  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 1y ago
    what do you mean by grantware?
    - roywashere 1y ago
      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 https://nlnet.nl/thema/NGI0CommonsFund.html
    - bri3d 1y ago
      Academic projects which receive grant money to produce papers and slides. This still can advance the state of the art, to be clear, and I like the papers and slides coming out of this project. But I wouldn’t cross my fingers for a working solution anytime soon.
bri3d 1y ago
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.
- qrios 1y ago
  > (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.hw/external_lib/ethernet/arp_eth_rx.v https://github.com/chili-chips-ba/wireguard-fpga/blob/main/1... [2] https://github.com/chili-chips-ba/wireguard-fpga/blob/main/LICENSE https://github.com/chili-chips-ba/wireguard-fpga/blob/main/L...
  - mort96 1y ago
    The safe assumption to make when met with a contradiction in licensing would be to assume that the more restrictive license holds, no? Especially when the permissive license is a general repo-wide license and the restrictive license is specifically applied to certain files. So for all intents and purposes, in my opinion, large parts of this Wireguard FPGA project are under this weird proprietary Chili Chips license. In fact, the license is so proprietary that the people who made this wireguard FPGA repository and made it visible to the public are seemingly in violation of it. It puts us in a weird spot as well: I'm now the "holder of" a file and am obligated to keep all information within it confidential and to protect the file from disclosure. So I guess I can't share a link to the repo, since that would violate my obligation to protect the files within it from disclosure. I would link to the files in question, but, well, that wouldn't protect them from disclosure now would it.
ericdotlee 1y ago
[dead]
louwrentius 1y ago
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 1y ago
  > 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 1y ago
  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 https://github.com/jedisct1/dsvpn
- coppsilgold 1y ago
  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 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 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.
exabrial 1y ago
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 1y ago
  Do you mean specifically as consumer products? There are loads of 10GbE switches from Cisco/Juniper/Arista/et al.
  - phatfish 1y ago
    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 1y ago
      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 1y ago
      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.
      - bigfatkitten 1y ago
        Second hand optics and preterminated fibre are cheap now too.
c0l0 1y ago
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 1y ago
  When macsec exists?
  - bc569a80a344f9c 1y ago
    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.
    - tecleandor 1y ago
      I have at least one switch that's MACSec compatible at line speed but I haven't had time to take a look. I guess this is confined to LAN and cannot do a MACSec link through the internet, isn't it?
      - bc569a80a344f9c 1y ago
        It’s port to port. It protects a link.
        tecleandor 1y ago
soupbowl 1y ago
This is a very cool project! I had never heard of SystemVerilog until today.
altairprime 1y ago
Project page: https://nlnet.nl/project/KlusterLab-Wireguard/ https://nlnet.nl/project/KlusterLab-Wireguard/
geoctl 1y ago
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.
- wmf 1y ago
  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 1y ago
  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-wireguard https://mullvad.net/en/blog/introducing-quic-obfuscation-for...
  - geoctl 1y ago
    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.
BAPHOMETA88F 1y ago
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.
almaight 1y ago
[dead]
keepamovin 1y ago
Tangentially related, I've experimented with Tailscale and Zerotier and, tho I guess they have different audiences, I prefer Zerotier for reliability. Tailscale gets borked by existing VPN config, breaking things on local networks. I like both but does anyone care to share their experiences or explain more in depth the uses / differences as they see it?
stephenanand1 1y ago
[dead]
Surac 1y ago
A open source stack for Xilinx 7 chips is the most interesting take away for me here. I have to dig deeper
Frank00 1y ago
[dead]
clarionPilot11 1y ago
Wow, it’s crazy how much thought goes into these VPN designs.
sherinjosephroy 1y ago
[flagged]

640 points by hasheddan 1y ago

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 1y ago
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.
- ohdeardear 1y ago
  Unless you physically build the FPGA, you still have a black box, but you just shifted the problem (now, I am not saying that this is a bad thing, since if you run Linux on Intel, it's still proprietary and people still run Linux).
kaoD 1y ago
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 1y ago
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 1y ago
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.
- deleted 1y ago
  [deleted]
numpad0 1y ago
"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 1y ago
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.
- johnthescott 1y ago
  i think of wg more as point-to-point, encrypted network interfaces cards than a vpn.
  - immibis 1y ago
    That's what a vpn is - a virtual private network. You can make a private network by adding more network interface cards and wiring. If you do it with software instead, it's virtual.

jauntywundrkind 1y ago

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 https://github.com/FPGA-House-AG/BlackwireSpinal

bri3d 1y ago
Amusingly, after the commentaries about niche HDLs, the authors seem to have turned to PipelineC in this project.
IshKebab 1y ago
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 1y ago
  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 1y ago

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.

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

nocman 1y ago

"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 1y ago
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 1y ago
  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 1y ago
    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 1y ago
    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-cluster-pod-traffic https://docs.tigera.io/calico/latest/network-policy/encrypt-...

mrb 1y ago

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 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 1y ago
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 1y ago
  what do you mean by grantware?
  - roywashere 1y ago
    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 https://nlnet.nl/thema/NGI0CommonsFund.html
  - bri3d 1y ago
    Academic projects which receive grant money to produce papers and slides. This still can advance the state of the art, to be clear, and I like the papers and slides coming out of this project. But I wouldn’t cross my fingers for a working solution anytime soon.

bri3d 1y ago

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.

qrios 1y ago
> (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.hw/external_lib/ethernet/arp_eth_rx.v https://github.com/chili-chips-ba/wireguard-fpga/blob/main/1... [2] https://github.com/chili-chips-ba/wireguard-fpga/blob/main/LICENSE https://github.com/chili-chips-ba/wireguard-fpga/blob/main/L...
- mort96 1y ago
  The safe assumption to make when met with a contradiction in licensing would be to assume that the more restrictive license holds, no? Especially when the permissive license is a general repo-wide license and the restrictive license is specifically applied to certain files. So for all intents and purposes, in my opinion, large parts of this Wireguard FPGA project are under this weird proprietary Chili Chips license. In fact, the license is so proprietary that the people who made this wireguard FPGA repository and made it visible to the public are seemingly in violation of it. It puts us in a weird spot as well: I'm now the "holder of" a file and am obligated to keep all information within it confidential and to protect the file from disclosure. So I guess I can't share a link to the repo, since that would violate my obligation to protect the files within it from disclosure. I would link to the files in question, but, well, that wouldn't protect them from disclosure now would it.

ericdotlee 1y ago

[dead]

louwrentius 1y ago

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 1y ago
> 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 1y ago
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 https://github.com/jedisct1/dsvpn
coppsilgold 1y ago
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 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 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.

exabrial 1y ago

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 1y ago
Do you mean specifically as consumer products? There are loads of 10GbE switches from Cisco/Juniper/Arista/et al.
- phatfish 1y ago
  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 1y ago
    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 1y ago
    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.
    - bigfatkitten 1y ago
      Second hand optics and preterminated fibre are cheap now too.

c0l0 1y ago

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 1y ago
When macsec exists?
- bc569a80a344f9c 1y ago
  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.
  - tecleandor 1y ago
    I have at least one switch that's MACSec compatible at line speed but I haven't had time to take a look. I guess this is confined to LAN and cannot do a MACSec link through the internet, isn't it?
    - bc569a80a344f9c 1y ago
      It’s port to port. It protects a link.
      - tecleandor 1y ago

soupbowl 1y ago

This is a very cool project! I had never heard of SystemVerilog until today.

altairprime 1y ago

Project page: https://nlnet.nl/project/KlusterLab-Wireguard/ https://nlnet.nl/project/KlusterLab-Wireguard/

geoctl 1y ago

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.

wmf 1y ago
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 1y ago
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-wireguard https://mullvad.net/en/blog/introducing-quic-obfuscation-for...
- geoctl 1y ago
  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.

BAPHOMETA88F 1y ago

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.

almaight 1y ago

[dead]

keepamovin 1y ago

Tangentially related, I've experimented with Tailscale and Zerotier and, tho I guess they have different audiences, I prefer Zerotier for reliability. Tailscale gets borked by existing VPN config, breaking things on local networks. I like both but does anyone care to share their experiences or explain more in depth the uses / differences as they see it?

stephenanand1 1y ago

[dead]

Surac 1y ago

A open source stack for Xilinx 7 chips is the most interesting take away for me here. I have to dig deeper

Frank00 1y ago

[dead]

clarionPilot11 1y ago

Wow, it’s crazy how much thought goes into these VPN designs.

sherinjosephroy 1y ago

[flagged]