WireGuard Gives Linux a Faster, More Secure VPN
wired.com
wired.com
The level 3-only tunnel is motivated as "the cleanest approach for ensuring authenticity and attributability of the packets" (in the whitepaper), but in fact every claim and routing algorithm described (needed since the tunnel is many-to-one) would work equally well substituting "ip address" with "mac address" (i may be missing something, but for sure it's not explicit anywhere). And indeed imho it would be less surprising to have an "allowed mac address" option in the configuration than an "allowed ip address": it's already common practice to white-list mac address of physical endpoints (in office). I'm toying with the idea of forking the driver code to adapt it to ethernet frames as i don't think it would need any big rewrite but i'm realizing my inexperience in writing kernel code.
Finally, how can ZeroTier’s support be so incompetent to not recognize connectivity issues between endpoints? That’s one of the few things that goes wrong with tunnel meshes.
Symmetric NAT basically breaks everything that doesn't use a simple client/server hub-and-spoke networking model.
I'm not the only one with external NAT that I can't do anything about; the question is what to do to mitigate this.
Switching to an explicit hub-and-spoke model would work around this, but at the expense of what I consider one of ZeroTier's biggest strengths: transparent meshing. If two machines in the network are on the same LAN, I'd like them to use that rather than the network.
Faster detection of the failure of the NAT-piercing peer-to-peer link, with fallback to the "moon" while the peer-to-peer link is being re-established, would substantially increase the usability for people, like me, who are stuck with the NAT they've got. As I alluded to, the new multi-path features that ZeroTier is getting might help with that.
In addition to device discovery, these are frequently used for heartbeat messages to indicate that you are still alive (for high-availability protocols like VRRP).
It was a strange beast but there were a few odd spots it was better than active directory - e.g. an "Organizational Role" could be created and have a user assigned to it, so you could more easily seperate the user (john smith) from their position and the permissions that go with it (finance director). So when john smith retires it is trivial to replace the occupant of the finance director organisational role.
That way the sender doesn't get delayed by unknown turnover, and the new recipient has full history to look back upon instead of starting cold.
Once set up, I can shut down a machine at one location, move it, bring it back up, and it's back in business. There are situations where we might want to migrate to new machines during the move, which this makes no harder. But for many things it makes them easier.
For example, the last move went something like this: Set up the VPN+bridge. Move half the application servers. Set up new firewall/load balancer since we were replacing the old ones. Test the new fw/lb. Physically move the primary database server during a maintenance window and switch over to the new fw/lb. If there were problems, just switch back to the old one via DNS record changes (TTL was lowered weeks earlier). Move the remaining app servers. During the bridging setup, the LBs preferred the local app servers.
EDIT: *and proxy arp requests through
There's still the issue of authenticating IPv4 IPs though, which are too small to embed anything useful into. ZeroTier has a certificate system for that but it requires the use of the rules engine to enable it.
lol
20 years ago, in college, some folks in the dorm had fun fucking with others at the Ethernet level. Most of us only had experience with the IP level, so couldn't understand what was going on.
https://github.com/zerotier/ZeroTierOne/blob/master/node/MAC...
There's a tiny chance of a collision, but for it to be meaningful you'd have to have a virtual LAN with millions of devices on it.
You'll want to use a crypto based identity if you want to ensure spoofing isn't occurring. Even then, you can still be DOSed by a malicious actor. Tools like eBPF may be able to help here by filtering out source MAC addresses that don't match the source interface's hwaddr.
edit: Sorry, I didn't read this comment properly. In ZeroTier I can believe that they cannot be spoofed across the VPN due to relying on a cryptographic hash. :)
Your down voting is caused by you used the word MAC without defining what it is, so naturally people think it's a "Media Access Control Address", or a "Message Authentication Code", but it's far more complex than either. It is an address so it does perform the same function as a "Media Access Control Address", but [0] says it is "computed from the public portion of a public/private key pair. A node’s address, public key, and private key together form its identity.", and uses proof of work to prevent forgeries. Thus your statement that "MACs can't be spoofed" is correct, or at least is unless someone breaks it. The "proof of work" bit did cause an eyebrow to rise, as it is vulnerable to exponentiation drops in the price of computing.
For those still reading, my (very brief) look at ZeroTier is it does far more than IPSec / Wireguard - it solves the internet scale routing problem in it's own way, address spoofing and a number of things as well. It's undoubtedly far simpler to use than Wireguard or OpenVPN, as routing with those protocols in large networks is a complete PITA. It treats IP rather like IP treats Ethernet - as a fabric it runs on top of that unlike Ethernet connects most nodes on the planet. For nodes that aren't fully connected (like those behind a NAT, it creates paths (ie, does routing), and if multiple paths are available uses several concurrently to get the best throughput.
[0] is well worth a look if you are curious about such things. I am going to take a much closer look when I get time.
This is paranoia about all the wrong things, focusing on irrelevant details and ignoring what’s important.
The suggestion is simply this: Don't embed your MAC address into your IPv6 address because it's a unique identifier that can deanonymize you even if you shift networks.
The chain of thought typically goes like this:
* Remote networks are connected via L2 tunnel.
* ARP requests are broadcasted over L2 tunnel to all connected networks, introducing scalability issues
* Proxy ARP is introduced to cache ARP responses
* Proxy ARP may become out of date or not scale as the L2 domain grows.
* BGP is introduced to keep track of and broadcast all topology changes
* How do you mitigate issues caused if Proxy ARP fails?
Most of these issues go away if you use IP tunnels instead of Ethernet because IP was designed to be routable.
For your point on security... Whitelisting MAC addresses doesn't provide security. These are trivial to spoof. Same with IP. Please start relying on cryptographic primitives to establish workload identity instead. I highly suggest looking at SPIFFE to get started here.
If you must send L2 over the VPN, please go use a L2 EVPN which is designed to handle the complexity and provide fault tolerance. There are numerous SDNs out there you can use to implement this including Tungsten Fabric and OpenDaylight. No need to complicate Wireguard to support EVPN.
[edited to improve formatting of bullets and clarity of wording]
Logical functionality should be decoupled to ease maintenance, reduce risk from complexity.
Config management tools can dump some text in a file for corporate needs.
Apply it over SSH or via git.
It’s just a bit of text to lay down.
I have one deployed on Digital Ocean ($5/mo droplet). All you need to do is run the setup script, answer a few yes/no questions (optional features), paste in your API key, and update the firewall setting on Digital Ocean's dashboard.
If anything goes wrong, deploying a new one only takes minutes.
At least, not without spending a great deal of my time or a great deal of my personal money to build a suitable rugged production-grade service.
In the case that no automatic deployment is necessary, it may also be useful to look directly at the WireGuard configuration [2]. Since WireGuard supports scripts in "PostUp" and "PostDown", I have automated the configuration of iptables, including some useful rules to redirect 53/UDP port traffic from the public interface to WireGuard, which helps in some cases to bypass some firewalls.
[1]: https://github.com/hectorm/wireguard-setup
[2]: https://github.com/hectorm/wireguard-setup/blob/master/packe...
Could this be a positive change? Does this represent a healthy response cognitive fatigue in a world with configuration options at every possible layer?
Or does this shift to less readily configurable tools represent an overall negative? Are we losing diversity in favor of a more vulnerable monoculture crop?
Or both?
Asking for real, not sarcastically. As a developer I’m a huge proponent of simpler, more opinionated frameworks for most projects but I’m also aware my perspective is more limited than many HN commenters.
There are some cases where opinionated is just fundamentally better. I'd say that a good example of this is code formatting tools. These have been historically highly configurable, but that creates huge amounts of room for bikeshedding and conflict, where consistency is by far the most important thing and the actual style itself barely matters unless you start getting silly.
I think it essentially becomes a sliding scale on how much consistency and "getting it right" are more important over having something be optimal or perfectly adapted to the situation.
When it comes to security tools like VPNs, reducing the chances for users to shoot themselves in the foot is almost always more important than anything else, so it seems like another area that would be beneficial to have something more opinionated rather than more configurable, so the decisions are in the hands of people who have invested the time in understanding the problems at hand.
[0] https://en.wikipedia.org/wiki/Unix_philosophy#Program_Design...
After using WireGuard for 5 minutes I knew this was going to be a big thing.
IPsec has too many fucking knobs. It is it’s pitfall.
I wonder if any specification group has ever thrown up their hands and said, “you know what? Fine. Let’s just create one named sub-protocol for the way each of you major players does things; and then have the clients of this protocol do a sub-protocol negotiation; and then have the client use a plugin specific to the sub-protocol that’s been negotiated. Then you don’t need any knobs; all the policy can be baked into the plugin.”
(Come to think of it, this is kind of how the authentication phase of SSH works, when configured to use PAM. “Pretend we’re MIT” (a.k.a. Kerberos); “pretend this is a Microsoft Active Directory domain” (a.k.a. NTLM auth); etc.
Wireguard is not opinionated, it just has a very limited scope. It has one job, to create an encrypted tunnel between two endpoints, and leaves literally everything else up to other tools to build higher-level functionality upon. Contrast with OpenVPN which requires you to be your own TLS certificate authority and all the complication that goes along with that.
I see it more as "convention over configuration". If you want to (or need to) tweak the configuration and settings extensively, then that tool is perhaps not for you, and that's ok. Perhaps you are a subject matter expert, and you want more control.
If you're ok with sane defaults (that were chosen by subject matter experts, and you are not one), then "opinionated" is a great thing.
Whether it impacts a specific use case is usually here nor there - it’s usually about maintainability. And while finding contributors for open source projects can be difficult, finding people who want to do the thankless work of maintaining code long-term is much harder.
That's one way of looking at it. Another way of looking at it is to emphasize minimalism, the UNIX philosophy, and keeping maintenance burdens low. Sometimes, neither is the case - Ruby on Rails being the classic example of an opinionated framework, one that did expand to add additional functionality over time.
Definitely programming languages are on the periphery of this conversation, but I think provide some good examples of why I like opinionated tools in general.
My language of choice right now is Go, and has been for a while. One of the things I like about it is that it's a bit opinionated. For example:
Braces around `if` statements aren't optional. I prefer this to other C-Like languages that allow you to leave out braces for one-liners.
Also the document "Effective Go" exists, which lays out the canonical "best" ways of doing a lot of things. The language doesn't force you to do these things, but there is an authoritative source that makes good suggestions.
The Antithesis of opinionated languages in my opinion is Ruby. I personally hate Ruby, but I know there are a lot of people that love it. I hate it because there are too many ways to of accomplishing the same tax, and to me this makes it harder to read. Go, on the other hand is the easiest language for me to read, largely because of `gofmt`, another thing that doesn't force you to do it a certain way, but strongly encourages a standard end result.
I've done a fair amount with Elm, which is undoubtedly hugely opinionated, doing things like locking JavaScript interop behind a message passing system and baking protection from XSS into the language.
Mostly I'd say this all encourages you to do things a better way, but it can be painful, and particularly given the early nature of the language, meeting the edges of the language can be very painful because of it.
In contrast, I adored working with Scala because it was so powerful, but it sits close to Ruby in the "you can do everything a million different ways" rankings. The more I did with it, the more I wanted a refined subset of what was there (which may be what Dotty/Scala 3 ends up being).
Things like "you must always use braces on if statements" are rules I always end up enforcing using tooling anyway because they are just bugs waiting to happen, and are the low-hanging fruit of this debate. Too many language take the approach of "if we can parse it, it's fine", when really the aim should be to make it clear not just to a parser, but to the person reading/writing the code too. Hopefully more languages are more opinionated about that kind of thing in the future.
I've frequently described Go as a very, very good 1990s language. Going through the process of maturity takes time. You can't have a "very, very good" 2020s language right now, because at the frontier we're still feeling our way through the issues.
(Remember, whatever you're about to hit reply with and try to contradict me about it being a totally smooth and polished 2020s language that's already here is also an assertion that your example basically has no room for improvement and will not improve in the next 10-20 years. Consider your options carefully before you go too "language partisan" here.)
I believe probably >75% of the hatred Go engenders is from people afraid that Go's success will erase or invalidate the 2010s/2020s languages they prefer, because otherwise, the solution to most of these people's hate/anxiety would be to just ignore Go. To which I can say to those people, you can stop worrying. It won't. And if you stay in the industry long enough, maybe someday you'll get to use the really good and polished 2010s or 2020s language. No idea what it'll be called. And you can similarly assuage the fears of the day that this new language will erase all the benefits of the 2040s languages in development at the time.
But for "opinionated" to really work, I think you intrinsically need to have years of experience to make the right calls. There's no realistic chance that we could have gone straight to the "correct" VPN choice in one shot. Too many variables, too many dimensions, too much to learn and know about the security. It's just not possible. We collectively need the decades.
It can be. In fact it's almost essential if you are handing out knives to children; you want someone doing who is very opinionated about the dangers posed by sharp knives.
There was a recent HN post making the same point about JWT's. JWT's allow the null cipher, and in the hands of people who might not appreciate the disaster caused production code accepting JWT's using the null cipher you want a _very_ opinionated implementation that prevents it.
But for me, such an implementation would be a total pain in the arse. The null cipher is there to make debugging easier - getting things working for the first time can be very difficult without it. You can stick your opinions on whether I should be using it where the sun don't shine.
In the Information Age, attention and cognitive bandwidth have become precious and limited commodities that should never be wasted on any unnecessary concern.
I have a rule of thumb in relation to product or project adoption: every installation step cuts adoption in half. If 1000 people find a project and it has a 5 step installation, approximately 32 of them will install it. Make it a 7 step installation and that number is cut down to about 8.
This stands in clear contrast to OpenVPN, which attempts to manage all aspects of the VPN management process from endpoint config (interfaces, routes, etc) to key dissemination (strongly preferring mutual TLS auth and specifying a format for importable VPN configs). As a result, we could say that OpenVPN "Does Everything And Does It Okay," which I'd like to coin as the opposite philosophy. This has advantages if you have some kind of complicated situation and want to keep everything inside of one tool, but the result is that OpenVPN is more complicated to use and configure, and has more surface area to attack.
To some extent this kind of limited scope comes off as opinionated but I would like to view it the opposite way: Wireguard is unopinionated in that it leaves a large portion of the VPN stack for you to handle yourself, either manually or by bringing your own tool. This is a bit annoying if you're looking for a turnkey solution, but also makes Wireguard very simple and easy to understand and audit.
There is indeed such a philosophy:
The main problem I have with highly configurable utils is that a lot of them don't have sane defaults (or any defaults), which might be ok considering most users want-to or enjoy spending hours writing custom config, but it's a big ask for things I want to use quickly, or just try.
So, imo it depends on the software.
Until you run into the limits, of course. If you control both sides, you can use what you want, but as soon as you implement just one side ...
It's normal and expected evolution of protocols and software.
Generation 1: New idea, new implementation. As people become comfortable with the new idea it gains in acceptance and hype. Try to keep it simple and fast, but it's a exercise in exploration and it gains technical debt faster then it gains new features.
Generation 2: Widespread acceptance and commercialization. Groups inside large corporations, and sometimes entire businesses, spring up around the new idea. They re-implement the idea to reduce technical debt and add flexibility. Features are piled on to make it marketable. Eventually becomes heavy and unwieldy.
Generation 3: Hype train dies down and people have learned what really matters and what really should be focused on. Third generation is lean, fast, and 'correct'. It becomes ubiquitous, people stop caring about it and people stop paying for it. It becomes just something that is always there and ends up little more then a building block for the next new idea.
Stage 1: Raw Iron Stage 2: Checklist Battles Stage 3: Productivity Wars Stage 4: Transparency
OpenPGP is an example of a case where relatively extreme backwards compatibility is required as old archived messages have to be accessible. But that isn't a problem because things are such that downgrade attacks are impossible. The list of desired methods is in the public key which is signed with itself. So downgrades are not always an issue.
Note that I am only claiming that downgrade attacks are technically impossible for OpenPGP due to the way that it works. To break the protection against downgrades means that you have to break the root cryptography. That might not be true for other stuff... Makes for a great example though...
We introduce wireguard2, which is not wire-protocol-compatible with original wireguard. The same configuration files can be used, but you must generate new keys as part of your switch over.
We strongly advise you to stop using original wireguard if there is any possibility of a wealthy, organized, determined attacker intercepting your communications. (See CVE2021-x. and forthcoming paper "64 qubits can deduce Curve25519 points" by D.J. Bernstein et al.)
None of this is complicated. It's also worth looking back on the history of TLS vulnerabilities to get a sense of just how little ciphersuite negotiation helped anybody.
or at least you might want different keys anyway
That said, OpenBSD's OpenIKEd is just as simple and efficient, and thanks to standard compliance (IPsec, IKEv2 and MOBIKE) it works out of the box with iOS devices.
It will be interesting to see what happens when (or if) large enterprises and hardware vendors adopt it.
With a security product, however, I can understand the allure of offering few to no options. Laypeople get security wrong at an alarming rate, even with good defaults, so I often don't mind a security product just offering one configuration that the (presumable) security experts who built it have decided is the right way to use it.
Of course, if they turn out to be wrong about something, and a mitigation would be "disable feature X", then this requires a patch and new release, when it might have otherwise just required a configuration change.
For cryptographic (and related) applications, it certainly seems standard engineering advice now to reduce choices and configurations to a minimum [1] (but apparently not 2 decades ago, when OpenSSL, OpenVPN, and GPG were initially released).
[1] pretty sure Bruce Schneider et al. recommended it in their 2010 book Cryptography Engineering.
Opinionated isn't the right phrase here. For something like webdev there are 200 "right" ways to do things. For encryption "throw out all the legacy crap and focus on 1 known strong tech" isn't opinionated...it's common sense.
...if you have the luxury of a fresh start. Which mainline kernel has granted wireguard.
Monoculture...maybe...but I reckon the tons of legacy stuff in openvpn is way more dangerous. Especially because it kind forces mass adoption of weaker cyphers due to compatability BS.
The difference is WireGuard is part of Linux kernel so speed of processing packets is faster than TincVPN.
Still experimenting with WireGuard and manually creating peer to peer mesh.
Next release will have a better daemon, with a more typical setup flow. If you want to test drive it, `tailscale-unstable-bin` is the AUR package for it.
EDIT: Stop supporting parasites repackaging and rebranding open source and selling it while leaving the author who single handedly made this entire thing possible begging for donations on Patreon
What I'm trying to say is that tailscale is doing nothing new or sinister.
I haven't seen any evidence of astroturfing in this case. The user you were accusing above seems entirely legit.
You've posted such accusations to HN several times before. Given how little data we have about each other online, it's easy to connect the dots in a way that jumps to nefarious conclusions about others. If you come here and post those, the odds get pretty high that you're accusing innocent people of bad things. That's not cool, which is one reason the site guidelines ask everyone not to do that. We'd be grateful if you'd stop doing that.
Don't let HN to become another ProductHunt.
From the website cannot see it.
Have you considered Nebula?
The one thing I wish wireguard had was overlapping AllowedIPs with 'ip route via' to distinguish (although this isn't a tinc feature either, unless you run it as an ethernet segment). The same result can be achieved using a separate interface for every peer and 0/0 at each end, but it's a bit unwieldy.
For a globally routed overlay mesh, have a look at https://yggdrasil-network.github.io/
The latest version actually uses the Wireguard TUN library https://yggdrasil-network.github.io/2020/02/21/release-v0-3-...
No it doesn't. There are some CNI plugins that use Wireguard, but it's not standard in any way (like any other network plugin, really).
Kubernetes does not use anything for the service mesh internally - as it does not provide a service mesh.
By this I can only assume you mean some popular CNI provider uses wireguard, but out of the ones I know of (flannel, weave, calico, canal, romana) I don't believe any use wireguard.
Or generally for mesh networks as others mentioned: Slack's Nebula, ZeroTier (wait for v2) or Tailscale.
[1] - https://www.tinc-vpn.org/pipermail/tinc/2017-February/004755...
If you haven’t checked them out yet: worth taking a look!
There might be a reason for this, but still it’s not in the same space as Wireguard.
using google/microsoft account is easier than setting up a user service that is comparable in security and ease of use
https://packages.ubuntu.com/search?keywords=network-manager&...
https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-netw...
I’m thinking of writing something to template out configs for short term keys (and automatically reload) based on an OIDC authentication, but seems inelegant.
Why?
doesn't seem very secure to me.
This is not a knock on Wireguard, I use wireguard and love it. It just has several hoops to jump through before it is ready for widespread adoption. Like NIST approving it to be used instead of IPsec or OpenVPN.
It's true that Fortune 500 companies aren't going to deploy WireGuard. They're constitutionally incapable of deploying security gear that isn't awful, which is why a huge fraction of all VPN deployments through the F500 were backdoored in the 2000s.
NIST is never going to approve WireGuard; it's not even a discussion worth having, nor is it NIST's place to certify which VPNs are or aren't safe to use, nor does NIST have the staff to do anything like that.
That's no reason for startup engineers to make the same mistake. Startups definitely do deploy WireGuard.
but even ignoring all of that, wireguard has significantly better security guarantees. https://www.wireguard.com/formal-verification/ claims that "WireGuard has undergone all sorts of formal verification, covering aspects of the cryptography, protocol, and implementation." with references to several formal proofs of the protocol.
furthermore, wireguard has actually received a CVE: CVE-2019-14899, which was posted here only a few weeks ago. it's not wireguard-specific though, it's a general problem with VPN setup on general-purpose operating systems.
With this exception, WireGuard does not CVEs because it is (for now) still considered pre-release software and not recommended for production use.
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases
> Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software).
CVE is just an identifier for a security vulnerability.
"Common Vulnerabilities and Exposures"
CVE generally covers released software, hardware and (in the process or being added officially) services. It also covers beta software (https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=beta).
The reason Wireguard doesn't have CVEs is nobody has bothered to request them.
For more details on CVE there's a bunch of episodes covering it: https://www.opensourcesecuritypodcast.com/search?q=cve
Another thing people might not realize if they haven't had to deal with lots of different VPN configurations is that most of the "user management" and "2FA" features of legacy VPNs are, as the kids say, janky "AF".
Ultimately, organizations should be tying their VPNs, like everything else, into an IdP of some sort, and most of the "user management" and "MFA" stuff belongs to the IdP, not the VPN. People will clearly get WireGuard integrated into Okta.
Right, but at the moment this integration does not exist.
You'd be best without a username a password, just a code.
It is not, for example, faster than the literally dozens of ASIC implementations of bump in the wire IPsec that scale to line rate n * 100Gbps. It's not even faster than kernel IPsec on architectures which support AES with dedicated instructions. Incidentally, this is the default configuration for Strongswan on supporting hardware.
In fact, the benchmarks published prominently on the WireGuard website (https://www.wireguard.com/performance/) are completely nonsensical and compare the clients under circumstances where neither should be bottlenecked and where it is known the underlying algorithm with AES-NI is considerably faster than chacha20-poly1305. Yet, they find that WireGuard achieves higher throughput (magically exceeding line rate, in fact!) in spite of more header overhead and a slower algorithm. They find WireGuard is lower latency by something like an order of magnitude more than the actual single packet latency for an IPsec compression with AES-NI. When I find the official hard data about a product to be complete bullshit, it raises a lot of red flags for me. Either the authors of this marketing fluff are completely ignorant or completely dishonest, but in neither case does the material motivate interest in the product.
It's extremely debatable that it's more secure than common IPsec implementations. The core IPsec implementation is a very simple state machine which has been under review by virtually everyone with an interest in secure comms for decades. It's very wishful to suggest that some hipster shitware that got puked out a few years ago because Strongswan was too hard is "more secure".
If you're in the position of designing a secure interconnect for something more consequential than a friend accessing your home media server and do not have the luxury of abdicating responsibility for the outcome, the fact that the client is easy to use is perhaps the single lowest bullet point on your list of priorities. Interoperability with existing software and hardware, flexibility to adapt to different customer environments and requirements, maturity and proven performance all rate much more highly. IPsec is and has been the go-to for that, while WireGuard is drenched in hype and bullshit and completely unproven.
As you said: I am not a network admin, so I probably botched something. Which, I guess, is another point for wireguard in my book. It lacks many of the bells and whistles of IPsec, which means less to configure for the average stupid home user (me).
The out of kernel alternative is how OpenVPN has always worked, by creating a TUN/TAP device, which basically creates a pipe<->network device bridge, and a user space process reading/writing from that pipe.
The configs itself are basically just the IP's used, and the peers and keys used to communicate with those peers.
(Running a 70+ node full-mesh vpn)
~2^70 VPN connections?
My wireguard setup actually has n x (n-1) config files/instances (current n=8), as that's the only way to shuffle default-gateways over it. It's a little unwieldy, but still manageable. Whereas I can't imagine doing the same with OpenVPN.
It's more like how iptables/nftables is part of the kernel. You need a recent kernel along with user space tooling. But it will become part of virtually every Linux distribution.
As for "my connection to the internet will be secure" - that's possible, but the main use case right now is "my connection to my vpn/server will be secure".
Additional configuration is required to route all traffic through the wireguard tunnel, and make sure all other traffic is dropped - and to make sure all traffic is dropped, rather than sent in plaintext when the tunnel goes down (a "kill switch").
I'm sure we'll see many tools and scripts that will help automate such setups.
But if you just want a udp routed VPN - you might want to look at zerotier or tinc.
1) By connecting to that server, you get access to private resources as if you were on the same network. Say, access to a printer, a web camera or a file server that aren't exposed to the Internet.
2) You gain access to the Internet through that server, so that your publically visible IP changes. This prevents anyone between you and the server to see the content of your traffic (eg: your isp, the hotel it staff that runs your free wifi). It can also grant you access to resources that are exposed to the internet - but filter access based on IP. Such as a CRM system, or webmail system.
If you are connecting to a VPN server, then, by definition (virtual private network) - your connection should be secure. Wireguard is one way in which that access can be secured - and it's new/modern, simple and widely regarded as following best practices. Alternatives are ipsec via eg strongswan, OpenVPN and a bunch of nasty proprietary solutions constructed out of mixes of libssl and obscure hedge magic.
That argument can be strong when considering that effective security in most projects comes down to whether assurance of security can be discerned effectively within a limited time window. Often very limited.
But I agree, it should really be audited properly before this statement can be made.
In addition, the crypto design (beyond it being opinionated and thus no way to misconfigure into using the "null cipher") is arguably much more secure by design than other systems. For instance, WireGuard eliminates entire classes of vulnerabilities through careful protocol design while also adding fairly neat features (such as being impossible to port scan) -- the author explains this much more eloquently than I can[2].
[1]: https://www.wireguard.com/formal-verification/ [2]: https://www.youtube.com/watch?v=CejbCQ5wS7Q (about 23 minutes in)
Fewer configuration options/smaller codebase mean you have less to screw up while programming, less to read while debugging, and fewer opportunities to get things wrong while deploying.
E.g., IPsec has a “none” cipher!
Part of what makes WireGuard "simple" is that it doesn't support any kind of key management--i.e. PKI. Instead you're expected to copy keys around manually. IKE is the most complex part of the IPSec software stack but in many ways the most important part.
Ironically but entirely predictably, people are using homegrown scripts and proprietary third-party services to replace the missing key management aspect of WireGuard. When these turn out to be insecure, or at least the weakest link in the chain, nobody will ever blame WireGuard, even though it will be a predictable consequence of using WireGuard.
Nice, but it would be nice to know if that is the default or not on Linux as well.
I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME. I really hated the PKI on Linux, especially when trying to revoke old keys than on Wireguard. The fact that clients also differed heavily in what they supported was also very annoying.
It's because OpenBSD uses a much nicer, more declarative configuration file syntax, whereas the options on Linux, like Openswan, use a less expressive key-value syntax. To be fair, AFAIU Openswan supports more IKE extensions, and is an older project with more baggage than OpenIKEd or OpenBSD's ipsecctl configuration compiler front-end for isakmpd. But that only highlights the fact that much of the complexity of IPSec is due to history, not because IPSec is intrinsically too complex to make it useable. The SLoC of IPSec kernel code are comparable to the SLoC for WireGuard kernel code. There are smarter ways to implement IPSec and IKE, especially when you have the benefit of hindsight.
> I don't agree with the claim that IPSec somehow automates PKI, it's still very disgusting compared to things like (LetsEncrypt's) ACME
It doesn't automate CA renewal, but you can't even do any kind of PKI using WireGuard as WireGuard doesn't support key signing or key authorities.
FWIW, OpenBSD provides a utility for generating and manipulating X.509 certificates for use with IKE.[1] I've never used it as I'm unfortunately quite familiar with PKIX infrastructure and have my own tools, but AFAIU it's what most people use.
None of this is to say that, when comparing apples to apples, WireGuard isn't a better protocol than IPSec. But SSH also has warts and it would be trivial to come up with a better replacement protocol. We don't need to because we have OpenSSH, a smart implementation that continually discards as much baggage as it can, while still interoperating with a wider ecosystem of alternative implementations.
The fundamental problem is that 1) key management is hard, 2) key management is critical to overall safety and usability. WireGuard sidesteps all of this. It looks great on paper because it's only solving the easiest problem. And it seems great in practice because the ugliness of the ancillary infrastructure isn't counted against it, even though from a wholistic standpoint it should.
[1] https://man.openbsd.org/ikectl.8#PKI_AND_CERTIFICATE_AUTHORI...
I haven't checked whether this is true, but even if it is, that's a damning indictment of IPsec, because on Linux, the entire connection establishment is in userspace, and the kernel only handles per-packet encryption and authentication. WireGuard has the entire negotiation sequence, authentication, routing, timeouts, rekeying, etc in the kernel. With IPsec, you need to have a userspace daemon to manage all of that, with significantly more LoC than the bare per-packet essentials. With WireGuard, you just load the keys into the kernel and you're done. I bet that you're also counting Zinc against WireGuard, but not counting the entire crypto API against IPsec (which, unlike with WireGuard, you might end up actually using).
I suspect that it's not actually true though in the first place, once you add in all of the other stuff like iptables -m policy that only exists to support IPsec.
Signal isn't an apposite comparison as Signal implements key signing and key exchange with Signal as the sole certificate authority. Who do you think attests to the authenticity of phone numbers, and how do you think they do so? Indeed, Signal exemplifies exactly what I was saying: key management is crucial, key management is hard. Secure, trusted key management is like 90% of Signal's value-add.
At large organizations SSH is often used with signed X.509 certificates. OpenSSH resisted the feature request for years, but the demand was overwhelming. The rise of products like Teleport and ScaleFT are perhaps best characterized as extremely convoluted combination key management and VPN solutions.
You say "complicated PKI", but my point is that WireGuard has no PKI. In any event PKI is intrinsically complicated. Take WireGuard and add the simplest possible trusted authority scheme on top and you've doubled the conceptual complexity by 2-3x, and possibly the SLoC, too.
There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized point of trust that mints time- and usage- limited token-equivalents. They're not trees so much as they are vines or fungus colonies. They're great, but they're certainly not a vindication of the 1990s concept of a PKI.
I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.
> The Web PKI is something we live with because we have to, not something anyone sets out to re-create.
We have to because it's crucial. If public key attestation didn't matter we would have dispensed with the lock icon and "this certificate is untrusted" popups rather than laud the emergence of Let's Encrypt and the ACME protocol.
> I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.
You are meant to verify your contacts' keys (aka "safety numbers") either in-person or otherwise out-of-band. The Signal server does not in any way sign or endorse the identity keys they serve to users (yes, they're delivered over TLS but that doesn't count).
Yes, Signal does do some best-effort verification of your phone number when you register a device but that's just to avoid DoS. SMS can be easily intercepted.
* Those primitives are used for a Noise construction, and Noise is itself reasonably well studied and increasingly formalized; we can be somewhat confident WireGuard is skipping over the 2 generations of protocol vulnerabilities SSL/TLS faced.
* Perhaps most importantly, the codebase is tiny and designed to minimize its attack surface; for instance, the protocol itself is designed to be implementable without dynamic memory allocation.
* WireGuard is itself minimal and doesn't implement higher-level features like user management, which means that those features aren't coupled and entangled into the core engine, and can be implemented straightforwardly through a clear interface.
In general, and contra this article, "smaller codebase" usually does mean "more secure".
Semi-OT: So I just installed PiVPN to use with this protocol to try and do a small vpn at home (all I want is to go to my domain, auth, and be on my LAN so I can RDP / VNC) and the wireguard bits worked great, and the install process was buttery smooth, even on a Raspbery Pi Zero W.
But - my network lack of knowledge is probably hamstringing me. I opened the WG port on my router and confirmed the dns hostname I'm using corresponds to the public IP, but I'm not able to get the wireguard clients to connect. The tcpdump doesn't show any incoming traffic on the port at all.
Should I keep fussing with PiVPN or try something like TincVPN or Tailscale? I have not been able to get a VNC or RDP session going over tailscale even though all my machines are able to connect to the Tailscale network.
I want to use wireguard, everyone says it is so good, and OpenVPN does seem a bit boring, but ultimately I'm just hitting a wall when it comes to the use case of 'auth, you are on your home lan, connect as if you are at home connected to wifi'
But this does give me hope that it can be done in the first place, I just have some setting goofed up somewhere. I will restart my tailscale stuff now that I know someone out there has done it.
Thanks!
(I just did the same setup with PiVPN. Somehow I got a wrong port number first, but then it worked)
I will also double check the port number.
My owned router had the right ports opened, but the AT&T bridged router did not. Be sure you open ports on both sets of routers, otherwise your owned router will never have a chance to allow the traffic in the first place.
Great tool for newbies like me.
QR setup for mobile also available.
A ton of links are conceptually point to point but not encrypted as such because existing means are a pain in the ass
Having a TCP-based option sure would be nice.
Without TCP/IP you're back to running dual wg and ovpn services and pretty much where we are with ip4 vs. 6. One is 'better' but the other works everywhere.
My work does the same kind of thing on the guest SSID, drives me nuts.
https://github.com/wangyu-/udp2raw-tunnel
Added bonus: it's not TCP
So I don't see yout point.
Thanks for the reply.
Also, see: https://lists.zx2c4.com/pipermail/wireguard/2017-September/0...
But of course what he's getting now ($1212) is nowhere near that.
I prefer this model for opensource software. We get an awesome product and he gets enough money to sustain himself while maintaining it. Seems like a fair deal for all.
$ systemd
$ wired> ChaCha20 is a stream cipher which are easier to implement in software. They encrypt one bit at a time. Block ciphers like AES encrypt a block of 128 bits at a time. ..
Wow. I'm avoiding wireguard for other reasons, but there is a lot of FUD in that article.
https://www.perfect-privacy.com/en/blog/wireguard-vpn-pros-a...
When those are not enough any more, they need to segment their VPN, so they can re-use the private IP space in each segment.
w.r.t. to "NeuroRouting and TrackStop not possible", they could route their stuff through a TUN interface to do whatever they want to do in user space. With a performance cost.
> What they probably need to do is to assign each customer a fixed private IP for use within their VPN, e.g. from 10.0.0.0/8.
Actually, they can set a different IP for each session and rotate them by given it to the client out of band, for example when it authenticates to the service.
> When those are not enough any more, they need to segment their VPN
Like with all other VPNs right? They could also distribute IPv6 for the tunnel and this would not be an issue.
Like I said, Wireguard does not have the concept of sessions. You could add your own proprietary "stuff" around Wireguard to add that concept, but then you don't need anything extra from Wireguard. You add the keys of the users as part of the session setup and remove them when the session is destroyed. Of course, this means that clients have to use a client tool provided by you.
- Basically no real user or admin-oriented docs. There's some example configs and some getting started guides, and then some crypto-nerd look-how-secure-our-algorithms-are docs, but no real guidance on how to set up a reasonably simple network of hosts.
- Authentication/authorization is just IP addresses and public keys? What about users and service accounts that you want to rotate the credentials of? What about SSO? What about fine-grained access control? What about <insert all of the enterprise things>?
Big static keys and open-ended authorization by default are really not where we should be going with modern security practices. If I just want a layer 3/4 tunnel with public keys, SSH already does that. Sure, WireGuard is basically "SSH plus some easier routing", but I don't need an iteration on SSH, I need an iteration on OpenVPN, which can actually support most enterprise needs. The SSH (and WireGuard) model doesn't scale, due to a lack of functionality.
In OpenVPN and others, the server can just check the certificate presented by a client against a shared CA. The certificate can be signed/emitted by a totally different system.
It wasn't really in release mode until it was merged to the kernel, so that's pretty understandable. I had no networking knowledge aside from pentesting and I was able to get a tunnel working.
I don't think Wireguard was ever going to be like those other things. It sounds like you should wait for products to be built on top of Wireguard. Judging a fish's ability to climb a tree and all that.
This is a simple example, but much of what you need to do can be done with layers on top. This is similar to iptables, in that you can use `firewalld`, or `UFW` which all use iptables under the hood.
It's also possible to use something other than Vault, you could use LDAP for example, but Vault lets you use multiple authentication mechanisms, and can be used for other purposes, so it's kinda a multi-tool. Additionally, I'm not using consul, just Postgres on the same host as Vault.
The rest of what you're asking for can be implementing on top of WireGuard in external tools and I fully expect will be over the next few years seeing the adoption so far.
And given you mentioned SSH... That's basically what it is, yes, layer 3 forwarding over SSH except done in a way that's actually usable. (For issues, see e.g., http://sites.inka.de/bigred/devel/tcp-tcp.html)
This is a step back towards the unix philosophy of providing simple pieces that can be stacked together to build more complicated things, not a drop-in replacement for OpenVPN et al. Most of us are excited because (1) not everyone is an enterprise, and that "we need everything and the kitchen sink" philosophy makes OpenVPN annoying to work with for everyone else and (2) we'll probably see a lot more options cropping up in this space soon built around WireGuard now that developers have been given a secure primitive to build upon.