Identity management for WireGuard

October 18, 2022

This article was contributed by Jordan Webb

Since its inclusion in the Linux kernel, the WireGuard VPN tunnel has become increasingly popular. In general, WireGuard is simpler to configure than other VPNs, but the approach that it takes to authentication can present some challenges. Each node in a WireGuard network has a cryptographic key that serves as the node's identity; nodes that do not know each other's keys cannot directly communicate. Keeping track of these keys and distributing them to the other nodes in a mesh network quickly becomes a chore as the network grows. Fortunately, there are now several open-source tools that can automate the management of these keys and make using WireGuard easier for both administrators and end users.

Key management can be particularly challenging for non-technical end users, who are used to logging into services with a username and password. Thus, the main feature that all of these tools have in common is that they allow a user to log into a WireGuard network using a username and password (and possibly a second factor, such as a one-time password). This is usually accomplished by integrating with an identity provider that implements the OpenID Connect (OIDC) standard. OIDC is built on top of the OAuth 2.0 protocol and can be used to implement the ubiquitous "Sign in with Some Big Company" functionality seen on many web sites.

Some of the software discussed in this article requires an OIDC provider; there are several open-source options for people who aren't already running their own and don't want to farm the task out to some big company. Keycloak is one of the most mature and popular choices and Authelia is an up-and-coming alternative.

Tailscale

Tailscale is a commercial service that provides managed WireGuard networks. When a network administrator creates a new network on Tailscale, they must choose an identity provider; they can choose to have their users sign in with Google, GitHub, Microsoft, or any other provider that supports OIDC. The approach of connecting key management for WireGuard to an identity provider was pioneered by Tailscale, and likely served as inspiration for the other projects covered in this article.

To connect to a Tailscale network, a user must install Tailscale's client software. The client talks to Tailscale's API and manages WireGuard interfaces on a user's device. When a user connects to a Tailscale network, the client generates a WireGuard key pair, and then submits the public key to Tailscale's API. The user is then directed to Tailscale's web site, which sends them to a login page for the identity provider chosen for the network. After a user is logged in (and after their device is approved, depending on how the administrator has configured the network), their public key is made available to be retrieved by the Tailscale clients running on the other nodes. The other clients add the new key to their WireGuard configurations, allowing them to communicate with the new node.

The Tailscale client is available for Linux, macOS, and Windows, as well as iOS and Android. The source of the command-line version of the Tailscale client (which is written in Go) is released under the 3-clause BSD license, as is the Android client. Unfortunately, the server software is proprietary. That's where Headscale comes in.

Headscale

Headscale is an independent implementation of Tailscale's server-side API; like the Tailscale client, it is written in Go. Tailscale's command-line interface (CLI) client has a --login-server flag that allows users to override the URL to the Tailscale API, which can be used to connect the client to Headscale. Despite Headscale's unofficial status, Tailscale seems to be fully supportive of its efforts; Tailscale has coordinated with Headscale's creator on API changes and hired one of Headscale's maintainers. On Android, changing the API URL was originally accomplished by recompiling the client, but a pull request that adds a hidden menu to Tailscale's official builds of the client was recently merged. Tailscale's Windows and macOS clients can also be used with Headscale, but support for changing the API URL in the iOS client is currently incomplete.

The list of Tailscale features that Headscale doesn't support is surprisingly short. Headscale does not yet support Tailscale's SSH key-management feature. Other than that, users of Headscale can enjoy most of Tailscale's features, including network-level access-control lists (ACLs), DNS for the VPN, and use Tailscale's NAT-traversal mechanism.

Headscale doesn't include a web-based administrative interface (although a third-party interface is available); it is configured using a YAML file. Headscale can be used with an OIDC provider, but it also supports using an internal database of usernames and passwords; this could be convenient for small setups or home labs that don't already have an identity provider set up. Unlike Tailscale's backend, the Headscale server doesn't support multi-tenancy; each instance of Headscale can only play host to a single network.

Though it has close ties to the Tailscale proprietary service, Headscale does enable creating a completely self-hosted WireGuard VPN using only open-source software. The project's friendly relationship with Tailscale bodes well for Headscale's continued usefulness. Unless Tailscale's management has a sudden change of heart, it is unlikely that Tailscale will make changes to its clients that make them incompatible with Headscale, at least without coordinating with the project.

NetBird

