Rather, I expect what the parent wanted to assert was that a novel malformed packet to a badly written VPN shouldn't bring down the entire VPN gateway machine, but rather just the VPN daemon itself, which can then be brought back up by init(8).
Or, to put it another way—even though the Linux kernel is monolithic, it can still pay to treat it as a microkernel and isolate fault-prone code outside of it.
This was one of the original big benefits of running e.g. the NTFS-3G in FUSE, when that support was experimental: the NTFS-3G driver did crash—often!—and your OS stayed up. The—usually external—drive would just get unmounted, and have to be fsck(8)ed.
Now, the argument you used also kind of answers this: in full deployments, we've got dedicated VPN gateways on either side of the connection, so if the VPN process crashes, the whole machine may as well have crashed, since it's not doing much of anything else anyway.
That's probably true for most networks, but I could think of one exception: a VPN gateway serving multiple customer sites. You'd really rather that one VPN "receiver" process crash on that host (like one webserver instance serving one request) than that the whole machine crash.
> But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs.
You're missing the other big use case: VPNs used to get one's internet access through a different network, in order to evade the Great Firewall, limit NSA surveillance, increase security on public Wi-Fi networks, or just watch Netflix in the 'wrong' country. These are often commercial (not that commercial VPNs are going to use WireGuard as long as it's Linux only, but hopefully it'll be ported to other OSes before long). In this case there are two ways the client could be attacked: the network itself could be modifying packets or doing a MitM attack, or the server could be hostile (either after being hacked itself [maybe with the same exploit] or, mostly applicable to government attacks, because it was set up as a honeypot).
With a network attack, the VPN code is one of the only bits of attack surface available to the attacker, especially if they don't know your IP on the other end. A hostile VPN server you route all internet access through, in comparison, already has quite a lot of power over you (hopefully you access all important services over TLS), and at the very least makes it easy to deliver (easier-to-find) browser exploits - but in theory the VPN implementation provides some additional attack surface which bypasses all sandboxes. Also, paranoid users may have a setup where their browsing is done inside a VM, whose connection is routed through a VPN on the host end. This helps ensure that they're not accidentally passing traffic through the wrong interface or leaking their real IP, and provides some protection against attackers who get code execution with the goal of finding said IP (see FBI Tor malware). In such a setup, any networking code running outside the VM is an interesting target.
Linux isn't all that secure against unsandboxed user processes, but VPN code has a simple enough interface that it could in theory be sandboxed effectively using seccomp-bpf.
The Great Firewall tries to block VPNs anyway, so a Chinese attack isn't all that realistic as things stand, but who knows, it might be nice if WireGuard grew some kind of obfuscation support. And that leaves the NSA and others.
Anyway, I don't actually think there's a problem with WireGuard living in the kernel! - because I don't think it presents much attack surface. It's a very small codebase, and performance is important for these applications. Actually, I wholeheartedly approve of WireGuard: it seems like a really nice design, and I've experienced the pain of just getting other VPN implementations to work, never mind securely. But if there is a vulnerability in WireGuard, then for the reasons I've stated, I think its placement in the kernel matters.
I doubt WG is a real candidate for the case you're talking about.
Web proxies are suboptimal because they only work with web traffic, or even if you use HTTP CONNECT, only TCP. SOCKS is mildly better at a protocol level, with SOCKS5 supporting both TCP and UDP, but still suboptimal if the server end is able to give each client its own IP address (not so common with IPv4 but easy with IPv6), due to the existence of protocols other than TCP and UDP. More importantly in practice, SOCKS clients are typically implemented in userland rather than the kernel, so each individual application needs to be configured to use the tunnel. There is software that lets you use any program with SOCKS by hooking socket API calls, but that's essentially a hack, and has many practical issues. Much nicer to just have the tunnel as a network interface like any other, and let the kernel's network stack work as it was designed - which is usually done with VPN software. VPN also lets one host transparently handle proxying for another, e.g. a router for a home network, or the host in the VM setup I mentioned in my original post.
You're talking about two completely different use cases with very different goals and potential issues.
You mean like lvs/ipvs? [0]
> How about some TLS termination?
You mean like the KTLS project from Dave Watson/Facebook Engineering? [1][2]
[0] http://www.linuxvirtualserver.org/software/index.html
Since we appear to be bolted to the top of the thread, I'll repeat a point I buried deeper in the thread:
Maybe some readers of this thread are in the habit of casually bringing up random VPN connections between individual Linux machines. But in my experience, people tend to invest in VPN configurations so they can connect developers and ops to deployment environments and company networks. That's like, the big use case for serious VPNs.
In a serious VPN deployment, if you lose code execution on the VPN server, whether the attacker took the kernel or just a userland process is somewhat far down the list of concerns you have to deal with. A better first concern is "how many machines inside the VPN did the attacker just get code execution on because they can now make direct TCP connections to all our internal services".
From that vantage point, I'm a little less concerned about whether my VPN server is at CPL0, and a lot more concerned with things like "how complex is this code and how straightforward is it to audit".