- It has a vastly smaller attack surface than e.g. OpenVPN, because it is much less complex.
- Its performance is improved by being kernel based.
- Compatibility is helped by it being in the mainline kernel, i.e. every device shipping a recent enough kernel will be able to have it (no need to deploy/version libraries etc).
re smaller surface area, adding some numbers, "WireGuard weighs in at around 4,000 lines of code; this compares to 600,000 total lines of code for OpenVPN + OpenSSL or 400,000 total lines of code for XFRM+StrongSwan for an IPSEC VPN. Two orders of magnitude fewer lines of code mean a lot less attack surface to find flaws in."
https://arstechnica.com/gadgets/2018/08/wireguard-vpn-review...
note openvpn sans openssl is 70k (supports multiple crypto libs), but given Wireguard's code size is including crypto, it seems apt to compare totals.
linus on a comparison, "Can I just once again state my love for it and hope it gets merged soon? Maybe the code isn't perfect, but I've skimmed it, and compared to the horrors that are OpenVPN and IPSec, it's a work of art."
https://lwn.net/Articles/761939/
ZeroTier's core is only about 30k lines of code including quite a lot of verbose multi-line comments, crypto, C++ cruft, and boilerplate. Core functional code implementing ZT is probably roughly 2X the size of Wireguard. How in the hell is IPSec that big?
It's bigger if you include all the service and virtual net device and UI stuff, but IPSec doesn't include any of that so comparing to the ZT core is apples to apples.
It does dynamically allocate, though it always checks for success. It could be refactored not to but so far we haven't targeted devices small enough to worry about a megabyte or two of RAM. There are also checks in place to guard against memory exhaustion attacks where applicable.
We just did phase I of a professional audit for V2. It was a design audit, but we're doing a code audit too. V2's code base will be a bit cleaner.
Cool! Just a thing to think about! Code size is a useful metric, especially as it improves auditability. But not having to think about object lifecycle bugs ("can this timer fire into a freed connection state block", etc) is a huge intrinsic structural win. Having an unusually clear, audited documentation of the lifecycles of all the objects in your design would also go a long way.
I was trying out ZeroTier a few years back and found it fantastic. I was, at the time, working for a large security network device provider and trying to get R&D to bake it into the flagship product - this was before SD-WAN really took off. I never got anywhere with that agenda, but - still think that would have been a fantastic use case.
I'm curious if the stalwarts of the network security space, with their old and crusty VPN concentrators, finally move on WireGuard. Likely not until enough customers move away from them to a solution using, or they get around to finally running a recent kernel.
Crusty stalwart here. I'd love to get off crusty VPN concentrators. I'd personally love to see something in the open source space that supports 2FA and a rich, user-based policy language. Tailscale is trying to deliver an enterprise product that builds this on top of Wireguard. I'm not aware of any open source approaches tackling this problem like Tailscale, but I'm keenly interested.
Curious if you can provide any links to exactly what you need. 2FA is obvious but what kinds of policy languages are you thinking of? There are numerous variations out there.
Wireguard is 6k lines if you don't count tools, crypto code, tests, etc. And god knows what is counted in those 600k lines of OpenSSL+OpenVPN, probably all kind of code that's not really used at all by OpenVPN.
It's still smaller, but no need to do useless comparisons.
But these are related, aren't they? Not trying to be pedantic or argumentative at all, just better understanding (for myself at least). Being kernel based means it cannot depend on external/3rd party libraries, which does reduce the attack surface. Of course user-land library can also be written with no other library dependencies, but I think kernel based forces this as a requirement, doesn't it (I don't know for sure, please correct me if I'm wrong)?
Moving something from userland to the kernel is not generally understood to be attack-surface-minimizing. One of the goals of attack-surface-minimizing designs, like privilege separation, are to get as much out of the kernel (or out of privileged processes) as possible.
Hosting WireGuard in-kernel is a performance and compatibility strategy. Being hosted in kernel makes WireGuard higher-risk, which Jason mitigates with other software security tactics, like a simple design that can be implemented without dynamic allocation, and a tiny codebase.
This goes both ways. Userland systems are susceptible to a myriad of attacks that a kernel, being privileged code, is not. We rely on the kernel (plus CPU rings) for most of the security enforcement in a machine, after all.
However, IF that code is compromised, the consequences are much more catastrophic.
Viewing/editing of another userland process is usually done using ptrace(2). Yama Linux security module prevents that unless you are root to disable it. It is active by default on Ubuntu.
Also reading /proc/nnnn/mem does not work even for your own processes and even though file node protections seem to allow it, not sure where that security enhancement comes from.
I have been a bit weary of the WireGuard hype for much the same reason. Surely kernel mode is (a) the equivalent of running as root (b) opens up greater attack surface by virtue of running at kernel level
I have only experimented a bit with WireGuard because I wanted to avoid OpenVPN. The argument seems to be that it's more secure because it's implementation is small (the implication being that it's easier to audit) and being in the kernel ensures mass adoption (ensuring even more likelihood of audits and quick patches.) I'm interested if there are other technical advantages for specific threat models.
Hm. I guess no-one has bothered with nftables yet, even when dealing with network code that's becoming part of the new upstream kernel (not just this blog, AFAIK wireguard upstream doesn't have any examples on using nftables either, just iptables).
I guess we need a new networking how-to?
Anyone aware of some resources I might have missed?
The community kind of skipped right over nftables to BPF. Simple use cases use iptables, complicated ones use BPF, nftables isn't flexible enough for the complicated use cases so everyone keeps using iptables.
@WGH_ You're dead - presumably because the profile is new, and immediately made a comment? I think maybe anti-spam is a bit aggressive, unless there's some linked account that accounts for the ban?
At any rate, I agree information on bpf as a iptables work-a-like is scarce. This helps a bit:
What is BPF (in the context of iptables/nftables replacement) exactly? I tried searching for it, but only found some articles about early stage kernel support. Nothing about userspace or how to use it at all. It looks like there's still no BPF firewall at this time.
We're using BPF for packet filtering in production on my team today, but it's not directly an iptables/nftables replacement- it's an entire kernel subsystem used in several parts of the kernel and also useful for diverse use cases such as performance profiling, syscall tracing and packet filtering. It's also seen rapid development in recent kernels and most internet articles about it are out of date.
Something I wrote for the ArchWiki [1]:
> BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.
> BPF was originally an acronym of "Berkeley Packet Filter" since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.
lwn.net has a decent (although 3 years old) intro article [2]. Cilium has a good document on how they use BPF to implement a packet filter [3].
IMO nftables is best used with your full ruleset defined in a file, and atomically loaded. nftables certainly does make your ruleset more grokkable than statefully appending ad-hoc rules everywhere, but you necessarily need the whole picture to gain from it.
So unfortunately it makes less sense for one-liners. Case in point: to use the masquerade action in a postrouting/nat chain, you also have to register a (possibly empty) prerouting/nat chain.
So unfortunately it makes less sense for one-liners. Case in point: to use the masquerade action in a postrouting/nat chain, you also have to register a (possibly empty) prerouting/nat chain.
Does wireguard have a noticeable overhead wrt data size compared to a unencrypted connection? I was thinking of setting up it on a small RPi-Like board at home, then on the laptop I carry around (when the lockdown is over). The purpose would be connecting to the Internet through the home broadband public IP which could be handy. However the laptop connects through a metered 4G connection which, although the data cap is more than reasonable, raises some concerns should the encryption require a lot more data than normal.
I just sent 200MiB of zeros over my wireguard connection to my VPS and my transmit counter on my wifi card went up by 238MB. Vs sending 1024MiB over just wifi to my Pi where the transmit counter went up by 1.04GiB.
I know its orthogonal to WireGuard itself, but I'd like to see these guides sometime provide some guidance around DNS, so that I can access services without having to remember the VPN client IP addresses.
If you're using NetworkManager and wireguard, try out the integration between the two as well. It lets you treat the tunnel as any other VPN in nm, and also easily avoids some issues with routing loops if you roam back on to your home network. Before, I always had to manually use wg-quick when I came back home or left.
In my experience, this does work somewhat, but doesn't set up the routes properly[1] and doesn't provide an interface to the networkmanager applet, so you are still left with configuring the profiles in the terminal. There is much left to be desired. Sadly the third-party plugin isn't much better and seems to be discontinued[2].
Interesting. I haven't had that happen because I do split-tunnel, but I will have to keep that in mind in scenarios when I try to forward everything thru the tunnel. All I needed to do for split tunnel was just adjust the route metric. (https://tujun.ga/2020/02/18/wireguard/) Agreed about the lack of GUI though, I do wish there was a GTK applet for it.
also available in ubuntu 20.04 (universe) via the dkms/module support thats been standard for use w/ wireguard for years. wireguard also just hit 1.0 from a stable api perspective.
One thing that is imo downplayed about WireGuard as opposed to other VPNs is ease of use, specifically:
- setup is easy
- automated config of large setups is easy
- it is extremely resilient under network temporary failure
It's not really different from what's shown here, only you set AllowedIPs to a single address instead of all addresses (0.0.0.0/0). Here's a short guide I just wrote: https://jtvjan.nl/documents/s2s-wireguard.md
Assuming you meant Wireguard both times, I have a small guide I wrote for my team that I can throw up on my site. If I don't post a link here in a couple hours, reply here so I get a notification.
If you are just interested in configuring clients, Wireguard for Windows comes with a GUI that you can use. For Mac I'd suggest just using wg-quick[^1].
Excuse my ignorance, but can someone explain why a kernel based networking stack has less of an attack surface then a user-space based stack?
I mean logically user-space should be more secure no?