Identity management for WireGuard
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 |
Posted Oct 18, 2022 16:25 UTC (Tue)
by q_q_p_p (guest, #131113)
[Link] (43 responses)
Posted Oct 18, 2022 17:05 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (33 responses)
OpenVPN sucks for many, many reasons.
Posted Oct 18, 2022 17:11 UTC (Tue)
by q_q_p_p (guest, #131113)
[Link] (2 responses)
Yeah, so it's perfect for them - they can keep their engineers busy by making openvpn suck more and leave wireguard alone.
Posted Oct 18, 2022 17:32 UTC (Tue)
by pallas (guest, #128204)
[Link]
Posted Oct 19, 2022 14:57 UTC (Wed)
by patrakov (subscriber, #97174)
[Link]
Posted Oct 18, 2022 19:52 UTC (Tue)
by intelfx (subscriber, #130118)
[Link] (27 responses)
Posted Oct 18, 2022 19:58 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
For the UDP mode, you have to be careful of MTU issues.
Then there's the usual configuration hell with OpenVPN.
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.
Posted Oct 18, 2022 20:38 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (9 responses)
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.)
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.)
Posted Oct 18, 2022 22:12 UTC (Tue)
by dankamongmen (subscriber, #35141)
[Link] (1 responses)
Posted Oct 18, 2022 22:14 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Oct 19, 2022 12:48 UTC (Wed)
by GhePeU (subscriber, #56133)
[Link] (2 responses)
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).
Posted Oct 19, 2022 19:35 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
On a mobile device?
Posted Oct 20, 2022 9:39 UTC (Thu)
by GhePeU (subscriber, #56133)
[Link]
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.
Posted Oct 20, 2022 14:22 UTC (Thu)
by auxsvr (guest, #120007)
[Link] (1 responses)
Posted Oct 20, 2022 15:36 UTC (Thu)
by jhoblitt (subscriber, #77733)
[Link]
Posted Oct 18, 2022 20:54 UTC (Tue)
by brunowolff (guest, #71160)
[Link] (14 responses)
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.
Posted Oct 19, 2022 1:16 UTC (Wed)
by riking (guest, #95706)
[Link] (2 responses)
Posted Oct 19, 2022 1:35 UTC (Wed)
by intelfx (subscriber, #130118)
[Link]
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.
Posted Oct 19, 2022 12:59 UTC (Wed)
by dskoll (subscriber, #1630)
[Link]
No; this is controlled by the client, not the server.
Posted Oct 19, 2022 4:09 UTC (Wed)
by donald.buczek (subscriber, #112892)
[Link] (9 responses)
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...
Posted Oct 19, 2022 4:22 UTC (Wed)
by donald.buczek (subscriber, #112892)
[Link] (3 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.
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.
Posted Oct 19, 2022 4:55 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (2 responses)
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.
Posted Oct 19, 2022 14:30 UTC (Wed)
by patrakov (subscriber, #97174)
[Link]
Posted Oct 20, 2022 5:34 UTC (Thu)
by donald.buczek (subscriber, #112892)
[Link]
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.
Posted Oct 19, 2022 4:52 UTC (Wed)
by intelfx (subscriber, #130118)
[Link]
Posted Oct 19, 2022 10:13 UTC (Wed)
by bof (subscriber, #110741)
[Link] (3 responses)
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.
Posted Oct 19, 2022 11:47 UTC (Wed)
by donald.buczek (subscriber, #112892)
[Link] (2 responses)
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.
Posted Oct 19, 2022 13:22 UTC (Wed)
by mbunkus (subscriber, #87248)
[Link] (1 responses)
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.
Posted Oct 20, 2022 5:55 UTC (Thu)
by donald.buczek (subscriber, #112892)
[Link]
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.
Posted Oct 19, 2022 14:36 UTC (Wed)
by zoobab (guest, #9945)
[Link] (1 responses)
Posted Oct 19, 2022 16:44 UTC (Wed)
by atnot (subscriber, #124910)
[Link]
However I think the complexity of the protocol makes it somewhat unlikely for this to land upstream any time soon when alternatives already exist.
Posted Oct 18, 2022 17:36 UTC (Tue)
by gspr (guest, #91542)
[Link]
Posted Oct 18, 2022 19:55 UTC (Tue)
by intelfx (subscriber, #130118)
[Link]
As far as I’m concerned, free software tooling that makes WG more powerful is, on the opposite, quite welcome.
Posted Oct 19, 2022 0:03 UTC (Wed)
by atnot (subscriber, #124910)
[Link] (2 responses)
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.
Posted Oct 19, 2022 1:26 UTC (Wed)
by wahern (guest, #37304)
[Link] (1 responses)
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.
Posted Oct 19, 2022 14:51 UTC (Wed)
by terom (guest, #55278)
[Link]
Some people just like to watch the world burn...
Posted Oct 19, 2022 8:21 UTC (Wed)
by scientes (guest, #83068)
[Link] (2 responses)
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?
Posted Oct 20, 2022 1:01 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (1 responses)
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.
Posted Oct 21, 2022 22:00 UTC (Fri)
by wahern (guest, #37304)
[Link]
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.
Posted Oct 19, 2022 14:23 UTC (Wed)
by jafo (guest, #8892)
[Link]
Posted Oct 18, 2022 17:54 UTC (Tue)
by IanKelling (subscriber, #89418)
[Link]
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.
Posted Oct 18, 2022 21:09 UTC (Tue)
by amarao (guest, #87073)
[Link] (1 responses)
Posted Oct 19, 2022 14:33 UTC (Wed)
by patrakov (subscriber, #97174)
[Link]
Posted Oct 19, 2022 6:06 UTC (Wed)
by leromarinvit (subscriber, #56850)
[Link] (2 responses)
*ducks*
Posted Oct 19, 2022 10:43 UTC (Wed)
by grawity (subscriber, #80596)
[Link] (1 responses)
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).
Posted Oct 19, 2022 15:29 UTC (Wed)
by patrakov (subscriber, #97174)
[Link]
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.
Posted Oct 19, 2022 19:59 UTC (Wed)
by afeiszli (guest, #161699)
[Link] (1 responses)
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!
Posted Oct 27, 2022 12:50 UTC (Thu)
by mrugiero (guest, #153040)
[Link]
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 :)
Posted Oct 19, 2022 20:30 UTC (Wed)
by mtaht (subscriber, #11087)
[Link]
https://forum.openwrt.org/t/new-wireguard-based-openwrt-v...
Posted Oct 21, 2022 4:20 UTC (Fri)
by nickodell (subscriber, #125165)
[Link]
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.
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
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
Identity management for WireGuard
It is possible to ignore commands from the server and manually set up the routing needed to make things work.
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
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.
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
Identity management for WireGuard
unetd wireguard + dht
Identity management for WireGuard