Now that it’s merged into Linus’s tree, any word on it getting an official release and the “this isn’t production ready, so no CVEs” disclaimer going away?
Further back in the thread, Donenfeld says “Please note that until Linux 5.6 is released, this snapshot is a
snapshot rather than a secure final release.”, so perhaps real soon now?
This is definitely big news!
There are other possibilities for individuals:
"Monthly: GitHub Sponsors, Paypal, Patreon, Liberapay"
"Once: Stripe, Bitcoin, Paypal"
And also "for non-profit foundations and companies."
We're not a very big company, could easily afford 1k a month though, but then it becomes an actual sum that's harder to motivate as we're mainly working with MS products.
Unfortunately it is up to open source developers themselves to set their business model, and many don't seem to like (or want to do the work of) setting up overtly commercial relationships like support contracts.
I don't know if it's fair to say he's not making what he asks for.. or basing a 1/10th claim without knowing how much he gets from other sources. (Bronze/gold partnerships GitHub donations, stripe, crypto donations, and some others).
As someone who does not do heavy NetOps, can you speak more about what's wrong with IPsec?
While using IPSec between supported devices, in an ideally configured setup, yield slight but real benefits with respect to attack resistance, a practical comparison of the difficulty involved and possible configuration mistakes makes other solutions more robust and less likely to be used incorrectly.
This discussion covers most of the high level points, however it doesn't consider that Wireguard being adopted in 2020 and not 1995 means we've got 25 more years of public cryptography research and far more relevant defaults to include as the base of the standard.
The answer here also provides some of the pitfalls of IPSec being more of a 'build your own crypto setup' than an off the shelf drop in solution.
I think the main reason of the less than polished IPsec experience is that operating systems didn't really promote it as a out of the box working feature, but instead just offered APIs that were mainly used by corporate VPN product vendors who didn't really want interoperation except as a checkbox feature. The early interop hassles are just a symptom of lack of testing and effort - when vendors are motivated and actually everyone's implementation of a standardised protocol to interoperate they organise interoperation testing events etc and make sure their products ship with configurations that actually do interoperate in the real world.
Your linked StackOverflow answer muddies the water too much - IKE was always the official keying protocol. Yes you can use lower level IPsec parts without it with manual keying if you are a masochist or have a very simple topology (like a 2-host tunnel with static IPs), but the other keying methods are fringe or academic.
 IKE was finished later than the lower level parts of IPsec, technically there was a period in the beginning when it didn't exist and you had only manual key setup
