
I made my own WireGuard VPN server - axiomdata316
https://techcrunch.com/2018/07/28/how-i-made-my-own-wireguard-vpn-server/
======
StavrosK
I was going to post this tomorrow, but I figure people here might find it
useful now. I wrote an article on how to configure Wireguard for common
scenarios:

[https://www.stavros.io/posts/how-to-configure-
wireguard/](https://www.stavros.io/posts/how-to-configure-wireguard/)

~~~
Foxboron
I think the wg0 references should be swapped with `%i` as the config is
dependent on the filename with that setup. Neat write up however.

~~~
StavrosK
Oh, great suggestion, thanks for that! I'll update it as soon as I get home.

EDIT: Updated and published, thanks again.

------
dragonsh
Streisand makes it very easy to setup privacy focused secure VPN including
support for wireguard and tor. Just provide credentials of your preferred
Cloud provider and it will do the setup very quickly and provide you easy
instructions to use VPN and proxy on desktop and mobile phones.
[https://github.com/StreisandEffect/streisand](https://github.com/StreisandEffect/streisand)

~~~
zhte415
I too use Streisand. It has a vast plethora of options. I would warn this
blessing can become its achilles heel as this introduces a potentially large
attack space. I limit every deployment of it to Wireguard and OpenConnect only
as these are the only options I use.

~~~
TabTwo
True, it’s a Swiss Knife with way to many options. It’s ok for a vacation with
your family in a country that blocks Wikipedia or you visit a place with
shitty WLAN with blocked ports. Streisand takes 15 minutes to setup and your
done. If you need something permanent like a company VPN, you really need to
spend more than 15 minutes. Way more than that.

------
obeattie
We use Wireguard extensively at Monzo. It’s such a workhorse: extremely
performant, straightforward to administer. Having dealt with the horrors of
IPSec before, I can safely say I’d never go back.

~~~
chrisper
I used IPSec before because OpenVPN was just too slow.

Is Wireguard similar to OpenVPN when it comes to configs?

~~~
dpwm
WireGuard is simpler to configure than OpenVPN and there's much less to tweak.

A real-world config file can be under 10 lines for the client and under (10 +
5 * n_clients) lines for a server.

Private and public keys are short base-64 encodings of 256-bit keys and can be
generated with the wg command line tool. These live inside the config file.

------
mirimir
OK, that's cool and all.

But what's really cool about WireGuard is how _simple_ it is. It's far simpler
than OpenVPN, and vastly simpler than IPSec/IKEv2. Given SSH logins to a pair
of VPS, it takes maybe an hour at most to setup a link.

[https://www.wireguard.com/quickstart/](https://www.wireguard.com/quickstart/)

~~~
hardwaresofton
Is it arrogant that I feel like I've basically invented this once before? The
combination of asymmetric keys for identity and symmetric rotating keys for
actual message sending is something that's just always made sense to me, but I
never bothered trying to implement this since I was usually working in a web
context and "just use HTTPS", was the better solution than trying to work out
a custom scheme.

[EDIT] - when I think about it, the management with kernel internals is
definitely something I couldn't do. Writing kernel-level drivers/software is
not my cup of tea.

~~~
Ao7bei3s
Just naive, not arrogant (it's ok & encouraged to think through things
yourself, even if there already is a solution. you can't expect to come up
with actually new good things on day 1.).

You've described the obvious part - this is in any crypto intro course. But
it's not even getting the details of that right (which is _a_ challenge)
that's interesting, because that's not where wireguard innovates. Well it does
actually propose a nice scheme, but still - OpenVPN (in TLS mode), IPSEC (with
IKE, else it's DIY) and, in a way, HTTPS already have working schemes.

wireguard shines is other areas: the simple (factor 500 smaller code than
IPSEC/IKE), performant and fully in-kernel (both unlike OpenVPN)
implementation, ifaces instead of xfrm policies (for IPSEC. though that's not
entirely far, you can have VTI's. they just don't scale well we've found.),
the lessons learned wrt crypto agility (tl;dr: don't), implicit source
verification, the beautiful DOS cookie implementation (feels nicer than TA
key), that servers are silent/invisible unless you know their public key (cant
provoke any response packets without), all connections are p2p. To name a few.
Read the Wireguard paper. It's short and very approachable.

~~~
tialaramex
> lessons learned wrt crypto agility (tl;dr: don't)"

This definitely doesn't qualify as a lesson learned. It's maybe, maybe, best
current practice, if you squint.

We've even seen in other threads the WireGuard author arguing that oh, well,
if there's a problem with say key exchange (it has a "conventional" elliptic
curve key exchange and so an adversary with a big Quantum Computer definitely
breaks that) then you can still rescue with PSKs. And as well as not
addressing problems in any other primitive that doesn't stand up to a laugh
test. If PSKs were fine you would already use PSKs and not have all this
complicated public key dance at all.

In reality if there's any problem you have to throw WireGuard itself away. So
the hope is maybe all these primitives are fine. And that hope will seem 100%
on the money right up until it isn't. We will see then, I think, valuable
character information about its designers and key proponents, in light of how
they react to that particular lesson, for example in helping people migrate
off their now fatally damaged baby.

The lesson learned wasn't "don't" it was that "more is always better" is
wrong, we didn't need fifteen mediocre symmetric block ciphers without much
cryptanalytic research behind them in TLS. But zero agility _definitely_
hasn't proven itself to be the right choice here either, it's just less work
to implement.

~~~
tptacek
No. Were Chapoly to be broken next year, we wouldn't "throw away" WireGuard.
We'd simply instantiate it over a new set of primitives. That is part of the
point of deriving it from Noise.

The idea behind zero-negotiation cryptography is that if there's a problem
with the primitives behind the protocol, you _version the whole protocol_ ,
rather than hoping that some complicated negotiation scheme can future-proof
it. No part of TLS's security problems have stemmed from "fifteen mediocre
symmetric block ciphers"; rather, almost all of them have come from the TLS
protocol's complicated handshaking.

~~~
tialaramex
It's not about the inconvenience for WireGuard's author in writing a modified
protocol document, "simply" instantiating the protocol with new primitives (or
parameters, or any changes at all) means throwing WireGuard away as far as all
the end users are concerned. For the sort of hobbyist "Hey, I hacked this
together in five minutes, awesome" types running Wireguard today in a trivial
pair-wise configuration this is no trouble. For a system with fifty thousand
ordinary users this is a complete nightmare, and I expect what they'll do is
consider that a lesson learned, no more WireGuard.

But perhaps at least some of them will try to muddle along as others have
described below, let's try both versions and see what works. Then we don't
need a flag day... Whereupon of course they've got a downgrade problem.

Because TLS has been such an overwhelming success there have been a lot of
problems.

Let's start with BEAST. BEAST attacks the way TLS 1.0 does IVs. Is that
anything to do with "complicated handshaking" ? Nope, not related at all.

Soon after that there's Lucky 13. This attacks CBC modes with a timing-based
padding oracle. Handshaking? Nope.

How about RC4 being broken - Handshake problem? Nope, the RC4 stream cipher is
just not as good as intended.

CRIME was a compression oracle, still not handshaking.

Coppersmith's and ROCA, as well as the Debian hilarity show that even minting
private keys might be too hard, at least in RSA, for people to do it
correctly. Once again, not related to handshaking.

Now Logjam really does come down to the complicated handshake, although it
does also need a client which is a total sucker.

Some? Yes. "Almost all" isn't correct. Lots of problems with cryptographic
primitives and implementation bugs, maybe WireGuard will be popular enough to
have so many implementations and to have such a large number of researchers
trying to break it...

~~~
pvg
_Let 's start with BEAST._

That's an interesting one to pick. It could not be fixed by negotiation and
configuration at all, in the end. The entire protocol version had to be thrown
away.

~~~
tialaramex
Beast works on TLS 1.0

The die-die-die draft would never have been written if we were looking at a
situation where TLS 1.0 was gone in practice on the web, let alone SMTP and
other slower-moving environments. Even PCI's day-late, dollar-short June 2018
deadline would have been irrelevant if you're right. You aren't right.

No, BEAST's story is much more interesting than that, there were three
mitigations and one remains widely in use.

One "configuration" mitigation was to move to RC4 since that's not a block
cipher so the CBC mode attack doesn't work by definition. This is no longer
considered acceptable because RC4 is way weaker than we'd thought at the time.

The next mitigation is "empty fragments". An attacker only gets to peak at
certain data using BEAST (and then they expand the attack and get everything)
but we can arrange for the vulnerable block to have zero length, and then the
attacker didn't achieve anything for all their effort. We waste a few bytes on
the wire, but this works fine by the specification. Alas, some real world
implementations had been written to reject these "empty fragments", which had
never been needed previously and so you couldn't actually use this in products
like web browsers.

Instead client implementations began doing 1/n-1 split, which moves a single
byte instead of nothing. The attacker has 1-in 2^16 chance to guess this using
BEAST, but it's a single byte, so they had 1-in- 2^8 chance to guess it
without BEAST, and thus BEAST is worthless if you can do this.

Of course it's still _wasteful_ but it's both protocol compliant and an
effective mitigation. How about that?

~~~
tptacek
'pvg is right. You're rattling off lots of random technical details about the
attack, but his single sentence captures a core problem with "agility":
_despite having all the complicated handshaking_ , a whole protocol version
had to be burned to fix the problem.

Your confused argument suggests that because BEAST involved chained IVs and
not the TLS handshake, it's an example of how the handshake didn't sabotage
TLS. You're right: it's not. It's an example how the handshaking, which
sabotaged TLS through other attacks, _didn 't buy anything material for TLS._

~~~
tialaramex
The confusion seems to lie with you here if it's with anyone. The stop gap RC4
preference is explicitly enabled by handshaking.

Beyond that though you seem to have your history out of order, BEAST is a TLS
1.0 attack, but TLS 1.2 was finished years before BEAST was published.

It's not a case of a protocol version "had to be burned to fix the problem"
but two subsequent protocol versions had already shipped years ago which fixed
the underlying cause and, as is the reality for which you seem so ill-
prepared, scarcely anybody had upgraded.

All these years later financial services companies are getting waivers from
PCI saying their cheap third rate POS terminal "has a mitigating control" and
so it's fine that they still do TLS 1.0. So that's nice. Nice for them I mean.
Hey, if you're "lucky" one day they'll be relying on a ten year out-of-date
WireGuard, as enthusiastically endorsed by Thomas Ptacek. And every time
you're asked about it you can spit feathers. How dare they. Like I said, if
you're lucky.

As messy and uphill as it has been, the journey from SSLv2 to TLS 1.3 was only
possible with the handshake.

~~~
pvg
_but two subsequent protocol versions had already shipped_

That doesn't really address the 'agility didn't help here' point at all. The
argument against agility as a design approach is straightforward and widely
articulated - it's obviously informed by the SSL/TLS experience but doesn't
outright _depend_ on it. It's not too difficult to imagine that there could be
some sort of coherent counter-argument. If you have one, though, it's
impossible to parse it out from this enthusiastic mixture of non-responsive
detail and superciliousness.

~~~
tialaramex
But it did help there, as I already pointed out and you ignored twice.

~~~
tptacek
It did _not_ help here. In fact, it amplified the problem. We knew RC4 to be
broken when BEAST was announced. Nevertheless, people enabled it, as a
"stopgap", to deal with BEAST. RC4 is arguably less secure than BEAST-affected
TLS (BEAST was in practice quite difficult to trigger), and, either way, all
those RC4 deployments ended up also needing to be scoured off the Internet!

------
cheghook
Hmmm, I've always wondered why you'd want to run your own VPN server. The very
first step is to rent a server from Microsoft/Google/DigitalOcean/etc and then
setup the VPN on that server, right?

But how does it help you stay anonymous? You are still paying for that server
using your CC and they'd have your address and all other info. Unless I can
rent the server anonymously, I can't see any point to run my own VPN server.
That's why I'm paying a third party, PIA for example, to rent and run that
server for me.

~~~
vbezhenar
I'm renting VPS in Netherlands. I'm using VPS mostly to circumvent internet
censoring my country does (mostly porn sites, but they occasionally breaking
legit sites and what's wrong with porn anyway). There's no legal punishment to
circumvent blocks AFAIK, so I feel pretty safe even if someone would find out
I'm doing that (it's not like I'm hiding, gigabytes of traffic on standard
OpenVPN port, lol). But anyway I'm sure that Netherlands provider won't tell
anything to Kazakhstan request even if they would ask something and I don't do
anything to warrant Interpol engagement. It's all about attacks you want to
mitigate, I think. If you want to break into Pentagon, that won't work, I
guess.

~~~
tinco
Still be safe, if the government gets proactive and starts to make house
visits to people who are having suspicious long running connections to foreign
national transferring GB's of data you don't want to be caught with loads of
illegal to own content on your machine.

Doing that kind of analysis has become very easy and cheap recently.

------
imhoguy
Beware of DNS leak [0]! It is easy to overlook when one configures own VPN
solution.

[https://en.m.wikipedia.org/wiki/DNS_leak](https://en.m.wikipedia.org/wiki/DNS_leak)

~~~
throwaway77384
If you use OpenVPN, add the following (without quotes) at the end of your
config file:

"block-outside-dns"

then run this test:

[https://www.dnsleaktest.com/](https://www.dnsleaktest.com/)

I pass the extended test with it. Very easy and worth doing.

------
crtasm
GDPR prompt implementation is terrible, shows the article, then redirects to
prompt, then reloads article! Have to press back three times to return to HN.

------
kdv
I truly appreciate Wireguard's simplicity but what's the best way to handle
key management and peer address assignment in larger deployments?

~~~
StavrosK
That's the only feature request I have as well. Something where you could
reference a file would be ideal, for example your config could be:

PrivateKey = !peername

Publickey = !peername

And the actual credentials could be in a separate file with a specific name,
with one peer per line:

peername:pubkeystring:privkeystring

That would make deployments much easier, as the credentials could be handled
separately.

However, the peer address assignment is another good question. One file per
peer would be better, I think, but you'd need something like another
directory, and, at that point, you might as well write a script to take all
your config and concatenate it into one file. That having been said, I don't
know why that can't be a part of wg-quick.

------
nicois
What is the recommended way of UDP tunnelling wireguard? Is it necessary to
run something like pwnat alongside it, or is there a better way?

Using a TCP based VPN there are services such as ngrok for exposing only the
VPN endpoint behind a NAT, but nothing equivalent for UDP.

Unless it's possible to use the android and other clients to work in this way,
it will limit the uptake of this, I believe.

~~~
chungy
For the sides that need to listen to an incoming connection (your server,
typically), you'll need a direct port open, which might just be passed through
via a NAT.

For clients, it works like all other UDP applications, it just reaches out to
the remote address and the NAT keeps a temporary mapping of the source and
destination ports and addresses.

------
pt
On the client, is it possible to setup an “always on” VPN? Such that when the
client restarts on reboot, there is no internet connection until the VPN is
on. Or when either the client or server glitches, the end point
computer/mobile does not connect to the internet in the clear?

~~~
diafygi
On Ubuntu, for each wifi/wired connection settings, there's a checkbox and
dropdown to automatically connect to one of your VPNs.

~~~
sexydefinesher
Its really frustrating that there isnt an option to enable automatic VPN for
all connections.

------
chrisper
I would like to try out WireGuard.

Has anyone made any experience with TunSafe?

[https://tunsafe.com/](https://tunsafe.com/)

~~~
berti
It's closed source crypto software. You can make your own judgement on how
acceptable that is for you. Jason Donenfeld (Wireguard author) strongly
recommends against it [1].

[1]
[https://lists.zx2c4.com/pipermail/wireguard/2018-March/00244...](https://lists.zx2c4.com/pipermail/wireguard/2018-March/002448.html)

~~~
dpwm
Worth noting there was a HN discussion on it from 5 months ago. [0]

I got the impression that ludde (the author of TunSafe) seems to think that
people should trust him because he wrote uTorrent and he is, for reasons not
specified, opposed to releasing it open source and suggests that the author of
wireguard has a "general dislike against non open-source applications."

For what it's worth I really cannot understand the mentality that would lead
to you creating a high-quality, benign VPN client that you have no intention
to charge for or sell and not wanting eyes (which have certainly been offered)
to look over it before users rely on it.

[0]
[https://news.ycombinator.com/item?id=16515637](https://news.ycombinator.com/item?id=16515637)

~~~
PlutoIsAPlanet
I'm still confused as to why Tunsafe isn't open-source. I feel like if he
wanted people to trust it, open-sourcing it would be a way to go.

There's nothing wrong with non open-source applications in general, but when
it's a closed-source client of an open-source VPN server, you can't trust it,
sorry.

~~~
ludde
I don't want to lose control over it. If I open source it then anyone could
just take it and rebrand it and pretend it's theirs.

~~~
shock
> If I open source it then anyone could just take it and rebrand it and
> pretend it's theirs.

Not necessarily. Depends on what license you use for the code, but if it's not
a copyleft license they can't even create a (legal) copy if you maintain
copyright and don't give anyone a license to copy the code.

~~~
mnutt
It's probably less about legal forks and more about bad actors forking it,
inserting spyware, and buying Google ads against "vpn server" and "tunsafe".
It seems like it's more of a problem for open source software targeting
nontechnical users, and I imagine uTorrent had a lot of issues with it.

~~~
berti
I can see that angle. We're all used to curated packages from distro
maintainers, whereas Windows software is like the wild West, especially for
those not so technically competent.

------
vbezhenar
I've heard a lot that WireGuard is faster than OpenVPN. I must admit that my
OpenVPN connection manages few megabits even if my server allows 100 Mb/s and
my home connection allows 300 Mb/s. I didn't test WireGuard, it seems too hard
to configure yet, but I wonder why is it more performant?

~~~
StavrosK
I found it similarly hard to configure, so when I finally managed it, I wrote
up how so you can try my configs: [https://www.stavros.io/posts/how-to-
configure-wireguard/](https://www.stavros.io/posts/how-to-configure-
wireguard/)

------
puzzlingcaptcha
So this requires maintaining an out-of-tree kernel module? Does it require
rooting on android?

I find OpenVPN plenty fast for personal use (with adjusted send/receive
buffers and AES-NI on the server)

~~~
Tharre
It does not require rooting on android, the wireguard app[0] falls back to the
userspace implementation if the kernel module is not available.

[0]
[https://play.google.com/store/apps/details?id=com.wireguard....](https://play.google.com/store/apps/details?id=com.wireguard.android)

------
brian_herman
Wow this is the best TechCrunch article I have seen in a while that has
reached the front page! Dude whoever wrote this deserves a big ass raise!

~~~
tempotemporary
IMO they simply had nothing else to write about. This is the first time I see
“how to” on TechCrunch.

------
thr0000waay
Meh.

[https://nixos.wiki/wiki/Wireguard](https://nixos.wiki/wiki/Wireguard)

------
sologoub
> Algo VPN runs on any Ubuntu server, but the easiest way to host your server
> is to create an account on DigitalOcean.

Advertorial?

~~~
andkenneth
I feel like saying the entire thing was written to direct people towards DO is
stretching it just a tad. Possible that they have some affiliate program with
DO? Sure. But Algo itself says that DO is the "most user friendly" on their
github page.

~~~
sologoub
Considering Google Cloud is offering $300 credit and their Console is top
notch AND offers browser based SSH. DO is not as obvious of a choice.

Sustained use discount and top notch network further the case.

