Wireguard FPGA

What the FPGA WireGuard Is For

• Implements WireGuard directly in FPGA “gateware,” aiming for:
  • Wire‑speed encryption in hardware rather than CPU‑bound software.
  • An open, auditable alternative to proprietary VPN/NIC IP blocks and closed toolchains.
• Envisioned use cases:
  • Small “WireGuard gateway” boxes (office/home/cloud) that laptops/phones connect to.
  • Offload engine for embedded/IoT systems where MCU cycles and power are scarce.
  • A NIC‑like device that speaks WireGuard instead of plain IP.
• Several commenters also see it primarily as an educational / research project rather than a product.

Debate on Practical Value and Performance

• Critics note the reference board has only 4×1 Gbps ports; Linux WireGuard on mid‑range CPUs can already saturate 1 Gbps and approach 10 Gbps, so the “software is far below wire speed” claim is disputed.
• Others argue it’s still valuable:
  • Demonstrates a new implementation path; a hypothetical ASIC could win on cost and power per Gbps.
  • Hardware packet pipelines can keep line‑rate even in worst‑case small‑packet / big‑routing‑table scenarios.
  • Good teaching platform: affordable board, full stack to study.
• Discussion touches on bps vs packets‑per‑second as the real challenge at high rates.

Security, Auditability, and Toolchain Concerns

• Some are attracted by the idea of an end‑to‑end auditable stack: no secret NIC firmware, closed VPN appliances, or opaque accelerators.
• Others point out:
  • FPGAs and vendor toolchains themselves can be compromised; true high‑assurance would require trusted fabrication.
  • The repository’s licensing is confusing: a BSD‑3 top‑level license but many files with a restrictive proprietary notice, potentially overriding BSD.

WireGuard vs OpenVPN/IPsec and Deployment Realities

• A claim that OpenVPN/IPsec are “running out of steam” is challenged; detractors want concrete evidence.
• Pro‑WireGuard points:
  • Much smaller, simpler codebase; easier configuration and correctness reasoning.
  • Substantial real‑world speed and CPU‑usage gains versus OpenVPN, especially on weak CPUs.
• Counterpoints:
  • IPsec remains mandatory in many government and enterprise environments; commercial firewalls are built around it.
  • WireGuard lacks FIPS‑approved cipher suites and has an explicitly anti‑FIPS stance, which blocks adoption in regulated sectors.

Connectivity, Blocking, and Alternative Transports

• Travel/hotel Wi‑Fi:
  • OpenVPN over TCP/443 usually works; UDP for WireGuard is more often blocked.
  • Workarounds include tunneling WireGuard over TCP or obfuscated UDP (e.g. udp2raw), accepting performance loss.
• QUIC/MASQUE:
  • Some argue QUIC (or MASQUE over QUIC) is a compelling modern VPN/tunnel: TLS 1.3, FIPS‑friendly, AES‑NI acceleration, rich auth (mTLS, OAuth2, tokens), and “looks like HTTPS” for censorship resistance.
  • Others say it’s over‑complex versus WireGuard’s minimalism, can be slower on fat pipes, and stacking WireGuard‑over‑QUIC adds state machines and MTU pain.
  • There’s discussion of using QUIC directly as the tunnel vs using it as an obfuscation layer above WireGuard.

HDLs and FPGA Tooling

• Discussion of SpiralHDL/SpinalHDL, PipelineC, Amaranth, and other “neo‑HDLs”:
  • Pros: better clock‑domain abstractions, higher‑level constructs, host‑language metaprogramming (e.g., Python + NumPy for DSP generation).
  • Cons: lack of direct support in commercial tools; they emit SystemVerilog/Verilog, forcing debugging of generated code.
• SystemVerilog is defended for its rich feature set, especially for multi‑clock designs and verification; Veryl is mentioned as a promising “TypeScript for SystemVerilog.”

Alternatives for High‑Speed Links

• For data‑center or DCI links, several point to MACsec as a simpler, line‑rate L2 encryption option when switches support it.
• One commenter describes achieving ~15–25 Gbps+ with WireGuard on COTS Zen4 hardware using jumbo frames, underscoring that software can already go very fast with tuning.