It's not as fast as strongswan or wireguard, but it has dynamic mesh routing. If one of my nodes is down, I route through the others automagically, all in user space without having to enable forwarding on any nodes. This is handy when backbone providers are having issues.
what's the logic behind that? are vps providers somehow more trustworthy than ISPs?
Super scary. It would be cool if someone currently working at one of those 50+ government agencies would make an AMA, maybe using a throwaway account.
"required communication service providers (CSPs) to retain UK internet users' "Internet connection records" – which websites were visited but not the particular pages and not the full browsing history – for one year;"
Random small providers from lowendtalk or whatever may not be, but yeah vast majority of hosting providers will be far more trustworthy than any residential ISP.
However, life tends to be much easier if you avoid VPS providers and just get a cheap dedicated server from somebody like OVH instead.
what does one consider to be "cheap" for a dedicated server these days?
2) No lock-in for hosting products, way more competitive hosting market, hosting companies have incentive to provide better service than residential ISPs.
3) Residential ISPs tend to have a far bigger attack surface and less trained staff. I hacked many of the worlds biggest ISPs and hosting companies, the ISPs were always running Solaris from a decade ago.
I should add that my ISP used to mess with my traffic ages ago, then laws changed to prevent that. Those laws were recently changed again, allowing ISP's to start mucking about again. Maybe they won't, but I will stick with my current traffic model.
In my setups, strongswan seems to induce ~25% hit, compared to ~15% with tincd. I’m a noob with strongswan so I’m sure it’s something with my setup.
Tinc on bare metal hardware has pretty low CPU usage at 1 Gbit/s, but not so at 10 Gbit/s.
Highly recommended. Allows you to use any server running SSH as a VPN endpoint with no configuration necessary - you just need a working login.
Also softether is extremely underrated for what it can do.
Usually most VPN tunnels use 1 connection, softether can use 16... So for overseas where you tend to see slow single connection throughout, this can be a game changer. Also its backed by a great University.
Just putting these two out there.
Meshbird project (golang) is also very interesting but not production ready.
Also, I'm a weirdo and run a fair number of services at home with AD authentication. SoftEther has AD support native in the Windows server, which is great, but as far as I can tell there's no way to add two-factor auth.
Also isn't the added lag of a VPN not ideal for playing games?
* gaming hardware is at home and you're playing on a mobile device
* region locked games. there are quite a few on steam.
* LAN games that you wish to play with friends
ZeroTier is actually peer-to-peer, so the added lag isn't as bad as with other vpn solutes such as openvpn
Another use case is our Docker Swarm which runs completely on zerotier, most nodes are on premise but some are in the cloud to make the system publicly accessible.
To me the best feature is the easy setup.
If you have two computers behind NAT, the ZeroTier will help you punch through your NAT and let the computers talk to each other directly. It does it extremely well, and I haven't seen anything like it.
Cool thing is, it can do everything that a normal VPN can. When the other commenters talk about them hosting the 'server'. They're talking about configs, etc. Traffic doesn't usually go through their servers. Just in rare cases where your ISP is really hell bent of preventing you from UDP hole punching.
I personally use it as a replacement for AWS VPN Gateway using a ZT managed route and a couple of VPC route table entries. I detail that setup in my ZeroTier Terraform plugin: https://github.com/cormacrelf/terraform-provider-zerotier
EDIT: Just did. This is amazing.
Highly underrated and too much under the radar afaik
You can run your own controller fir free, and it's also open source iirc, but it's not as nice (no web ui) and you're fully on your own.
If you're behind a restrictive firewall ZeroTier won't be able to punch through it, and will fall back to forwarding packets (encrypted) through ZeroTier servers, Even if a connection could've been made over TCP to the other client (because his firewall supports UPnP or is port forwarded) which creates a tunnel directly between them.
Note that UDP connections are always better for encapsulating TCP, but P2P TCP is better then TCP through an external server with limited bandwidth.
I'm a ZeroTier user though, and i've only encountered this to be a problem once. It's nice to know it'll always work well though.
Configuration & ease of use: ZT > Tinc
Connectivity: Tinc > ZT
I know ZeroTier people are looking into solving this, so this might soon be obsolete information :)
Also tinfoilhats might prefer Tinc considering there's no central service anywhere.
I'm on the laptop, connected to Gb ethernet--- I do work on remote servers (via tinc).
I pull the cable, the lappy's network reconfigure to wifi, tinc re-connects and...
my connections to the remote serves have not skipped a beat. As far as x2go, ssh or VNC, the 'ethernet' it's using is still up; might have lost a couple packets, but that's it.
I just love it.
Transfers of quite large files as well as mysql/redis connexions work amazingly well. CPU gets loaded quite a bit, but overall it is fast (for such a setup) and easy to configure.
* No configuration required for endpoints - any SSH server that you have a login on will work.
* Works on Linux and FreeBSD and OSX
* Tunnels DNS and UDP, etc.
* I have no idea how fast it is.
Absolutely not. My colleagues with Macs are using it on macOS just fine.
> a little more involved to set up
Either TPROXY is the default on Arch Linux, or this is false as well. I just installed sshuttle via pacman and it worked without any additional setup.
We (rsync.net) sponsored work to get UDP functionality working with sshuttle on FreeBSD. It is my understanding that it is committed to FreeBSD ... you might need to wait for 11.2 ?
All incoming tcp traffic is blocked to my VPN, it doesn't respond to ICMP. Pretty much looks like a dead host unless you know there's a VPN. To connect, you need both the key and password. So it's quite secure. I can then ssh to my internal network. Nice way to access my home network without exposing it directly to the net.
* It inherits strong, modern crypto from Trevor Perrin's Noise Protocol Framework.
* It's designed to be extremely simple to configure for the common case.
* It has a microscopic trusted code base --- 4-5000 lines compared with hundreds of thousands for strongSwan --- and the protocol was specifically designed to enable that; for instance, the protocol makes specific allowances to enable implementations without any dynamic allocation.
* It's probably the fastest available VPN.
You can only use it on Linux at the moment, but that will change this year.
WireGuard is so good people at my company spin up Vagrant images on their Macbooks to use it. Check it out:
Benjamin Dowling and Kenny Paterson (a name you might be familiar with) just completed and published a formal analysis of WireGuard; the results are complicated (the eCK model WireGuard was proven under doesn't contemplate separate key exchange and data transport phases) but here's a TLDR from Kenny:
It's so rare and so pleasant to see people treating small code base size and high comprehensibility as a major benefit, rather than a nice-to-have or a negative.
I really like being able to roam with my laptop(s) and have my routing table look exactly the same, as opposed to having a "home network" and then having to explicitly "connect to the vpn" when away from it.
With a quick reading, it looks like the Wireguard protocol wouldn't preclude adding this functionality via userspace forwarding daemons on the better-connected hosts. It's just not there right now, especially in the just-works package tinc provides.
If anyone wants help with their setup, ask here. I can help anyone out with questions. I didn't create the sub, but should be okay.
If you have questions, come to #wireguard on Freenode -- https://kiwiirc.com/client/irc.freenode.net/wireguard -- or ask the mailing list https://lists.zx2c4.com/mailman/listinfo/wireguard -- or just ask me here. We're a friendly bunch.
I don't mind getting help on IRC, but often there are problems that many people come across that can be solved by looking at other people's answers. Reddit is great for that, and StackOverflow hates being tech support and closes questions.
I understand if you want people to use the mailing lists for normal tech support, but I wonder if WireGuard's increasing adoption will bring a lot more people than everyone would like there.
Also the average person would find the use of mailing lists daunting, and tend to not love IRC.
> WireGuard is not yet complete. You should not rely on this code.
So...should we not rely on this code?
If you're comfortable with beta/dev software versions, or using ArchLinux/Debian Sid/other distro with the latest software—there's no reason not to rely on WireGuard today. Otherwise, wait until it arrives at your system, being built into the mainline kernel. Also, I would like it to get audited by independent third-party.
1. There aren't many audit firms qualified to do that audit, and only a subset of the people at most of the qualified firms are themselves qualified.
2. As a result, none of WireGuard's competition has been meaningfully audited --- all of them have been audited, but the projects are pretty much seen as a well that we can keep going back to for more bugs.
The only exception to that rule is probably OpenSSH, which despite the very complex code base has received pretty significant coverage --- not so much from formal audits (it's had some, but they're the same kind as I just described above) but from a decade of close scrutiny.
Against the desire for an audit, I'd also bank:
- The author is a Linux kernel vuln researcher
- The codebase is deliberately tiny
- The protocol was streamlined specifically to make it possible to implement as simply as it was
I know of one (and we're hosting the dude who wrote the Wireguard go implementation this summer (hey Mathias))
I've used this for internal ldap, etc. as it's easier than configuring a certificate authority and using TLS.
But, unfortunately for me, step 0 for Android is to install a new kernel. Whilst other people have already done the hard work to build kernels for my device (Pixel XL), it would create a significant maintenance headache for me to use one of them. I rely on the device manufacturer's security team to release updates to keep my device safe (particularly as I use mobile banking apps on it). But installing a custom kernel would create a large hole in that, and I can't dedicate sufficient time to reviewing the code patches and building the kernel myself. (Of course, better programmers could do that faster, so the trade-off would be easier.)
Do you happen to know whether WireGuard support will be in the mainline kernel in future?
* The underlying SSH protocol dates back into the 1990s, is cryptographically inferior to WireGuard, and does not have an especially strong track record (it's record is similar to that of TLS).
* SSH is opt-in secure for a selection of ports; WireGuard (really, any real VPN) is default secure for all traffic, which is why you use it.
Mostly, though, the reason you'd use a VPN instead of SSH is that VPNs are easier to use. The reason people use SSH instead of VPNs is that most VPNs are hard to set up. That's a big part of what WireGuard fixes.
SSH tunnels are not VPN tunnels. SSH will act as the endpoint for your TCP application and only tunnel the application payload over SSH (TCP). On the other side a new TCP session will be opened over which that payload is sent. So you never do TCP over TCP.
It's more so a proxy than a tunnel and that avoids the real issue, which is nested congestion control. In addition SSH should also be able to do so with less overhead (in bytes) than a VPN (which need to forward the IP and TCP header intact), but I don't know how well SSH takes advantage of that.
SSH tunneling can outperform OpenVPN running in TCP or UDP mode.
Would you say this is true even if you configured openssh to only use the more modern options?
In recent years they've added a chacha20+poly1305 option as well as Curve25519 for key exchange and ed25519 for host and user authentication.
This would seem to bring it up to about an equivalent level cryptogtaphically speaking, in terms of application security, it's definitely more complicated, but it's also one of the most proven pieces of software around and much of that complexity is post-auth. The wireguard site itself pretty clearly states that it hasn't seen much in the way of field testing, though it does look extremely promising. I'll definitely be keeping on eye on it once it's available on more platforms.
SSH supports a wider array of features while having effectively the same cost in implementation and use. The only difference is SSH doesn't support dual IP roaming and IP over UDP. Probably didn't need to start a whole new project when they could have added this to SSH, but then crypto nerds couldn't reinvent the wheel (and SSH probably wouldn't accept the patches).
And this baffles me:
"In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer gN65BkIK..., after being decrypted and authenticated, if its source IP is 10.10.10.230, then it's allowed onto the interface; otherwise it's dropped." "system administrators do not need complicated firewall extensions, such as in the case of IPSec, but rather they can simply match on "is it from this IP? on this interface?", and be assured that it is a secure and authentic packet."
If this is on a dedicated tun/tap interface, shouldn't it only be transmitting secure and authentic packets anyway?? Why is IP traffic on an interface just assumed to be authentic information, if for example you aren't sure what put that packet on that interface? And you still need firewalls, so this duplicates configuration. This is basically an .rhosts file for a VPN.
If WireGuard is as easy to set up as SSH, why not use SSH? Because you want a VPN. But if you want a VPN, don't you want VPN features? WireGuard doesn't have VPN features. So you have to get a real VPN, or use SSH.
To put it another way: if you only want roaming IP and public keys, use WireGuard. For any other use case, you're going to get a real VPN or use SSH.
Certainly not. However, I see how you might think that: the code base and design is deliberately small and readable. It's very far from being a toy, but it aims to be as auditable as a toy would be.
I was confused about this too, but it made sense when I saw it another way. The network/IP address you put there is also added into the routing table, so it routes traffic to that network via the wireguard interface to the specific endpoint using the key associated with the destination address. While it might seem it doesn't have an important place in the receiving side (which I believe it does, especially when you have multiple hosts sharing a key), I feel it vastly simplifies things. You wouldn't have to worry about where a packet is getting routed if you look at the output of `wg` (if you keep the ACL minimal)
When the config is used with wg-quick(which you can setup as a service with systemd), it adds the address to the routing tables automatically and is less work for you to do.
>If WireGuard is as easy to set up as SSH, why not use SSH
Because SSH can't do many things that WireGuard can, and also speed. Especially since I believe it will get merged into the kernel. AFAIK Greg Kroah-Hartman is all for it, so I don't think it'll have any trouble.
Also, I'm interested in what you consider a 'real' VPN is. What do you think this cannot do, compared to say, OpenVPN?
* Certificate management
* VLAN assignment
* LDAP, RADIUS
* Layer 2 bridging
* App deployment
* Host check
* Web UI
* TAP or TUN
* Stats, Reporting
* Scripted extensions
This is no guarantee; he was all for AF_DBUS / kdbus and that never happened.
I think what convinced me at least was the argument that larger codebases like IPSec were merged into the kernel, so why would WireGuard have any trouble?
Of course someone upstream might just decide to say no, and we'll have to live with the kernel module which is just as fast especially since it tends to reach line rate.
When sending; a single interface may have many peers configured. In that case WG needs to be told which peer to tunnel the packet to or it wouldn't know. It's can be viewed as WG internal routing table, in addition to the ordinary IP routing table.
When receiving; although the packet is proven to be from a configured peer, that peer may have used any IP as a source (referring to the encapsulated traffic). Even if you trust all your peers are who they should be this is a potential security risk. For example a peer may spoof its source IP to imitate another peer. You could patch this hole with iptables rules, but this way is more convenient and has a better chance of being correct since it's simpler to configure.
If you don't want any of this I suppose you could just set up multiple WG interfaces instead, configuring only a single peer for each interface and setting AllowedIPs to 0.0.0.0/0. That should give you the same behavior as a what I think you mean by "real VPN".
I agree that minimising the attack surface is the right course of action but on balance the increased risk of several protocols didn't outweigh the convenience given my purpose and temporary nature.
I fell back to global roaming data if I needed to do anything involving logging in, which I avoided doing unless strictly necessary anyway (e.g.: no banking, etc.).
All this is moot, however, as I was citing it for the point at hand rather than suggesting it over a manually set-up install of Wiregard.
What's the story there? Is it being ported to some other platforms, and, which ones?
What's the ETA on a Windows build? I'd love to try it!
is there an expert mode? does this support ED_25519 keys or use open/libressl libs?
Here's an example of the full output from `tinc -n foo init` on a node named `yarp` in Tinc 1.1, which is roughly the same as the command linked to: https://gist.github.com/anonymous/95cd556cfcb66119234ed14255...
"expert" mode would be to just generate those same keypairs with openssl, and configs by hand.
With 1.0, you can only have RSA. With 1.1, you can have RSA and/or ED25519.
Weave Net is completely OSS and usable to create overlay networks between docker nodes or hosts. There's an extensive user guide  and project on Github .
You wouldn't need the commercial service for this sort of usage. Business users buy a subscription to get support for complex networking.
You are right – but SSH is certainly not a network. This technology is useful for folks who need to go down a layer in the stack.
On pretty much all sensible networks I've tested iperf3 on, performance of actual applications sending data was close to its results.
I recall the 1.1 branch improving the protocol in this regard, though it's been a long time since I looked, and I can't vouch for its overall security. I'm surprised it hasn't been officially released yet; the branch was cut over a decade ago! (Also a little annoyed; I contributed improvements to tincctl back then, and they still haven't been released...)
Given that this is not point to point protocol, you cannot just assume that
the author used stock protocol (TLS or IPsec), because there's no such thing.
And unless there was an analysis that confirmed the protocol's strength or
the author is a recognized cryptographer, you cannot assume he did a good job.
nor can you assume he did a bad job..
> hand-rolled protocol riddled with cryptographic errors
It's fine if you know of examples but even better if you can provide them so others benefit.