NetBird is another commercial service that provides managed WireGuard networks. The architecture of NetBird is similar to that of Tailscale. A client application (the NetBird agent) generates keys for a node and submits the public key to a management service. The user is directed to an identity provider to log in; after the user is logged in and their device is authenticated, their public key is distributed to the other clients in the network, which add the key to their WireGuard configurations. NetBird doesn't seem to have a built-in user database, and requires the use of an OIDC provider; people that don't already have one running will have to install and configure one before trying it.

Unlike Tailscale, NetBird is fully open-source; the sources to both the client and the server-side components are BSD-licensed and available on GitHub, although one needs to agree to a Contributor License Agreement (CLA) before contributing. Agreeing to the CLA grants NetBird the right to relicense contributions in any way that it might choose; it also contains some additional language about patent rights. There are also instructions for hosting your own NetBird server.

The NetBird server consists of the management API service and a signaling server to help clients find each other. A dashboard is also included; unlike Headscale, the same web interface is available to both users of the NetBird service and those who are self-hosting NetBird. Beyond that, NetBird also needs a 3rd-party STUN/TURN server to assist with NAT traversal. Instead of inventing a new protocol like Tailscale did, NetBird's NAT-traversal functionality is based on the WebRTC standard.

NetBird offers many features similar to those offered by Tailscale. Like Tailscale, NetBird supports network-level ACLs, and it also has an SSH key-management feature. NetBird doesn't currently have all of the DNS functionality that Tailscale does, and its client is currently only available for desktop platforms. Mobile clients and private DNS for the VPN are both listed as "coming soon" in the project's README, though.

It's not quite at parity with all of Tailscale's features, but NetBird largely replicates the core functionality of Tailscale's product, without any proprietary software. It has yet to achieve the same level of popularity as Tailscale or to build the kind of community that Headscale has, though; its core contributors are all NetBird employees. Compared to Tailscale, more of NetBird's software is open source, but the fate of that software is likely to be tied to that of NetBird's business endeavors.

Firezone

Firezone is a another company that aims to provide managed WireGuard networks, although its hosted offering doesn't appear to have actually launched yet; the pricing page is scant on details and the documentation features a "Join the Beta" link at the top of the page.

Firezone is written in Elixir. Its source code is available now under an Apache 2.0 license; contributions do not appear to require a CLA. Instructions for self-hosting Firezone are provided in the documentation. Like Headscale, Firezone can authenticate users using an OIDC provider or a built-in user database.

Firezone does not (yet?) provide any sort of client software. Instead, users generate WireGuard keys for themselves, and then upload them to Firezone's web interface. Users can then download a configuration for the standard WireGuard client from the web interface. Firezone allows filtering traffic between nodes but doesn't include any additional features like DNS or SSH key-management. No NAT-traversal methods are mentioned in the documentation; without assistance from NAT traversal, WireGuard nodes that are behind NAT may have trouble connecting to the VPN depending on the network configuration.

It's hard to tell if Firezone is intentionally minimal, or if it's still just early in its development; there is no public roadmap that I could find. The project's commit history starts a little over a year ago, and the vast majority of the commits are attributed to the company's founder. In its current state, it could be appealing to someone who is already comfortable managing their own WireGuard networks and is just looking for integration with an OIDC provider.

Netmaker

Netmaker is yet another provider of managed WireGuard networks. Like Tailscale, Headscale, and NetBird, Netmaker's software is written in Go. The source is available under the Server Side Public License (SSPL). Instructions for self-hosting Netmaker are available, but the license implies that the creators of Netmaker would prefer that you not attempt to make a business of it.

The SSPL is similar to the GNU Affero GPL license in that it requires source code to be made available to any user who interacts with a service over the network, but contains additional language that requires the source of any components that are used to manage the service to be released under the SSPL as well. The SSPL is designed to protect the business interests of companies that release software under it. The additional restrictions that it imposes make it legally unpalatable for other companies to offer the software as a service; according to the Open Source Initiative, it is not an open-source license. Like NetBird, Netmaker also requires contributors to agree to a CLA, which grants patent rights and allows Netmaker to relicense the contribution.

Based on the release notes for the earliest versions of Netmaker, it doesn't look like the authors set out with the intention of building a competitor to Tailscale. Instead, it was originally built for use with Kubernetes, and this use case is still supported. Netmaker uses WireGuard to enable building Kubernetes clusters that span multiple data centers and to securely connect clusters to external services and clients.

