Show HN: Dsnet, a simple command to manage a centralised WireGuard VPN | Hacker News Reader

Show HN: Dsnet, a simple command to manage a centralised WireGuard VPN

github.com

69 pointsnaggie11 comments

I was using wg-quick at home + work but it got tedious to add peers and track what key was for what peer.

I looked around but I considered the available wireguard GUIs / tools (such as subspace) to be too heavyweight and/or have a few security concerns.

So, I wrote dsnet in go. dsnet manages subnet generation, IP allocation, key generation and peer management.

* A sane and working server peer configuration is generated with a single command * Client peers are added/removed with a single command * A JSON report suitable for producing a HTML rendered peer status display can be generated with one command

There's more in-depth information on the github README, and background + a tutorial on my website: https://callanbryant.co.uk/blog/how-to-set-up-a-wireguard-vp...

Thanks for reading!

You should add it to the lists in https://github.com/pirate/wireguard-docs

Good idea, I will do later today

> The peer private key is generated on the server, which is technically not as secure as generating it on the client peer and then providing the server the public key

"Not as secure" means specifically this punts all the actual security of the system.

This is one of the sad but predictable thing with designs like WireGuard that themselves decided to punt this hard problem (you can also see it in OpenVPN [edited: Let's blame an early morning for me writing OpenSSL there] and with the same consequences). So in one sense it isn't your fault - Jason knew this was hard but left it for you to solve anyway, and predictably you didn't.

But of course for the end user the practical result is that they maybe don't get the security benefits they were told were available in WireGuard.

My crystal ball is cloudy but I'd guess that one possible future for WireGuard is that it gradually grows a reputation for insecurity not because WireGuard the protocol is bad but because the way it's used has meant almost invariably bad guys get private keys they shouldn't have.

The irony being that this is what the IPSec people have been arguing because WG externalities all the messy real-world bits which now have to be solved again.

But I think your criticism is overly harsh. A lot of the use-cases for WG are to connect a group of systems that are mutually trusted. But even if they aren’t, the sever potentially knowing your single-use private key doesn’t matter as much as your making it seem because all an attacker can do is authenticate as you. Who cares at that point when the server is compromised.

Some prior art. The standard OepnVPN setup on pfSense stores the CA keys and all client keys on the server.

The history of practical encryption has been largely about solving the "messy real-world bits".

I am emphatically not saying here that WG is a step backward. But what I had hoped to see - either from Jason or from somebody else in that community - were practical approaches to actually deploy this safely in real environments people have.

Let me give you a small not very related example that made me smile recently of how to make security usable:

Magic wormhole will cheerfully help do SSH public key setup for a new device that needs access.

Normally this is a messy real-world problem. The SSH public key for a new laptop, or a phone, or whatever needs to get authorized for access to some system. As a public key it isn't secret, but the correct key must be installed or you'd be subject to a sophisticated MITM. Unlike the server authentication there is no provision for TOFU and it's unclear how that should work anyway. SSH keys are too long to just read them out comfortably, secure messaging platforms add clumsy extra steps (copy, paste)...

But Magic Wormhole fits the gap pretty nicely. You run one end of the wormhole on the machine where the key is to be installed, and the other on the machine that has the key pair, secured with a trivial human memorable passphrase like '6-candle-cheesegrater-horse' and the result is simple but safe†.

† I've argued Wormhole security thresholds should be higher mostly for PR reasons, but it's not a deal breaker and you can doubtless find my rambling about that if you care.

> "Not as secure" means specifically this punts all the actual security of the system.

In my opinion, not quite; the peer private key only exists on the server for a short amount of time which somewhat mitigates the problem.

I agree it's not ideal but it is convenient, and a good balance for the average user in my opinion. I will support specifying a public key as part of the `add` command soon. See https://github.com/naggie/dsnet/issues/8 (also, see the FAQ)

Thanks for the feedback

I was just having a very similar problem. Thank you for your code.

You're welcome, glad it was useful.

Can someone guide me to how wg decides on whether a route push created by wg becomes default or not? Don't see a config option to decide that in dsnet

Each connection in WG has an “allowed-ips” which say what source addresses a peer is allowed send traffic with.

The most common behavior is to automatically route that list of ips over the tunnel. You don’t have to do this. But if you do and then specify 0.0.0.0/0 and/or ::/0 then all traffic goes through the tunnel.

Reply on news.ycombinator.com