
Show HN: Dsnet, a simple command to manage a centralised WireGuard VPN - naggie
https://github.com/naggie/dsnet/
======
naggie
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...](https://callanbryant.co.uk/blog/how-to-set-up-a-wireguard-
vpn-in-minutes-with-dsnet/)

Thanks for reading!

~~~
nikisweeting
You should add it to the lists in [https://github.com/pirate/wireguard-
docs](https://github.com/pirate/wireguard-docs)

~~~
naggie
Good idea, I will do later today

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

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

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

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

~~~
naggie
You're welcome, glad it was useful.

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

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