More recent versions of Netmaker have become more like Tailscale. Originally, Netmaker's client software authenticated to the API using a pre-shared key; this makes sense for automatically-deployed virtual machines and cloud instances but isn't suitable for end users. Netmaker still supports this method of authentication, but more recent versions also support logging in with a username and password, using either a built-in user database or via an OIDC provider. Netmaker also supports access-control lists; earlier versions included a DNS server, but more recent versions have switched to adding VPN hostnames to /etc/hosts instead. Like Firezone, no NAT-traversal methods are mentioned in the documentation.

Netmaker appears to have attracted more community contributions than NetBird or Firezone, but its development is still primarily employee-driven. Its origin in the world of Kubernetes is still readily apparent; prospective users can choose from multiple deployment options and the advanced server installation guide presents a vast array of ways in which an installation of Netmaker can be customized. Netmaker's client software runs on Linux, macOS, and Windows, as well as FreeBSD, but it only offers a command-line interface at the moment. Networking experts and people who are already running their own Kubernetes clusters will likely be happy and comfortable with Netmaker, but people looking for a VPN that is easy for non-technical users might want to look elsewhere.

Conclusion

For someone who wants to build a self-hosted WireGuard VPN for possibly non-technical end users, Headscale (in combination with Tailscale's client software) is the most complete solution, and the only solution if being able to connect mobile phones to the network is a requirement. If relying on Tailscale's clients is a non-starter, NetBird provides a similar experience to users, but NetBird doesn't have mobile clients yet. Firezone looks to be off to a promising start, but it still has a lot of catching up to do relative to Headscale and NetBird; its complete lack of client software still puts a lot of the work of managing WireGuard configurations on the user. Meanwhile, Netmaker's end-user experience is unpolished, but its other use cases might make it interesting to people managing Kubernetes clusters or other large deployments of virtual machines.

Despite its close association with Tailscale and dependence on its clients, Headscale is the only truly community-driven project of the bunch. All of the other solutions are open source (or, depending on how you feel about the SSPL, source available), but they are all built by venture-backed companies. Given the relative lack of community contributions, these projects may not have much of a future if the companies associated with them are unable to find their way to commercial success.

Index entries for this article
GuestArticles	Webb, Jordan

to post comments

Identity management for WireGuard

Posted Oct 18, 2022 16:25 UTC (Tue) by q_q_p_p (guest, #131113) [Link] (43 responses)

Why simple things can't stay simple? If corporations want identity management they should use OpenVPN. It's stupidly complex so it should be perfect for them.

Identity management for WireGuard

Posted Oct 18, 2022 17:05 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (33 responses)

> Why simple things can't stay simple? If corporations want identity management they should use OpenVPN.

OpenVPN sucks for many, many reasons.

Identity management for WireGuard

Posted Oct 18, 2022 17:11 UTC (Tue) by q_q_p_p (guest, #131113) [Link] (2 responses)

>OpenVPN sucks for many, many reasons.

Yeah, so it's perfect for them - they can keep their engineers busy by making openvpn suck more and leave wireguard alone.

Identity management for WireGuard

Posted Oct 18, 2022 17:32 UTC (Tue) by pallas (guest, #128204) [Link]

Why the gatekeeping for who can and can’t use or write tooling for an intentionally open protocol?

Identity management for WireGuard

Posted Oct 19, 2022 14:57 UTC (Wed) by patrakov (subscriber, #97174) [Link]

No, even in this respect, OpenVPN is not perfect. You forgot about IPSEC.

Identity management for WireGuard

Posted Oct 18, 2022 19:52 UTC (Tue) by intelfx (subscriber, #130118) [Link] (27 responses)

What reasons, besides performance?

Identity management for WireGuard

Posted Oct 18, 2022 19:58 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

OpenVPN support for IPv6 is kinda buggy from my experience. But the main problem is the TCP mode of OpenVPN, it suffers from all the usual head-of-the-line blocking issues.

For the UDP mode, you have to be careful of MTU issues.

Then there's the usual configuration hell with OpenVPN.

Identity management for WireGuard

Posted Oct 18, 2022 20:04 UTC (Tue) by dskoll (subscriber, #1630) [Link] (10 responses)

Yes, you definitely should avoid TCP mode for OpenVPN. But I'm curious about your Then there's the usual configuration hell with OpenVPN. sentence. I find OpenVPN pretty easy to configure. I generate certificates for each client and drop their respective configs in the ccd/ directory and that's it. Very easy.

Identity management for WireGuard

Posted Oct 18, 2022 20:38 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (9 responses)

You have to run your own CA to work with OpenVPN, which is quite a bit of work. Especially if you want proper CRLs and everything. There's also no way to NOT use certs, if you want to set it up on a mobile device.

Identity management for WireGuard

Posted Oct 18, 2022 20:43 UTC (Tue) by dskoll (subscriber, #1630) [Link] (1 responses)

In principle, you could use LetsEncrypt certs, but that would require a lot of work and resolvable hostnames for all the clients, so yes... in practice you need to run your own CA. It took me a few hours to set up the scripts, and now I have a script that just spits out keys and certificates as I require them.

I also use certs on my mobile devices. It's not hard to import a cert into the Android OpenVPN client. (In fact, my script puts it inline in the .ovpn config file.)

Identity management for WireGuard

Posted Oct 18, 2022 20:44 UTC (Tue) by dskoll (subscriber, #1630) [Link]

Also, you can effectively revoke a client certificate by deleting it from the ccd directory. Just don't reuse that CN (call the new client vpn-2.client.example.com or something instead.)

Identity management for WireGuard

Posted Oct 18, 2022 22:12 UTC (Tue) by dankamongmen (subscriber, #35141) [Link] (1 responses)

? untrue, there's a simple PSK mode using "static keys"

Identity management for WireGuard

Posted Oct 18, 2022 22:14 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

The last time I checked it, it worked with exactly one key. No per-client keys or anything.

Identity management for WireGuard

Posted Oct 19, 2022 12:48 UTC (Wed) by GhePeU (subscriber, #56133) [Link] (2 responses)

There are ways to avoid certificates even on mobile clients.

If you're already using an LDAP server (AD included) you can configure the LDAP plugin that's available on most if not all distros, or you can use the "auth-user-pass-verify" option to execute an external program, passing to it the username and password via environment variables or a temporary file and having it return 0 if the user is authorized and 1 if he's not.

In both cases you still need to distribute the CA certificate, but that can be done easily enough by including it in an .ovpn profile (inside a <ca> tag) that you would use it anyway to tell the mobile client to authenticate with username and password ("auth-user-pass" option) and not to require a client certificate ("client-cert-not-required" option).

Identity management for WireGuard

Posted Oct 19, 2022 19:35 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> If you're already using an LDAP server (AD included)

On a mobile device?

Identity management for WireGuard

Posted Oct 20, 2022 9:39 UTC (Thu) by GhePeU (subscriber, #56133) [Link]

I don't follow, did you mean you want to set up an OpenVPN *server* on a mobile device?

I thought you meant you wanted username/password authentication on the mobile *clients*, if that's the case both the Android and the iOS clients support it, you only need to include the options I mentioned in the .ovpn profile.

Identity management for WireGuard

Posted Oct 20, 2022 14:22 UTC (Thu) by auxsvr (guest, #120007) [Link] (1 responses)

You have to run your own CA to work with OpenVPN, which is quite a bit of work.

easyrsa makes this easy.

Identity management for WireGuard

Posted Oct 20, 2022 15:36 UTC (Thu) by jhoblitt (subscriber, #77733) [Link]

FreeIPA has a built in CA.

Identity management for WireGuard

Posted Oct 18, 2022 20:54 UTC (Tue) by brunowolff (guest, #71160) [Link] (14 responses)

I looked at it a while back and it seems to not be OK in the default setup if the server and the client are not in the same trust domain. Some scripts generated by the server are used to control routing on the client. That in itself is problematic. I remember looking at how it worked and it looked like the server could run arbitrary commands as root. I might have missed something there.
It is possible to ignore commands from the server and manually set up the routing needed to make things work.

Identity management for WireGuard

Posted Oct 18, 2022 21:04 UTC (Tue) by dskoll (subscriber, #1630) [Link] (13 responses)

I think earlier versions of OpenVPN may have executed shell commands to set up routing, but I'm pretty sure current releases update the routing table directly via netlink.

Identity management for WireGuard

Posted Oct 19, 2022 1:16 UTC (Wed) by riking (subscriber, #95706) [Link] (2 responses)

This implies that servers can still do that by simply pretending to be an older version :(

Identity management for WireGuard

Posted Oct 19, 2022 1:35 UTC (Wed) by intelfx (subscriber, #130118) [Link]

> This implies that servers can still do that by simply pretending to be an older version :(

Why? The protocol didn't change, the client implementation did.

The ability to execute arbitrary programs is a completely separate concept, (1) which is disabled by default and (2) servers are disallowed from pushing any options that control execution of external programs anyway.

Identity management for WireGuard

Posted Oct 19, 2022 12:59 UTC (Wed) by dskoll (subscriber, #1630) [Link]

No; this is controlled by the client, not the server.

Identity management for WireGuard

Posted Oct 19, 2022 4:09 UTC (Wed) by donald.buczek (subscriber, #112892) [Link] (9 responses)

This is exactly why I rejected OpenVPN when I Iooked at it (long ago) and get angry when our users want to install openVPN just to access some Intranet site of another organization. I don't want third party servers to configure the network of our clients. There is a reason, we have a Firewall router.

We have that scenario often because of a cooperation. For Linux, luckily, we've created a wrapper which runs a Firefox browser in its own network namespace, so the remote OpenVPN server can configure that namespace however it likes. It doesn't have access to our protected networks.

https://github.molgen.mpg.de/mariux64/mxtools/tree/master...

Identity management for WireGuard

Posted Oct 19, 2022 4:22 UTC (Wed) by donald.buczek (subscriber, #112892) [Link] (3 responses)

Oh, and for our own "Access internal site" or more often "Access IP-Address protected subscribed online journals", we do have VPN (SoftEtherVPN) which works with the native clients on all operating systems. So we don't ask users to trust and install any software, just configure their native clients.

But we very much prefer to teach people to use ssh with a socks tunnel and configure their browsers to use it instead. People just keep asking vor VPN because they think they need it and we talk them into ssh.

And *if* they configure VPN, they may be dissapointed to learn, that the client terminates in a guest network with very little more access rights than any other system from the big bad Internet. Of course, no access to networks shares.

Identity management for WireGuard

Posted Oct 19, 2022 4:55 UTC (Wed) by intelfx (subscriber, #130118) [Link] (2 responses)

> But we very much prefer to teach people to use ssh with a socks tunnel and configure their browsers to use it instead. People just keep asking vor VPN because they think they need it and we talk them into ssh.

Well, I would very much prefer *not* to use ssh -D, exactly for the reasons discussed above which are inherent to any TCP-over-TCP tunneling solution.

It does work okay-ish for one-off management & rescue tasks, but for anything remotely serious? I'd like my OpenVPN, complete with all the routing automation and split DNS forwarding, thank you very much, and please leave the security theater at the door.

Identity management for WireGuard

Posted Oct 19, 2022 14:30 UTC (Wed) by patrakov (subscriber, #97174) [Link]

SSH SOCKS tunneling is not a TCP-over-TCP tunneling solution. It works on byte streams, not TCP packets. TCP connections are terminated by the SSH server.

Identity management for WireGuard

Posted Oct 20, 2022 5:34 UTC (Thu) by donald.buczek (subscriber, #112892) [Link]

> Well, I would very much prefer *not* to use ssh -D, exactly for the reasons discussed above which are inherent to any TCP-over-TCP tunneling solution.

I can just say, that I work like that all day (even with an additional ProxyJump) when in home office and I don't notice any difference in my browser when I go to public sites whether socks proxy is on or not.

Identity management for WireGuard

Posted Oct 19, 2022 4:52 UTC (Wed) by intelfx (subscriber, #130118) [Link]

I'm sorry for your users... this just reeks security theater.

Identity management for WireGuard

Posted Oct 19, 2022 10:13 UTC (Wed) by bof (subscriber, #110741) [Link] (3 responses)

If you are concerned about that, just don't put the statements into the openVPN client config that permit the remote server config info to be acted upon (--pull). It is not on by default. There is also --pull-filter, giving you flexible control to express what server pushed info to accept, or not.

I run a few of my clients exactly that way, instead of believing the server, running a local "up" script to configure stuff my way.

Identity management for WireGuard

Posted Oct 19, 2022 11:47 UTC (Wed) by donald.buczek (subscriber, #112892) [Link] (2 responses)

Yes, but the users get the config from the other organization.

I also should mention, that the (client) systems, I am talking about, are multi-user systems. Neither have the users root nor do you want to tunnel the traffic of all users over the vpn, one user activated with his credentials. That is another reason, the openVPN client has to run in a network/user namespace.

Identity management for WireGuard

Posted Oct 19, 2022 13:22 UTC (Wed) by mbunkus (subscriber, #87248) [Link] (1 responses)

Yeah, so? If they care about these things they can easily edit the config after receiving it, removing "pull", adding the "route"s they actually do need and be done with it.

And if they don't have root, as you said, it should be easy enough for your admins to prevent them from importing arbitrary OpenVPN configs. That way they have to go through your admins, and they can vet & modify the OpenVPN config.

I don't see what you're arguing for, exactly.

Identity management for WireGuard

Posted Oct 20, 2022 5:55 UTC (Thu) by donald.buczek (subscriber, #112892) [Link]

> I don't see what you're arguing for, exactly.

So please let me try again: The solution you proposed (manually modify client config) is valid in view of what has been said before. However, it wouldn't fit our environment, because we have an additional constraint, which I didn't mention before: The vpn client machines are multiuser machines and it is, of course, not wanted, that the traffic of one user goes over the vpn connection of another user.

This is why your suggestion wouldn't work for us and why we need to run the specific applications of the specific user, which requires the vpn connection, in its own network namespace anyway. The security considerations are resolved along that way.

Identity management for WireGuard

Posted Oct 19, 2022 14:36 UTC (Wed) by zoobab (guest, #9945) [Link] (1 responses)

OpenVPN sucks because context switching between user and kernel space. Wireguard has a kernel module to do this. And OpenVPN thereby consume too much CPU.

Identity management for WireGuard

Posted Oct 19, 2022 16:44 UTC (Wed) by atnot (guest, #124910) [Link]

OpenVPN does have an out of tree kernel module to do this: https://github.com/OpenVPN/ovpn-dco

However I think the complexity of the protocol makes it somewhat unlikely for this to land upstream any time soon when alternatives already exist.

Identity management for WireGuard

Posted Oct 18, 2022 17:36 UTC (Tue) by gspr (subscriber, #91542) [Link]

I was under the impression that one of the beautiful sides of WG is that it can remain simple even if third party providers add things like various incarnations of identity management. WG remains unconcerned with those things, and remains simple. The added layers of complexity can be combined in various ways for added functionality not provided by WG itself, or not be used at all.

Identity management for WireGuard

Posted Oct 18, 2022 19:55 UTC (Tue) by intelfx (subscriber, #130118) [Link]

WG is on the strictly opposite side of the spectrum — it’s so stupidly simple that the emphasis ends up on “stupidly”.

As far as I’m concerned, free software tooling that makes WG more powerful is, on the opposite, quite welcome.

Identity management for WireGuard

Posted Oct 19, 2022 0:03 UTC (Wed) by atnot (guest, #124910) [Link] (2 responses)

The reason ovpn is so complex is because it made the very early fundamental mistake of mixing the data plane (transmission of packets) with the control plane (auth, configuration, routing). They are all just different packet types over a single connection. This means that building on top of ovpn means inevitably having to extend and hence complicate the protocol and clients with your use case.

Wireguard did this correctly by exclusively providing the data plane (although the project does provide a simple control plane in the form of wg-quick and the wg cli). People building more complex control planes for their use cases does not affect the protocol. It is the design working as intended.

Identity management for WireGuard

Posted Oct 19, 2022 1:26 UTC (Wed) by wahern (subscriber, #37304) [Link] (1 responses)

At some point someone will realize everybody is just reinventing the wheel, and add WireGuard support to IKE. Then all will be right with the world.
On balance WireGuard is clearly a better transport than IPSec, at least for tunneled VPNs. But IKE is much more mature and proven. IKE is complex, but unlike transport, key management has always been the most irreducibly complex part of the equation, especially without the ability to leverage WebPKI's centralized trust anchors.

Using OpenIKED, in just a few lines I can configure the server-side of a VPN which works trivially with the native IKE clients on Windows, macOS, Android, and iPhone. All these ad hoc WireGuard solutions will never get to that point, at least not without a formal standard.

Identity management for WireGuard

Posted Oct 19, 2022 14:51 UTC (Wed) by terom (guest, #55278) [Link]

> At some point someone will realize everybody is just reinventing the wheel, and add WireGuard support to IKE. Then all will be right with the world.

Some people just like to watch the world burn...

Identity management for WireGuard

Posted Oct 19, 2022 8:21 UTC (Wed) by scientes (guest, #83068) [Link] (2 responses)

> OpenVPN. It's stupidly complex so it should be perfect for them.

Why is everyone so in love with the darkness that they miss the sarcasm?

OpenSSH is the other system. Are WireGuard 256-bit keys compatible with OpenSSH ed25519 keys?

Identity management for WireGuard

Posted Oct 20, 2022 1:01 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (1 responses)

What does "compatible" mean in this context?

You should not use private or secret keys from one system with another system unless both systems have analysed this specific use case and told you it is fine.

This is even - perhaps surprisingly - true when one tool you use can involve two different cryptographic systems. Early SSL and TLS versions with RSA kex, and a modern TLS 1.3 service with RSA signatures as proof of control, are doing different things with that RSA private key, they try quite hard to have your issuer and other elements scream if you try to use the same key, but they can't stop you and I'd guess a non-trivial fraction of people do so. A serious attacker can use the old server as an oracle to attack the new server.

Identity management for WireGuard

Posted Oct 21, 2022 22:00 UTC (Fri) by wahern (subscriber, #37304) [Link]

> What does "compatible" mean in this context?

A very strict, narrow answer to the question is: maybe. WireGuard doesn't use EC signatures, e.g. EdDSA or ECDSA. WireGuard packets aren't signed, they're simply encrypted (using a ECDH key exchange scheme), and authenticated by the fact that they decrypt to something sensible. Unlike with ECDSA and standard NIST curve ECDH, which use the same public and private components, Curve25519 schemes don't use the same key for signing as they do for key exchange. An Ed25519 signature key is different from an X25519 key exchange key, including in their public key components. (X25519 is what WireGuard uses, IIRC).

You *can* convert an Ed25519 key to an X25519 key. And you can sort of convert X25519 key back to an Ed25519 key, except there are two possible variants so you need to specify how to deterministically pick one. But because the public key components aren't the same, there's not much value in attempting this, even when ignoring the many reasons why even considering sharing keys this way this is problematic.

Traditionally, using an EC private keys for both key exchange and signatures was frowned upon as early EC schemes were exploitable this way. But I believe Curve25519 schemes like EdDSA and related key exchange schemes are inherently robust to such exploits. That doesn't make doing it any more sensible, though.

Identity management for WireGuard

Posted Oct 19, 2022 14:23 UTC (Wed) by jafo (guest, #8892) [Link]

The nice thing about WireGuard is that none of these systems interfere with WireGuard's simplicity. WireGuard stays WireGuard and keeps its simplicity, but if you need enhanced capabilities these options can provide most or all of the WireGuard benefits with enhancements.

Identity management for WireGuard

Posted Oct 18, 2022 17:54 UTC (Tue) by IanKelling (subscriber, #89418) [Link]

> but contains additional language that requires the source of any components that are used to manage the service to be released under the SSPL as well.

That isn't right. The license says "all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available." So, none of that could use an incompatible license, eg: anything copyleft. It is easy to argue that the kernel on up are "programs used to make the program available as a service," so you would need to find an entirely permissively licensed OS. The instructions for self-hosting this program start with "apt install wireguard", that is a GPL wireguard implementation, clearly not allowed. The idea that compliance is possible is a misleading distraction of what is better just called a noncommercial license (which may grow more noncommercial for future versions due to the cla). Anyone can write a proprietary license specific to their business model then tack on: "for things we haven't mentioned here, see the AGPL." That is the SSPL, and it is a disservice to free software to describe it in a form like: "AGPL, except...". The SSPL website does basically that and other misleading things, so it is easy to get this wrong.

Identity management for WireGuard

Posted Oct 18, 2022 21:09 UTC (Tue) by amarao (guest, #87073) [Link] (1 responses)

There is also opensouce innernet, aiming at small scale tailscale replacement. It's not without quircks, but has an amazing AAA idea: wg connection to auth server is the proof of identity. Also, by assuming people are 'ip addresses' and putting them into cidrs instead of 'groups' it make access control hierarchical and naturally following routing/ACL rules with masks, etc.

Identity management for WireGuard

Posted Oct 19, 2022 14:33 UTC (Wed) by patrakov (subscriber, #97174) [Link]

This amazing AAA idea will blacklist the project in any company that has a security certification that demands SSO. And SSO is demanded for a very simple reason: exactly one place to press the Delete button when an employee is fired.

Identity management for WireGuard

Posted Oct 19, 2022 6:06 UTC (Wed) by leromarinvit (subscriber, #56850) [Link] (2 responses)

If only we could just invent a protocol to exchange keys over the Internet. We might call it, I dunno, Internet Key Exchange?

*ducks*

Identity management for WireGuard

Posted Oct 19, 2022 10:43 UTC (Wed) by grawity (subscriber, #80596) [Link] (1 responses)

IMO, the big problem with IKE/ESP isn't that it's complex, necessarily (IKEv2 is quite ok), but that its main implementations rely heavily on the kernel's "transform" framework instead of providing a route-based interface (like tun0 or wg0) and that makes everything look so much more complex.

Xfrm makes a lot of sense for *transport* IPsec associations, where no virtual IPs are involved, but instead the traffic between hosts' real IPs gets ~magically~ transformed into encrypted packets (or has an AH header stuck onto it). For example, between a bunch of servers spread around the net.

But once you start building tunnels through xfrm API, things get really weird. You have to assign virtual IPs to the physical eth0, move them as the default gateway changes, etc. IPsec VPN clients like StrongSwan really ought to default to creating an ipsec0 interface for that (which it *can* do now, using xfrmi interfaces).

Identity management for WireGuard

Posted Oct 19, 2022 15:29 UTC (Wed) by patrakov (subscriber, #97174) [Link]

Even with the xfrm interfaces (what they call a route-based VPN), there is a gotcha. Let's say that there is a firewall that applies packet marks, and a complex routing setup that uses these firewall marks for routing decisions.

Let's talk about an incoming packet on port 4500/udp. It traverses through the firewall, and gets its packet mark applied. Then the kernel decrypts it. The resulting packet traverses again through the firewall, but it inherits the mark of the original IPSEC packet.

Some firewall rulesets for policy routing (e.g. mwan3) clearly do not expect this, because "non-zero packet mark in the PREROUTING chain on the mangle table at the very beginning" just cannot happen with classical non-VPN interfaces or with userspace solutions like OpenVPN. Already reported as a bug in mwan3, see https://github.com/openwrt/packages/issues/19607.

Identity management for WireGuard

Posted Oct 19, 2022 19:59 UTC (Wed) by afeiszli (guest, #161699) [Link] (1 responses)

Hey there, Netmaker author here. Thanks for the article, this is a really great comparison that lays out a lot of pros/cons of the available options.

I just wanted to point out a couple of small things worth correcting from the Netmaker section (can't speak for the other platforms):

1. We do have a client GUI - It's not enabled on Linux by default since most users prefer CLI, but there is one available, and is installed by default on Mac/Windows.

2. We do NAT traversal via our own UDP Hole Punching method (it is very lightly mentioned here https://docs.netmaker.org/architecture.html#netmaker-server, though we should definitely expand on it).

There's definitely a lot more we can be doing, and we're working on getting those things done. Hopefully you can do an update article in 6 months or so and see where we've gone from here!

Identity management for WireGuard

Posted Oct 27, 2022 12:50 UTC (Thu) by mrugiero (guest, #153040) [Link]

> 1. We do have a client GUI - It's not enabled on Linux by default since most users prefer CLI, but there is one available, and is installed by default on Mac/Windows.

I suggest you do enable it. Maybe early adopters do prefer the CLI (we always do), but as your software gets more popular you'll definitely have many GUI-loving users running Linux :)

unetd wireguard + dht

Posted Oct 19, 2022 20:30 UTC (Wed) by mtaht (guest, #11087) [Link]

Over in openwrt-land, there's a similar approach to all this that can also leverage a DHT. It's also available for regular linux...

https://forum.openwrt.org/t/new-wireguard-based-openwrt-v...

Identity management for WireGuard

Posted Oct 21, 2022 4:20 UTC (Fri) by nickodell (subscriber, #125165) [Link]

>Tailscale's Windows and macOS clients can also be used with Headscale, but support for changing the API URL in the iOS client is currently incomplete.

The macOS client, at least, does not seem to support using a custom server. There doesn't seem to be an option for it. It insists on using a tailscale.com account. A comment on HN says that there is an setting to do this in an undocumented menu that can be accessed by holding down the Option key, but I'm unable to find it.