7 ms·

What I don't like about WireGuard: - Basically no real user or admin-oriented docs. There's some example configs and some getting started guides, and then some

What I don't like about WireGuard: - 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.

q3k 7y ago
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.
- megous 7y ago
  What do you mean by static keys? All keys are changeable at runtime and wireguard uses public key cryptography.
  - q3k 7y ago
    That all clients have to be configured on each server.
    - megous 7y ago
      Server has to know what clients to accept in any VPN solution. I still don't see the point.
      - q3k 7y ago
        > 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.
        namibj 7y ago
        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.
        megous 7y ago
        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.
vsareto 7y ago
>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.
ecnahc515 7y ago
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.
- atmosx 7y ago
  Are you going to open source it?
  - ecnahc515 7y ago
    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.
- d21d3q 7y ago
  Have a look on how Cloudflare's WARP vpn handles this: https://github.com/aghorler/cloudflare-warp-wg-client https://github.com/aghorler/cloudflare-warp-wg-client
- peterwwillis 7y ago
  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.
nucleardog 7y ago
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 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.
nikisweeting 7y ago
Here's some docs: https://github.com/pirate/wireguard-docs https://github.com/pirate/wireguard-docs

q3k 7y ago

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.

megous 7y ago
What do you mean by static keys? All keys are changeable at runtime and wireguard uses public key cryptography.
- q3k 7y ago
  That all clients have to be configured on each server.
  - megous 7y ago
    Server has to know what clients to accept in any VPN solution. I still don't see the point.
    - q3k 7y ago
      > 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.
      - namibj 7y ago
        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.
      - megous 7y ago
        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.

vsareto 7y ago

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

ecnahc515 7y ago

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.

atmosx 7y ago
Are you going to open source it?
- ecnahc515 7y ago
  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.
d21d3q 7y ago
Have a look on how Cloudflare's WARP vpn handles this: https://github.com/aghorler/cloudflare-warp-wg-client https://github.com/aghorler/cloudflare-warp-wg-client
peterwwillis 7y ago
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.

nucleardog 7y ago

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

nikisweeting 7y ago

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