What does it mean to be "in Linus' tree" if it's already on Linux and everywhere else? Like it will be built in somehow?

Right now, it is not part of the Linux kernel. It is just some random external software that you have you download and compile yourself against the source headers of the kernel you're currently running.

It got merged into the net-next tree, which meant it has been approved by the maintainer of the Linux kernel net branch to be included into the kernel. Linus has now pulled it from net-next into his own tree, which means it'll be included in the next release of the Linux kernel.

As far as that means as an end user, it means that you no longer need to recompile your wireguard module every time there's a kernel update, as now it will be handled by your distro.

That said, given that Wireguard is packaged nicely already for most distros, the end effect for you is really pretty little, as you're probably unaware of all of this complexity that's going on right now, as it mostly just works.

> As far as that means as an end user, it means that you no longer need to recompile your wireguard module every time there's a kernel update, as now it will be handled by your distro.

That's not the important point.

The point being, when merged as part of the kernel officially, you know it will get more support and eyes for stability and development power as the kernel wouldn't want to ship anything that's at some unstable state.

So you can expect long term usage and maybe RedHat might pick it up as its official VPN solution instead of libreswan some day.

>you know it will get more support and eyes for stability and development power as the kernel wouldn't want to ship anything that's at some unstable state.

This is a rather idealistic view on kernel development.

But it is true that when wireguard is “ready” this could very well result in a bit more support as larger orgs will be more willing to start using wireguard.

It will now end up in all Linux distros by default. Instead of having to chase it down and apply a bunch of patches it’s now just a single config option away.

Not all linux kernel modules are in the main sources. Many projects begin outside the main tree and are pulled in later after they have proven themselves and have matured, responded to criticism, etc.

True but now they have to put some small effort into excluding it, rather than a reasonable amount of effort to include it.

Right now Wireguard is using DKMS which is like a external Kernel module which needs to be rebuild on every Kernel update. When WG is already inside the Kernel no dynamic created DKMS are needed anymore.

So like IPSec?

e: I mean that doesn’t suck

A major difference, besides WireGuard's simplicity, is that IPSec is a layer 4 protocol (ESP packets instead of TCP/UDP packets) whereas WireGuard is a layer 5 protocol (runs over UDP), so switches don't choke on it, and so a WireGuard peer doesn't need a public-routable IP address, but can be behind NAT.

IPSec works fine with UDP and NAT.

"fine" with NAT is a bit of an overstatement, I don't think anyone who has seriously interacted with IPSEC would call it anything but a gigantic pain in the ass

I'm not "seriously" interacted, but I have VPN server and I'm using it on all devices in my hope (laptop, PC, phone) which are behind WiFi NAT. They work just fine. I'm using strongswan and IKEv2 on server.

Your NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.

More likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.

NAT-T is unfortunately not very reliable.

Try having more than one IKE responser behind same nat gw. Gets tricky to have both/all respond to udp 500...

WireGuard operates at layer 3. The first sentence from the white paper by Jason A.: “ WireGuard is a secure network tunnel, operating at layer 3...”. [1]

Regardless of the layer, in a few words WireGuard is a simple encrypted tunnel over UDP. Since it’s UDP - there’s no guarantee all packets will be delivered, BUT - what WireGuard places emphasis on is all packets delivered from the WireGuard interface will be authenticated and encrypted. Similarity if packets are received from a particular peer, replies to that IP address will be guaranteed to go to that same peer.

The best feature of all imho is OpenSSH inspired authentication - makes configuring server/peers really straightforward.

References [1] https://www.wireguard.com/papers/wireguard.pdf

The tunnel does not have to encapsulate messages at the same layer as the tunnel itself. Consider this thought experiment: if you send Ethernet frames over WebSockets, what layer is the protocol?

My understanding is the Wireguard messages are IP (L3) but the protocol messages itself are UDP (L4) and it seems reasonable to describe Wireguard as a session layer over UDP given how much state and connection information it maintains.

I see what you mean. Specifically in the context of VPNs I’ve always interpreted the layer in terms of the payload that’s being encapsulated - which as far as I understand is IP (L3) packets in Wireguard’s case.

Maybe due to my own ignorance I misunderstood the meaning of derefr’s comment. Apologies if I sounded rude!

No worries, you're fine, just trying to clear up the confusion. I've heard both terms used interchangeably depending on context. _Usually_ as an administrator you care about what's in the tunnel, but _usually_ as a designer you're worried about how the tunnel itself is communicated, so, yeah, confusing :)

The internet does not use OSI.

It never ceases to amaze me how stubbornly educators have clung to the OSI model. It describes a non-Internet protocol stack which was designed in the 1970s, and which was never fully implemented. Attempting to use its layers as an ontology for Internet protocols is doomed to failure, as some of its layers (especially Layer 6) describe components which have no direct equivalent on the Internet.

Layer 6 exists, it’s just that most layer 7 protocols “fix” their layer 6 protocol. E.g., JSON/RPC requires JSON; SOAP requires XML; etc.

But Layer 6 is where the difference lies between ASN.1’s representational encodings—DER, BER, XER, etc. You can switch out this “presentation layer” encoding without either your application layer caring (it just sees an ASN.1 codec library) or your transport layer caring (it’s just transporting an opaque octet-stream payload document.)

One might also describe Avro, Parquet, etc. as “presentation formats”—they all have canonical input ADTs, but multiple possible wire encodings depending on the schema supplied at encode time. But all such schemas decode back to the same input ADT.

OK? The Internet does not use OSI, but it sure was helpful just now as an educational tool for describing that "what layer a VPN operates on" can be confusing. Even if you don't literally use OSI layers, knowing that UDP builds on top of TCP and having a common vernacular to express that is pretty useful. Given that the entire thread was already using specific OSI layers (which have clear mappings to things the Internet does do), starting by saying "the OSI model is not what the Internet actually does" does not seem to be the most productive avenue towards fostering understanding :)

L1 to L4 are just a shorthand way network engineers talk about:

  1. The physical connection and voltage/light levels
  2. Switching and MAC addresses
  3. Routing and IP addresses
  4. TCP/UDP and port numbers

Of course we know it's more complicated than that, but it's still a useful simplification.

this is subject to interpretation

In that it's “leaner, and more secure than IPSec”?

I dont know why you're being downvoted. It is a vpn protocol, just like IPSec, with the main difference being its much simpler, and hence "sucks" less.