VPN connectivity #152
Replies: 5 comments
|
what's the use case? |
|
Hello |
|
Hi @jlayec, 1. A permanent SSH tunnelFor exposing one or a few TCP services, a permanent SSH tunnel is a perfectly valid solution. A reverse tunnel can work even when the gateway is behind NAT, and it is straightforward to secure with a dedicated key, Its advantages are simplicity, mature tooling, and a very small operational scope: only the explicitly forwarded TCP ports are reachable. It is therefore a good fit for occasional administration, SSH access, or one remote Zigbee/TCP endpoint. The trade-offs are that it is not a general IP network: UDP, broadcast/multicast traffic, and arbitrary LAN access need additional mechanisms. Each new service also needs its own forwarding rule. It can become less convenient if the requirement evolves from "reach one service" to "make the gateway and a remote network mutually reachable". 2. Why WireGuard rather than OpenVPN when a real tunnel is neededIf a layer-3 tunnel is required, WireGuard is the more realistic option for this gateway. It is in the Linux kernel, has a small configuration surface, no userspace daemon for the packet path, and uses modern fixed cryptographic primitives. It also has a much smaller memory and flash footprint than an OpenVPN stack and avoids TLS/certificate management. OpenVPN remains a good choice on more capable hardware when its mature feature set is needed, but it is comparatively heavy for a 400 MHz RTL8196E with 32 MB RAM. On this device it would add more userspace overhead and would not be expected to outperform WireGuard. 3. WireGuard implementation and measured performanceWe have compiled and installed WireGuard successfully on the 6.18 firmware, including the required kernel crypto support and the small We also measured it on the development gateway with
The tunnel is stable, but encryption is CPU-bound on the RTL8196E. The resulting roughly 8.5 Mbit/s is appropriate for administration, MQTT, remote Zigbee/TCP access, and other low-bandwidth control traffic. It is not intended to carry sustained LAN traffic or large transfers. The networking data path is therefore noticeably affected when WireGuard is enabled and actively carrying traffic. WireGuard will be shipped in v4.0.0 as an optional feature for the 6.18 kernel. It will be disabled by default; users who need it will be able to explicitly enable and configure it. |
Update: measured SSH tunnel performance and 7.1 supportWe have now measured a persistent SSH local-forward tunnel as well (with keepalives), using 15-second TCP
For this hardware and this use case, the persistent SSH tunnel is therefore the more attractive choice when only one or a few TCP services need to be reached. It is noticeably faster than WireGuard in our test, while remaining simpler to operate and more narrowly exposed. There is one caveat: SSH forwarding carries TCP inside the SSH TCP connection. In the host-to-gateway run we observed 44 TCP retransmissions, so it is not a suitable replacement for a general network tunnel or for sustained bulk transfers. For a Zigbee TCP bridge, administration, or a small number of control services, however, it is a very good fit. The forthcoming v4.0.0 WireGuard implementation has also been ported to both supported kernel lines, 6.18 and 7.1 (not only 6.18 as stated above). It remains opt-in and disabled by default. WireGuard is still the right option when a real routed IP tunnel is needed, including UDP or several services; the measured throughput simply sets realistic expectations for this 400 MHz gateway. |
WireGuard in v4.0.0 — what shipped, and a correction to what I told you@jlayec — v4.0.0 is out, and I have to correct something I wrote here on 3 August. I said WireGuard would ship "as an optional feature, disabled by default, that users who need it will be able to explicitly enable". That is not quite what happened: the tooling and the recipe ship, but the kernel driver is not built into the released images, so enabling it now means rebuilding a kernel rather than flipping a config flag. Here is why that changed, because the reason turned out to be more interesting than the feature.
|
| build | TCP TX (Mbit/s) |
|---|---|
CONFIG_WIREGUARD=n |
69.95 |
CONFIG_WIREGUARD=y |
66.3 |
everything WireGuard selects, but WIREGUARD=n |
70.1 |
| 71 392 bytes of inert padding at WireGuard's link slot | 66.9 |
The third row rules out the dependencies it pulls in — NET_UDP_TUNNEL, DST_CACHE, GRO_CELLS, the CRYPTO_LIB_* family — they cost nothing. The fourth row is the answer: dead bytes at the same position in the link reproduce the loss exactly. WireGuard is declared at drivers/net/Makefile line 13, ahead of ethernet/ and therefore ahead of the whole network stack, and its ~71 KiB push every hot symbol downstream — rtl8196e_poll by 81 920 bytes, __dev_queue_xmit by 64 724, softnet_data by 90 368. On a core with a 16 KiB instruction cache and an 8 KiB data cache, that relocation is worth several percent. Runs were interleaved n, y, n, y so drift could not be misread as effect.
Charging every gateway 5 % of its TX throughput for a feature that defaults to off was not a trade I was willing to make for everyone, so the shipped configs carry # CONFIG_WIREGUARD is not set.
CONFIG_WIREGUARD=m may well be the better route, and this release is what makes it possible
CONFIG_MODULES=y simply failed to build on this port until now — arch/mips/include/asm/vermagic.h picks MODULE_PROC_FAMILY from a cascade of upstream CPU types and falls through to an #error, and the Lexra core matches none of them. v4.0.0 adds an RLX4181 arm to that cascade, so a modular build is available for the first time.
That matters here specifically, because the cost above is positional: built as a module, WireGuard is not in the vmlinux link at all, so it cannot push the network stack downstream. The measurement is consistent with that — MODULES=y WIREGUARD=m gives 68.0 / 67.9 against a shipping baseline of 69.6 / 67.4, a gap of 0.55 against a ±0.9 repeatability floor, so no measurable cost, even though CONFIG_MODULES=y adds 381 KiB to .text, five times what WireGuard itself adds.
What was not measured is a module actually loaded and carrying traffic. Whether running from vmalloc space penalises the tunnel against a built-in driver is an open question, and I have no data on it. If you take this route, I would be glad to see your numbers.
What you get instead, and how to turn it on
Everything else is in the release, under 3-Main-SoC-Realtek-RTL8196E/34-Userdata/wireguard/: the wg(8) tool, a minimal RTNL link helper, a wireguardctl lifecycle script with genkey/enable/disable/status, an init hook that is a no-op while ENABLED=0, and a config template. The optional/ subdirectory mirrors the on-target layout, so installing is a plain copy. Its README.md carries the full recipe and the numbers above.
Three steps: set CONFIG_WIREGUARD=y in 32-Kernel/config-<line>-realtek.txt and rebuild/flash the kernel, run ./build_wireguard.sh for the userland, then copy optional/ onto /userdata. It works on both kernel lines, 6.18 and 7.1, as I said it would. Expect the throughput cost — it is not a bug and no amount of tuning removes it.
For your actual use case
Nothing changes in the recommendation I gave you: a gateway reaching a remote home-automation server over a routed IP tunnel is exactly where WireGuard earns its keep, and the ~8.5 Mbit/s measured through the tunnel is fine for MQTT, Zigbee/TCP and administration. If it turns out you only ever need one or two TCP services, the persistent SSH tunnel measured above is faster on this hardware (12–15 Mbit/s) and simpler to operate.
If you build it and hit anything, say so here and I will fix it.
Uh oh!
There was an error while loading. Please reload this page.
Hello
This repo is fantastic.
I was wondering if we could imagine having openvpn and wireguard available with binary pre compiled for that gateway?
Does the performance of the cpu is enough for a vpn piece of software?
What do you think?
Jerome
All reactions