Hacker News Reader

If you want SSO, or fine grained access control, the idea is you would do that at a level above wireguard. For example, I'm prototyping a small CLI that talks to hashicorp vault via OIDC/OAuth2, and then creates a wireguard key pair + configuration locally, submits the public key to vault, and then the wireguard "server" is configured with a simple daemon that pulls all the public keys from vault and generates a wireguard configuration allowing access from those public keys.

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.

Have a look on how Cloudflare's WARP vpn handles this: https://github.com/aghorler/cloudflare-warp-wg-client

It sounds cool, but it also extends the amount of components that have to be made resilient to failure and attack. Your HA vault+consul clusters, HTTPS & OAuth2, key generation, and automation pieces (inc. message passing & load balancing) all need to be working correctly. Compare that to a single stateless server which spits out an OAuth2 login url to a client, receives a token once the client is authed, and opens a connection with that user's specific network authorization.

Agreed, but as OpenVPN has shown us, it's not a guarantee that security will be any better if everything is contained within a single process.

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.

Are you going to open source it?

If it gets anywhere yes, I've been a bit busy with life and it's been in a pause. The other aspect is this isn't super useful yet because I still need to implement the server side, as well as figure out how to make this useful as non-CLI for my mobile clients (iOS), which are the majority of what I use the VPN for.

WireGuard is a networking primitive. It creates a secure tunnel between two points and only contains the things necessary to make that happen.

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.

>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.

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.

Here's some docs: https://github.com/pirate/wireguard-docs

Very much agreed. While for simple use cases static keys are more than fine, a proper PKI is basically the only sane way to deploy a VPN in an enterprise or even small company setting.

What do you mean by static keys? All keys are changeable at runtime and wireguard uses public key cryptography.

That all clients have to be configured on each server.

Server has to know what clients to accept in any VPN solution. I still don't see the point.

> Server has to know what clients to accept in any VPN solution. I still don't see the point.

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.

Wireguard doesn't respond at all (not SYN/ACK stuff) if not provided with a correctly signed packet. This means you can't scan for wireguard ports without already being configured for them.

I see. Though if you ever want to remove access you'll still not avoid distributing information about individual clients to the VPN servers. It will just be a blacklist style list and not a whitelist like in WG.