9 ms·
If you're wondering what it is: WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, si
by kennu 7y ago
If you're wondering what it is:
WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable.
https://www.wireguard.com/ https://www.wireguard.com/
- numpad0 7y agoSo like IPSec? e: I mean that doesn’t suck
- simonh 7y agoIn that it's “leaner, and more secure than IPSec”?
- derefr 7y agoA 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.
- sirtoffski 7y agoWireGuard 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 https://www.wireguard.com/papers/wireguard.pdf
- lvh 7y agoThe 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.
- wbl 7y agoThe internet does not use OSI.
- duskwuff 7y agoIt 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.
- derefr 7y agoLayer 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.
- 867-5309 7y agothis is subject to interpretation
- vbezhenar 7y agoIPSec works fine with UDP and NAT.
- throwaway2048 7y ago"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
- vbezhenar 7y agoI'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.
- throwaway2048 7y agoYour NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.
- GhettoMaestro 7y agoBullshit. If you don't have ALG/fix-ups for FTP, IPSec, etc your device sucks.
- wahern 7y agoMore likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947 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.
- throwaway2048 7y agoNAT-T is unfortunately not very reliable.
- 7y ago
- bawolff 7y agoI 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.
- Noumenon72 7y agoWhat does it mean to be "in Linus' tree" if it's already on Linux and everywhere else? Like it will be built in somehow?
- tanderson92 7y agoNot 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.
- teruakohatu 7y agoTrue but now they have to put some small effort into excluding it, rather than a reasonable amount of effort to include it.
- MBCook 7y agoIt 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.
- therealmarv 7y agoRight 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.
- oarsinsync 7y agoRight 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.