It’s nice to see one of these providers upgrading their protocols away from openvpn and the like, but it still doesn’t solve the problem of these commercial VPN’s are still just someone else’s computer.
It is really nice, OpenVPN is good, but it is definitely harder to configure, and slower. I also like that it is hard to shoot yourself in the foot with Wireguard given it is really hard to mess up and create an insecure config.
ProtonVPN is also at least a bit better than other commercial VPNs, specifically the "Secure Core" feature is quite good. Proton is one of only like two or three companies I actually trust when it comes to their security and honesty.
I think the point is that public VPNs don't provide much additional security. Basically they just let you act from a different location on the internet. Is your traffic safer egressing on to the public network from your current location, or from the VPN's location? In some cases the VPN may be better. In others, your local network makes more sense.
If what you care about is encrypting traffic, then set up WG yourself and have a free tier / $3/m machine do the relay. Or your router. It's so easy there's really no excuse not to.
If what you care about is anonymizing your traffic, then you need someone else's computer. That's the idea, to mix your traffic in with a bunch of other traffic.
WG isn't just stable, it's so easy to configure and set up you'll wonder why you didn't do it ages ago. At least that's the way it was for me.
I stand by my assertion that eventually nobody will talk about Wireguard because everyone will use it for almost everything. It'll be like HTTPS, TLS, or TCP.
I tried setting it up on a VPS on Ubuntu the other day, got it installed after doing some config files, connected to the tunnel, could access the server but not the wider Internet. Made about 4-5 config changes per a bunch of Stackoverflow posts then gave up since nothing worked.
Installed OpenVPN instead, took me 2 minutes and worked immediately with far fewer config files changes.
I've had this experience before with Wireguard as well. People keep saying how easy it is and in my experience... it simply isn't.
OpenVPN has a lot of BS overhead and I'd be more than pleased to move off of it. But WG hasn't been simple for a common use case - install on Ubuntu VPS, client on Windows.
apt purge'd it, reinstalled and updated my Windows client, now getting this entry in the Wireguard log:
2021-10-11 15:18:30.313: [MGR] Failed to connect to adapter interface \\?\SWD#WireGuard[REDACTED]: The system cannot find the file specified. (Code 0x00000002)
So, again, I'd like to use it but... dead simple it ain't. Googling that error shows 5 month old reddit posts and not much else.
Like I said, everyone keeps saying Wireguard is dead simple to set up, but the comments are full of editing configuration files, priv/pub key pairs, etc. I've helped administer OpenVPN servers for a decade now (and take no pride in it), and yet all these errors that keep coming up in Wireguard configuration for me on a main Linux distro + Windows 10 client seem pretty odd for something that's supposedly so easy to use.
Someone just come out with a wizard/package installer that actually works reasonably well (like OpenVPN has already) and then it might be "easy" to install. For OpenVPN I run an apt install command, run a wizard, SFTP into the box, transfer out the .ovpn file, import it into whatever client devices I need, and it works. Wireguard is at least 10 times tougher than that, even if it worked, which it currently does not.
I have both OpenVPN and wireguard set up, running my own server/"server" peer... First OpenVPN because that's what I used before wireguard was around (and now keep as a fallback that I never use). OpenVPN required a lot more fiddling e.g. to get a ca+client certs for auth set up, find a config that works for each OS where I have clients, etc. And then again some more work because client certs expired, and again more work because the distro changed some things and required a different config suddenly (not really OpenVPN's fault)
wireguard just worked for me, except I first forgot to enable port forwarding / the NAT stuff on the interface on the "server" peer so that I could route all traffic through it (other people already remarked about that), not just have a point-to-point to it. The point-to-point stuff worked immediately tho without having to sprinkle any magic pixie dust on top first.
Setting up a "server" is always more intricate be it OpenVPN be it wireguard, tho. But once I had two peers in my wireguard setup up and running (the "server" and the first client) adding more clients was a breeze compared to doing the same in OpenVPN. All in all, it was like 10 mins of fiddling in some testing VMs and a bit of googling, and then a couple of more minutes to apply what iIlearned and set up the real "prod".
>I tried setting it up on a VPS on Ubuntu the other day, got it installed after doing some config files, connected to the tunnel, could access the server but not the wider Internet. Made about 4-5 config changes per a bunch of Stackoverflow posts then gave up since nothing worked.
I ran into this also. The docs are quite bad, in the sense that they assume a lot on the part of the reader and only cover a fairly simple use case.
I have a script to automate the pain away with creating throw away VM instances based on Ubuntu/Debian. Almost every fail is not allowing the correct ingress port into the VM (51820 in my case)
I've been running a WireGuard setup for a couple of years now, and have been and continue to be very satisfied with it.
- WireGuard server running on my FreeBSD VPS. Always on.
- WireGuard client running on my MacBook Pro M1 laptop (and prior to that, on the MacBook Air that I had before this computer). I activate this one when I need to connect to my server or to some other device on the VPN.
- WireGuard client running on my iPhone X. Like with my laptop, I activate it when I need to connect to the server or to another device on the VPN.
- WireGuard client running on my grandfather's Mac Pro desktop computer. Always on. This allows me to remote into his computer via the macOS-builtin VNC server on his computer, to help him out when he is stuck at something. I use the macOS-builtin VNC client on my MBP or a third-party VNC client on my iPhone. In either case the connection is tunneled over the WireGuard VPN. I also have the builtin SSH server running on his computer that I connect to over WG VPN to transfer files or run commands through.
- WireGuard client running on my desktop computer which runs KDE Neon Linux. Always on.
WireGuard has been almost trivially simple to set up across all of these systems; FreeBSD, macOS, iOS, Linux. And I am sure it is equally simple to set up on many other systems as well.
WireGuard has been very stable and reliable too for all of the time that I have been using it.
Some months ago I changed the WireGuard configuration on my server to run on port 443 UDP instead of the UDP port that WireGuard server would run on by default. This has allowed me to connect to my VPN even when using some public hotspots that were very restrictive on what traffic they allowed through and where previously I could not connect to my WireGuard VPN. Deep packet inspection would still block the traffic I assume, but in all cases with regular public hotspots in my country I have been able to connect to my VPN after I made this change of what port I am using. I live in Norway.
I highly recommend anyone that wants to run their own VPN to use WireGuard.
I personally use my WireGuard VPN for connectivity between these hosts only, not for tunneling traffic that is routed out onto the wider Internet. (That is, my tunnel runs over the Internet but I only use it for traffic that is destined to the machines that are member of the VPN). So I cannot really comment on the use-case of tunneling Internet traffic, but from the experience with connecting the hosts in my VPN I can only assume that tunneling Internet traffic would work out equally well.
Yes, his computer is on my VPN and has a static IPv4 address inside of the VPN, 10.42.42.4, as well as a static IPv6 address inside of the VPN, fc42:4242:4242:4242::4.
I updated my comment above to note that I use my VPN for connectivity between hosts only, but across the Internet. So I can connect to any host in the VPN from anywhere in the world, but all of the hosts still send all of their other traffic via the same interface that they would if they were not part of the VPN.
So when he browses the Internet, his traffic is routed by his ISP directly and the VPN is not involved, and the same goes for my own computers and other devices.
Can you point me to some docs on how to accomplish this? I'm currently using Slack Nebula to achieve similar goals but every time I looked up WireGuard tutorials, it was to tunnel traffic through a VPS, which I didn't want to do.
wg genkey | tee server.private | wg pubkey > server.public
wg genkey | tee iphone.private | wg pubkey > iphone.public
wg genkey | tee stuegris.private | wg pubkey > stuegris.public
wg genkey | tee nova.private | wg pubkey > nova.public
wg genkey | tee schumberry.private | wg pubkey > schumberry.public
And then I printed the values of each of the files to the terminal simply by cat'ing them to the terminal and copying the values into the respective places. For the server, only the private key is used in the config and the server config likewise contains only the public keys for the clients. For each of the clients, as we will see below, the config contains the private key of the client in question and the public key of the server.
The names "server.private", "server.public", "iphone.private", "iphone.public", "stuegris.private", "stuegris.public", etc are just corresponding to the different hosts and devices. Likewise I have comments in the config file corresponding to which host or device each entry is for.
All of theses files "server.private", "server.public", "iphone.private", "iphone.public", and so on are just temporary. After you've created the config files for the server (above) and the clients (below) you can delete these files.
In /etc/rc.conf on the same FreeBSD server I have added
wireguard_enable="YES"
wireguard_interfaces="wg0"
If your server is running Linux then the setup will be different in terms of how to enable the service. For example if your server is running a disto that uses systemd, then you'd typically create a WireGuard config similar to mine but place it at /etc/wireguard/wg0.conf and then you'd run
sudo systemctl enable --now wg-quick@wg0
On each of the clients I have corresponding configurations.
Here is what the configuration of WireGuard client for my MacBook Pro M1 looks like:
I'm renting a couple of VPSes from Vultr that I run FreeBSD on. Very low cost, and decent for my current use which include self-hosting email, hosting a couple of websites that receive little traffic, as well as to host the mentioned VPN, and for testing of some backend services that I am developing.
I hope to afford racks of beefy bare-metal servers one day that can sit in colocation data centers and that I can host backend services for others on. But for the time being I do not have the funds for that so a couple of small VPSes for my own use it is :)
All the replies to your comment seem like sales pitches that don't actually explain anything.
The difference between wireguard and OpenVPN is that there is no real negotiation between the client and server.
Connecting to OpenVPN can take several seconds as it authenticates you, figured out encryption algorithms, IP and route management. If the network or OpenVPN server hiccup, it drops you and you need to reconnect and renegotiate again.
Wireguard does not do this, the interface comes up regardless if the remote server is up. The client and server key have already been exchanged, the routing and ip are statically configured, so the server can just receive packets without any negotiation.
Clients are identified by their public key, so roaming and ip switches are seamless as well.
There actually is a very tiny amount of negotiation in that protocol has perfect forward secrecy, so the connection re keys every two minutes (hard codes time value).
> All the replies to your comment seem like sales pitches that don't actually explain anything.
It's sort of hard to provide any other than "yes/no" to a question like "Is WG stable/reliable", right?
For most uses the answer is probably "yes" but there are use cases (I'm guessing around auth and middleboxes that do not like UDP) where the answer would be "no".
> WireGuard is also orders of magnitude more secure than OpenVPN.
This entirely depends on how you configure OpenVPN, which encryption to allow it to support, HMAC, hashes, etc. If you configure it with maximum security, it is equally secure as WireGuard. If you configure it less so, then you allow older clients to connect.
I think what the parent post meant isn't necessarily security in the transport, but security in the code.
The wireguard has around 4k LOC [0] and you can read and understand it in a weekend (or faster depending on your skill).
Also you not only don't have to configure the ciphers, but you actually can't. If any of the chosen defaults isn't considered secure anymore they will be replaced [citation needed]. So even thought the code resides in the linux kernel you could still reasonably well argue that it is indeed on several levels more secure than OpenVPN. Here [1] is the whitepaper for anyone who is interested.
About the only issue I've had with wireguard is that it leaks DNS so I'm constantly getting alerts from AWS GuardDuty about suspicious DNS queries. The only way around that I can see is to run my own DNS and forward the queries that don't look like they are AWS related to a public resolver like 1.1.1.1.
I am really eager to hear details how the VPNs are implementing Wireguard - particularly the address management portion.
It doesn't really "leak" DNS, because it has no concept really of DNS resolution. It's a virtual network interface. It will not mess with your resolv.conf.
Are you tunneling out of AWS, or are you using some AWS node as a wireguard server? Sounds like the former with wireguard interface being the default gateway (I am not an AWS user and am just guessing)... Adding a route for the AWS DNS server IP(s) to use the real network interface for traffic instead of the wireguard interface might work. Something like
ip route add <AWS DNS server IP, or AWS subnet) dev <normal network interface such as eth0>
e.g. ip route add 10.0.0/24 dev eth0
Of course, that will make DNS traffic bypass wireguard. If your goal is to hide your DNS queries from AWS except for internal AWS queries, then you will indeed have to run some local resolver that is set up to use the AWS DNS server for AWS-internal queries and some other server (be it a local one or some public one) for everything else.
3 years ago I installed Project Streisand [0] on one of my Digitaocean droplets which configured automatically different VPN protocols and my favorite one has been Wireguard. To this day I still use it on all my devices and it's only last month that I was made aware that the project has been discontinued (Why??). But my Wireguard VPN is still kicking. Works like a charm. On all devices. I can use restricted apps in Africa where my bank app and Disney plus/HBO do not works...
When comparing Wireguard with OpenVPN, it’s worth mentioning that:
* While creating a point to point tunnel is straightforward with Wireguard, it’s the networking part that takes time.
You need to do a bit of networking to set up firewall, access internet and other networks, etc, that may not follow a standard formula depending on your set up.
* Wireguard creates a tunnel. OpenVPN does a lot more, such as authentication, etc. The tunneling part of OpenVPN is much smaller than the whole
The stuff that WireGuard doesn't do is part of the appeal. WireGuard is simple to understand (and audit), behaves consistently, and is easy to build on top of.
Apple is getting into VPN now and if I was to guess they would integrate it with some kind of hardware block in their silicon to make it seamless and transparent. I wonder if Wireguard is at the point where silicon makers can actually consider a hardware block such that the VPN is completely transparent to the cores. Personally I find it better to have individual devices do the VPN than at the central network of my home as I find that these mobile devices are significantly more powerful and efficient to do it.
50 comments
[ 8.4 ms ] story [ 99.9 ms ] threadProtonVPN is also at least a bit better than other commercial VPNs, specifically the "Secure Core" feature is quite good. Proton is one of only like two or three companies I actually trust when it comes to their security and honesty.
If what you care about is anonymizing your traffic, then you need someone else's computer. That's the idea, to mix your traffic in with a bunch of other traffic.
Some of the rest are probably run by criminals.
Oh yeah, let us not forget Facebook whose vpn app was created mainly to snoop on you other network activities
Edit: remember that you can roll your own temporary vpn: https://www.digitalocean.com/community/tutorials?q=vpn
I stand by my assertion that eventually nobody will talk about Wireguard because everyone will use it for almost everything. It'll be like HTTPS, TLS, or TCP.
Installed OpenVPN instead, took me 2 minutes and worked immediately with far fewer config files changes.
I've had this experience before with Wireguard as well. People keep saying how easy it is and in my experience... it simply isn't.
OpenVPN has a lot of BS overhead and I'd be more than pleased to move off of it. But WG hasn't been simple for a common use case - install on Ubuntu VPS, client on Windows.
echo 1 > /proc/sys/net/ipv4/ip_forward
2021-10-11 15:18:30.313: [MGR] Failed to connect to adapter interface \\?\SWD#WireGuard[REDACTED]: The system cannot find the file specified. (Code 0x00000002)
So, again, I'd like to use it but... dead simple it ain't. Googling that error shows 5 month old reddit posts and not much else.
https://www.reddit.com/r/WireGuard/comments/n6yocf/unable_to...
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; iptables -A FORWARD -o %i -j ACCEPT
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; iptables -D FORWARD -o %i -j ACCEPT
Like I said, everyone keeps saying Wireguard is dead simple to set up, but the comments are full of editing configuration files, priv/pub key pairs, etc. I've helped administer OpenVPN servers for a decade now (and take no pride in it), and yet all these errors that keep coming up in Wireguard configuration for me on a main Linux distro + Windows 10 client seem pretty odd for something that's supposedly so easy to use.
Someone just come out with a wizard/package installer that actually works reasonably well (like OpenVPN has already) and then it might be "easy" to install. For OpenVPN I run an apt install command, run a wizard, SFTP into the box, transfer out the .ovpn file, import it into whatever client devices I need, and it works. Wireguard is at least 10 times tougher than that, even if it worked, which it currently does not.
I have both OpenVPN and wireguard set up, running my own server/"server" peer... First OpenVPN because that's what I used before wireguard was around (and now keep as a fallback that I never use). OpenVPN required a lot more fiddling e.g. to get a ca+client certs for auth set up, find a config that works for each OS where I have clients, etc. And then again some more work because client certs expired, and again more work because the distro changed some things and required a different config suddenly (not really OpenVPN's fault)
wireguard just worked for me, except I first forgot to enable port forwarding / the NAT stuff on the interface on the "server" peer so that I could route all traffic through it (other people already remarked about that), not just have a point-to-point to it. The point-to-point stuff worked immediately tho without having to sprinkle any magic pixie dust on top first.
Setting up a "server" is always more intricate be it OpenVPN be it wireguard, tho. But once I had two peers in my wireguard setup up and running (the "server" and the first client) adding more clients was a breeze compared to doing the same in OpenVPN. All in all, it was like 10 mins of fiddling in some testing VMs and a bit of googling, and then a couple of more minutes to apply what iIlearned and set up the real "prod".
I ran into this also. The docs are quite bad, in the sense that they assume a lot on the part of the reader and only cover a fairly simple use case.
https://pastebin.com/09iE1sME
- WireGuard server running on my FreeBSD VPS. Always on.
- WireGuard client running on my MacBook Pro M1 laptop (and prior to that, on the MacBook Air that I had before this computer). I activate this one when I need to connect to my server or to some other device on the VPN.
- WireGuard client running on my iPhone X. Like with my laptop, I activate it when I need to connect to the server or to another device on the VPN.
- WireGuard client running on my grandfather's Mac Pro desktop computer. Always on. This allows me to remote into his computer via the macOS-builtin VNC server on his computer, to help him out when he is stuck at something. I use the macOS-builtin VNC client on my MBP or a third-party VNC client on my iPhone. In either case the connection is tunneled over the WireGuard VPN. I also have the builtin SSH server running on his computer that I connect to over WG VPN to transfer files or run commands through.
- WireGuard client running on my desktop computer which runs KDE Neon Linux. Always on.
WireGuard has been almost trivially simple to set up across all of these systems; FreeBSD, macOS, iOS, Linux. And I am sure it is equally simple to set up on many other systems as well.
WireGuard has been very stable and reliable too for all of the time that I have been using it.
Some months ago I changed the WireGuard configuration on my server to run on port 443 UDP instead of the UDP port that WireGuard server would run on by default. This has allowed me to connect to my VPN even when using some public hotspots that were very restrictive on what traffic they allowed through and where previously I could not connect to my WireGuard VPN. Deep packet inspection would still block the traffic I assume, but in all cases with regular public hotspots in my country I have been able to connect to my VPN after I made this change of what port I am using. I live in Norway.
I highly recommend anyone that wants to run their own VPN to use WireGuard.
I personally use my WireGuard VPN for connectivity between these hosts only, not for tunneling traffic that is routed out onto the wider Internet. (That is, my tunnel runs over the Internet but I only use it for traffic that is destined to the machines that are member of the VPN). So I cannot really comment on the use-case of tunneling Internet traffic, but from the experience with connecting the hosts in my VPN I can only assume that tunneling Internet traffic would work out equally well.
Is he on static IP?
I updated my comment above to note that I use my VPN for connectivity between hosts only, but across the Internet. So I can connect to any host in the VPN from anywhere in the world, but all of the hosts still send all of their other traffic via the same interface that they would if they were not part of the VPN.
So when he browses the Internet, his traffic is routed by his ISP directly and the VPN is not involved, and the same goes for my own computers and other devices.
The names "server.private", "server.public", "iphone.private", "iphone.public", "stuegris.private", "stuegris.public", etc are just corresponding to the different hosts and devices. Likewise I have comments in the config file corresponding to which host or device each entry is for.
All of theses files "server.private", "server.public", "iphone.private", "iphone.public", and so on are just temporary. After you've created the config files for the server (above) and the clients (below) you can delete these files.
In /etc/rc.conf on the same FreeBSD server I have added
If your server is running Linux then the setup will be different in terms of how to enable the service. For example if your server is running a disto that uses systemd, then you'd typically create a WireGuard config similar to mine but place it at /etc/wireguard/wg0.conf and then you'd run On each of the clients I have corresponding configurations.Here is what the configuration of WireGuard client for my MacBook Pro M1 looks like:
Here is what the configuration file /etc/wireguard/wg0.conf of WireGuard client on my Linux desktop looks like:Alternatively, if @codetrotter need to do the connecting, you can also setup wire guard to use a dns name, which could be dynamic.
On the VPN side, it would be a static IP though…
I hope to afford racks of beefy bare-metal servers one day that can sit in colocation data centers and that I can host backend services for others on. But for the time being I do not have the funds for that so a couple of small VPSes for my own use it is :)
The difference between wireguard and OpenVPN is that there is no real negotiation between the client and server.
Connecting to OpenVPN can take several seconds as it authenticates you, figured out encryption algorithms, IP and route management. If the network or OpenVPN server hiccup, it drops you and you need to reconnect and renegotiate again.
Wireguard does not do this, the interface comes up regardless if the remote server is up. The client and server key have already been exchanged, the routing and ip are statically configured, so the server can just receive packets without any negotiation.
Clients are identified by their public key, so roaming and ip switches are seamless as well.
There actually is a very tiny amount of negotiation in that protocol has perfect forward secrecy, so the connection re keys every two minutes (hard codes time value).
It's sort of hard to provide any other than "yes/no" to a question like "Is WG stable/reliable", right?
For most uses the answer is probably "yes" but there are use cases (I'm guessing around auth and middleboxes that do not like UDP) where the answer would be "no".
WireGuard is also orders of magnitude more secure than OpenVPN.
This entirely depends on how you configure OpenVPN, which encryption to allow it to support, HMAC, hashes, etc. If you configure it with maximum security, it is equally secure as WireGuard. If you configure it less so, then you allow older clients to connect.
The wireguard has around 4k LOC [0] and you can read and understand it in a weekend (or faster depending on your skill). Also you not only don't have to configure the ciphers, but you actually can't. If any of the chosen defaults isn't considered secure anymore they will be replaced [citation needed]. So even thought the code resides in the linux kernel you could still reasonably well argue that it is indeed on several levels more secure than OpenVPN. Here [1] is the whitepaper for anyone who is interested.
[0] https://git.zx2c4.com/wireguard-linux/tree/drivers/net/wireg...
[1] https://www.wireguard.com/papers/wireguard.pdf
I am really eager to hear details how the VPNs are implementing Wireguard - particularly the address management portion.
Are you tunneling out of AWS, or are you using some AWS node as a wireguard server? Sounds like the former with wireguard interface being the default gateway (I am not an AWS user and am just guessing)... Adding a route for the AWS DNS server IP(s) to use the real network interface for traffic instead of the wireguard interface might work. Something like
Of course, that will make DNS traffic bypass wireguard. If your goal is to hide your DNS queries from AWS except for internal AWS queries, then you will indeed have to run some local resolver that is set up to use the AWS DNS server for AWS-internal queries and some other server (be it a local one or some public one) for everything else.[0]: https://github.com/StreisandEffect/streisand
FD: My employer.
[1]: https://github.com/trailofbits/algo
It looks like the main contributor is (or was very recently) a Signal developer [1], but they have not committed to Streisand since 2018 [2].
[1] https://signal.org/blog/help-iran-reconnect/
[2] https://github.com/StreisandEffect/streisand/graphs/contribu...
* While creating a point to point tunnel is straightforward with Wireguard, it’s the networking part that takes time.
You need to do a bit of networking to set up firewall, access internet and other networks, etc, that may not follow a standard formula depending on your set up.
* Wireguard creates a tunnel. OpenVPN does a lot more, such as authentication, etc. The tunneling part of OpenVPN is much smaller than the whole
* Wireguard doesn’t support TCP
And that, stuff that tailscale adds is superfluous or not appealing?
The complexity rapidly grows as you scale, mostly pertaining to networking.
Now a better question is, how does OpenVPN compare with tailscale?!