IPsec can be/is complicated because we learnt as we went with it, but given the correct settings, it can be/is secure.
So just like with SSL/TLS, it may be necessary to 'simply' introduce new RFCs to deprecate the Bad Way(s) of configuring it. Doing a quick search, there's a BCP RFC:
(I haven't really used either, so am just spit-balling here.)
I can't deploy WG before that haven't happened... thus time to get WG into RFCs!!!
It's fast. It's easy. You never have to think about it. It just works.
I can't seem to find any "free" option on their pricing page. Could you elucidate?
I sure can.
It looks like I'm using the $5/month 1GB/1CPU/25GB droplet running Ubuntu 18 LTS, and just imagined that I was using a free one.
I think that Azure and GCE have better free tiers than AWS, but I'm guessing the bandwidth metering may work against a vpn use.
I used to build a DDoS mitigation product and we would regularly see 50+ Gbps of inbound attacks originating from DO.
Extremely convenient for some basic privacy when on a public hotspot.
I'm not sure if UniFi equipment supports the run times necessary for WireGuard.
UniFi has its own VPN type of software. Not sure what it is or how secure it is, though.
brew install wireguard-go wireguard-tools
Since WireGuard doesn't do NAT hole punching etc, you'd most likely need to connect from work to your network, and use the `PersistentKeepalive` setting. You can't initiate the connection the other way round.
An overlay network on top of wireguard would be really nice. For example you are running a wireguard network on 169.254.0.0/16. So every peer which is assigned an ip address within this range is by configuration of the network allowed to forward packets to another peer in the 169.254.0.0/16 network. So the only things needed to be implemented would be:
* an internal routing system to forward packets on some way to the destination
* a concept on how peers are found and how they build a secure channel (pre-shared key?)
Edit: A better way would be to have multiple shared secrets for every server. So you could basically assign roles to every server. So if a server has the keys "db" and "middleware" he can communicate with every same in the network for forwarding but the final destination can only be a server which has also one of the keys "db" od "middleware". Maybe such a server would have 2 virtual ips within the subnet, one for it's role for db and for middleware.
Did you look into these as alternatives?
Any connection flakiness is probably due to NAT or firewall issues and is going to occur in any P2P network layer since they all use a toolbox of common techniques such as UDP hole punching.
Does that mean that all your nodes have to be accessible to the public internet?
So someone on the internet doesn't necessarily know the node is reachable from the internet if they try and scan it for example.
Edit: IIRC only one end of the connection needs a stable endpoint as well. IIRC WireGuard supports mobility (changing IP addresses) for one end of the connection.
I've been interested in setting up a private network similar to what you describe and your comment has piqued my interest in finally building it
From my experience file locking on a distributed filesystem is either not implemented correctly or has piss-poor performance -- and databases use them
I haven't dug fully into but definitely will later today.
I’m serving a 1,000,000+ page views a month through WireGuard and can’t say anything less about it it.
Looks really promising
> No app-level integration or reconfiguration is required, because security is built into the network itself. If you configure your network to require Tailscale, every one of your internal services will be subject to multi-factor authentication.
Which is simply not true. I've had 2FA for my Cisco AnyConnect VPN for years. That does not mean my applications I access through the VPN are now magically subject to MFA.
Maybe in time this may end up being viable for me, and maybe it already is for other people. For now, I'd rather my VPN didn't depend on Google, Microsoft, Okta, etc.
Why not? Doesn't the VPN authenticate you via VPN before you can access the apps?
If I plug a cable into your LAN, I am not subject to MFA to login to a server on your LAN.
If you have a lock on the network port that requires me to type in a PIN code and stick in a key to unlock, and expose the port, that then results in MFA to connect to your network. Your applications behind your network remain without MFA.
MFA VPN is essentially the same thing as the above, but for remote access to the LAN. Applications should still be properly secured.
I suppose it could be argued that this provides a client-side agent to authenticate the end user as well (mumble mumble 802.1x), and if so, then it's arguable whether or not you need another layer of authentication on the application, or if this qualifies as SSO to authenticate you to everything you have access to in the network (so passwordless login to servers, desktops, webapps, etc)
This looks like it solves a problem I have. Looks like it might be a commercial product (mentions of Okta and "get started for free"), but I can't find out any more information without signing up which I don't want to do if it doesn't support the configuration I want or is more expensive than my budget for such things.
They want early adopters (their friends) to play with their prototype, and they don't want to commit to pricing and long term support before they know what they can build and if it will work and how much it costs.
Recently they started supporting TCP so now I do both HTTP for websites and TCP for databases
WireGuard for networking and Traefik for loadbalancing is so easy to do (if you do it correctly).
I would appreciate a guide as well, really for anything Wireguard adjacent. I tried to get a simple client / server configuration with forwarding set up about 2 months ago and gave up after 5 hours of blood, sweat, and tears. Disclaimer: the server was an OPNsense based router. I probably could have done it between two Linux servers from the terminal. I was using a guide I found online, but it didn't help, which may have been due to using OPNsense, I'm not sure.
OpenVPN may be more complicated in theory, but one really nice thing about it is that there are tools that make setting up a configuration trivial on just about any device that supports it. Not true for Wireguard (yet). I'm sure it will get there eventually.
So your setup is:
* GCP Instance (i.e. VM on the Google infrastructure).
- Traefik running on this instance.
* GCP conntected to Wireguard
=> Is Wireguard run on a router/firewall, or directly
on the DB, HTTP servers? If router, would be
interesting to know which type of router?
* Behind Wireguard: Two servers (DB and HTTP) + Laptop
* You SSH to the two Servers (directly or via the GCP?)
Or you are using a third party-controlled server with direct internet access to make home IP accessible
1. No ISP firewall blocking unsolicited incoming traffic
Do you configure WG to use persistent keepalives
And that's really NAT, not a firewall, so nothing is "blocked".
You do get public IPv6 addresses from some ISPs, though.
If your DNS provider has an API, this is probably the very first example in the docs.
I have cable with a theoretically dynamic DNS but it's changed once in >4 years.
The point of the comment was that cannot just assume it never changed unless monitoring it contiuously.
Sure enough, look what appears on HN front page a few hours later...
People's home public IP addresses are not universally reachable/accessible^1 from the internet. It varies.
What does "reachable/accessible" mean. It means that transferring a file would be as easy as person A typing something like
nc -lnp [port] [person A home IP adddress] < file
nc -w1 -vvn [person A home IP address] [port] > file
Regardless of what anyone says in an HN comment, in the real world, people at home are sometimes behind firewalls, or other software that performs NAT, that are running on computers that do not belong to them and are not under their control.
That's why WG has persistent keepalives. No one answered that question.
Can you tell us anything about how you obtained one
You only get one, so you typically NAT everything, port 25 is blocked and often port 80 is as well, but that's about it.
I have run services on port 443 on Optimum and FiOS for years.
IP addresses don’t change frequently. Usually what happens is there will be some maintenance and you’ll end up with a new IP because you lost the lease in the interim. If you keep your equipment on though you can have the same reachable IP address for years.
I use a dynamic DNS service so this is rarely a big deal.
Not sure why this is so hard for you to grasp. You keep arguing, for what reason?
What is Optimum, FIOS.
WG does not work over TCP.
Try running a UDP-only DNS server from home on some random port. If you know the port can you reach it via UDP from the internet.
A TCP service listening on port 443 on an ISP customer's IP address in the US might be reachable from the internet. However, this topic is neither TCP nor port 443 nor is it restricted to just the US.
> Try running a UDP-only DNS server from home on some random port.
No reason to run DNS.
However, I run openvpn udp between three houses (fios, Comcast, cablevision) for nearly 15 years. It’s pretty common, works fine.
Again in the US... cable, fiber and dsl internet service comes with a public mostly unfiltered IPv4 address, the address is dynamic but in practice it is extremely stable.
End of story.
No idea why you’re acting like such an imbecilic tool in this thread. The whole time I have mentioned that this is the case for major US “landline” ISPs. Yes there are plenty of counterexamples, not sure what point you’re trying to prove.
Hmmm, it was a yes or no question. Are you suggesting it work would if you did.
I have no reason to run DNS on a home internet connection. What would a sane use case be? They don’t block it because it would be stupid to use it anyway.
Ports that are typically blocked include 67, 139, 161, 520, 547, etc.. ie dhcp, rip, smb, snmp... none of them are any great loss to those that want to run a vpn.
Running a VPN or ssh service is another story and it works fine both TCP and UDP.
I had a Time Warner cable modem for 15 years and the IP address would only change after a sustained power outage. Usually had the same IP for a year.
My AT&T Fiber IP address has not changed in 2 years and that is even after 2 power outages of about 12 hours.
Some tool that would augment WG with more features a-la Tinc would be awesome.
Getting a secure transport integrated safely into the kernel shouldn't be rocket surgery, but it is. That part is done. Getting IdP-managed WireGuard is not rocket surgery, and lots of teams will presumably do it. Those teams, by the way, stand to make a lot more money than Jason will off WireGuard, which is a very good reason to donate.
Nobody who can reasonably avoid it should be using OpenVPN anymore. I get that it's burrowed far into some organizations and am not OpenVPN-shaming anyone. But WireGuard is leagues beyond OpenVPN in terms of nuts-and-bolts protocol and implementation security.
Could you recommend anything to read that explains this in more detail, please?
WireGuard® is an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography. It aims to be faster, simpler, leaner, and more useful than IPsec, while avoiding the massive headache. It intends to be considerably more performant than OpenVPN. WireGuard is designed as a general purpose VPN for running on embedded interfaces and super computers alike, fit for many different circumstances. Initially released for the Linux kernel, it is now cross-platform (Windows, macOS, BSD, iOS, Android) and widely deployable.
It got merged into the net-next tree, which meant it has been approved by the maintainer of the Linux kernel net branch to be included into the kernel. Linus has now pulled it from net-next into his own tree, which means it'll be included in the next release of the Linux kernel.
As far as that means as an end user, it means that you no longer need to recompile your wireguard module every time there's a kernel update, as now it will be handled by your distro.
That said, given that Wireguard is packaged nicely already for most distros, the end effect for you is really pretty little, as you're probably unaware of all of this complexity that's going on right now, as it mostly just works.
That's not the important point.
The point being, when merged as part of the kernel officially, you know it will get more support and eyes for stability and development power as the kernel wouldn't want to ship anything that's at some unstable state.
So you can expect long term usage and maybe RedHat might pick it up as its official VPN solution instead of libreswan some day.
This is a rather idealistic view on kernel development.
But it is true that when wireguard is “ready” this could very well result in a bit more support as larger orgs will be more willing to start using wireguard.
e: I mean that doesn’t suck
Regardless of the layer, in a few words WireGuard is a simple encrypted tunnel over UDP. Since it’s UDP - there’s no guarantee all packets will be delivered, BUT - what WireGuard places emphasis on is all packets delivered from the WireGuard interface will be authenticated and encrypted. Similarity if packets are received from a particular peer, replies to that IP address will be guaranteed to go to that same peer.
The best feature of all imho is OpenSSH inspired authentication - makes configuring server/peers really straightforward.
My understanding is the Wireguard messages are IP (L3) but the protocol messages itself are UDP (L4) and it seems reasonable to describe Wireguard as a session layer over UDP given how much state and connection information it maintains.
Maybe due to my own ignorance I misunderstood the meaning of derefr’s comment. Apologies if I sounded rude!
But Layer 6 is where the difference lies between ASN.1’s representational encodings—DER, BER, XER, etc. You can switch out this “presentation layer” encoding without either your application layer caring (it just sees an ASN.1 codec library) or your transport layer caring (it’s just transporting an opaque octet-stream payload document.)
One might also describe Avro, Parquet, etc. as “presentation formats”—they all have canonical input ADTs, but multiple possible wire encodings depending on the schema supplied at encode time. But all such schemas decode back to the same input ADT.
1. The physical connection and voltage/light levels
2. Switching and MAC addresses
3. Routing and IP addresses
4. TCP/UDP and port numbers
AND! This part is critical: all of my interactions with the team and the community around it have been positive.
I've been using tinc for several years now, and it's been very simple to configure and use. Similarly to WG, it can tunnel over UDP, but also over TCP, supports router or switch modes, NAT traversal, etc. It's a great project, but not very popular and I'm concerned about its maintenance and security issues moving forward.
To someone who's used both projects: can WG today be a drop-in replacement for tinc?
Also, I heard maintainers were contemplating replacing the protocol with Wireguard.
IPSec by itself can not do this without adding very complex route statements on each node and enabling packet forwarding. Tinc operates in user space and does not require kernel packet forwarding or any destination node specific route statements.
There is no separate mesh routing in this scenario, everyone just uses normal internet routing and addressing.
THANK YOU Jason for writing it and to everyone else who has contributed code, testing, money, whatever.
I believe WireGuard will become the most widely used VPN above IPsec and OpenVPN. There will still be use cases for them (especially IPsec) but both will lose marketshare dramatically.
Also until Cisco, Juniper, etc add WireGuard support and enough devices are deployed with it, IPsec will remain the corporate tool of choice when connecting between different organisations. Within the same org, where you have greater control of the equipment used, WireGuard is a bit more feasible.
So what software can I use now to make 2FA work with WireGuard that’s simple to use - as simple as OpenVPN (cert+user/pass is trivial in OpenVPN and supported in their clients).
I can’t wait for better adoption amongst businesses for corporate VPNs.
Does anyone with more knowledge care to comment on security issues with tinc vs wireguard?
Too bad that you need to use an external droplet for discovering the hosts with this one :(
1 - http://tinc-vpn.org/
I wrote up what I did for my Raspberry PI server that I have at home .
The only other component that may be necessary is Dynamic DNS if you have a dynamic home IP address, or at the very least a way to find out your home IP at any time.
I have been using wireguard via telegram and discord. Bot generates a config, whip it up and send generated QR code/file/instructions. It changes the DNS to the proxy pihole so whenever I connect to vpn, most ads stop bothering me.
It's been great because I can easily give access to others via the bot too. They only need to scan the QR code or download the file, import it in the official app and it works. :D
Well... I just tried to install the latest official Windows client and got an error about Wintun missing when activating a tunnel :/
Hope it helps. The Windows client is very stable now.
Meanwhile, if you're not doing that: Wireguard can avoid lots of syscall and copying overhead plus some magic CPU register overhead by being in the kernel. Hence this almost certainly makes wg faster on the net because it can't pick and choose what environments it runs in.
Are there any hardware ASIC implementations of ChaCha or are they basically unnecessary?
One approach to this is to move everything into userspace and take the kernel out of it completely. Another approach used by some projects is to put everything into the kernel and take userspace out of it completely. Either of these approaches remove syscalls.
The kernel isn't an inherently slower place (in some cases it can be faster as you have more control), it is having your network stack split across the kernel/userspace boundary that is slow.
The reason it's faster is because it's polling your hardware. You spend a lot of cpu time to buy the lower latency.
Yup, definitely possible. It just doesn't give the PPS numbers as polling does. The project you linked to is really cool, but it is an academic project. It's not trying to compete with DPDK or anything.
IO is one of those things in computer science that forces us to make trade ofs. What is more important to you? Raw throughput? Latency? Overall resource usage? You can't optimize all three.
> it sounds like you might want to look at pinning cores to workloads, such that only one of your CPU cores is polling
Correct again. It may take more than one cpu (DPDK is commercial software running on 88+ cpu systems) but cpu pinning is definitely the recommended way to go. In the spirit of spending CPU to buy IO speed, dedicating physical cores to the task always gives you the best bang for your buck.
But since WG is getting so high praise here, I'm now interested what are WG advantages and what does WG have to justify the effort to move away from iked and install/setup the client software everywhere?
I'm certainly going to find out and test it myself, but would really appreciate just a quick answer/explanation
The first is that for some reason I sometimes need to ping machine B from A in order to get to C via B (in my case B sits in a VPS, while A is a laptop and C is a desktop).
The other is that I would love to be able to connect directly over the LAN from A to C and vice versa, only going via B when A is mobile. I'm pretty sure that I could fix this with more IPv6 addresses and routing tables, but so far no joy.
OpenWrt router back at home, multiple Android devices and Fedora machines connecting back that just work seamlessly between different networks. It's been such a treat to use and watch and help it mature.
Just need more popular VPN providers to start supporting it -- NordVPN and PIA have provided "support" for it, and Nord allows using it as "NordLynx" on their Linux app.