Hacker News new | past | comments | ask | show | jobs | submit login
WireGuard is now in Linus' tree (zx2c4.com)
982 points by axiomdata316 on Jan 29, 2020 | hide | past | favorite | 278 comments



As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion.

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?

EDIT:

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?

https://lists.zx2c4.com/pipermail/wireguard/2020-January/004...

This is definitely big news!


If you value WireGuard and can spare a few bucks the inventor/maintainer is getting about 1/10th what they publicly ask for to maintain:

https://www.patreon.com/zx2c4


Thanks for posting this; we appreciate it. More generally, donation options for the project are listed here: https://www.wireguard.com/donations/


That ( https://www.wireguard.com/donations/ -- repeating for completeness and exposure) is surely much better link for donations, as some of us would feel limited with a single "Patreon" option.

There are other possibilities for individuals:

"Monthly: GitHub Sponsors, Paypal, Patreon, Liberapay"

"Once: Stripe, Bitcoin, Paypal"

And also "for non-profit foundations and companies."

Thanks!


Any way you can add a "choose your amount" box on patreon, or a lower amount? I try to drop micro-contributions with creators via patreon and $15 is above the current budget for something I don't (yet?) make much use of.


Go to https://www.wireguard.com/donations/ and click on GitHub Sponsors, there's a $5/month option there.


If you work for a company that uses Wireguard, please ask your employer to contribute.


What's the rate of companies doing this?


I have no real idea, but I wouldn't be surprised if it is less than 1%.


I finally emailed my bosses asking our company to give about 100$ a month spread over various projects. I thought not to ask too much as 100$ infinitely much more than 0.

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.


The problem I ran into is that my company will match employee contributions to registered non-profits. Wireguard doesn't seem to be a project under a registered non-profit. My company won't donate to a random Patreon or PayPal link.


There have been numerous threads here on HN about this: donating to people to support open source development does not match up with what companies usually do, so it runs into all sorts of corporate friction. Whereas a monthly or annual support contract is the sort of thing that companies do all the time, and at low dollar amounts it might not require much approval at all.

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 would place a bet on not greater than 0.1%


I do rely on Wireguard for some personal projects and I can spare a few bucks. However the reality is I can't get to $15/month the minimum tier. I rely on thousands of opensource projects. Upstreaming should help my arguments for adoption at work; they wouldn't think twice.


You can support on Patreon for less than the minimum tier. It is just the cut-off over which the rewards (such as stickers here) are given. Support for just $1! He'll still get it!


Thank you, they could make this clearer.


I didn't know this either. I guess that's why many projects have a fake $1 tier with just "the pleasure of knowing you contributed" or something like that as the "reward" for that tier. To let people know that that's still an option.


I agree, I would have signed up for a $1 tier or perhaps $2 but $15 is far too high for the minimum tier. I support the Zig author for $1/mo and hope others would do the same for my open source projects in the future.


Apart from knowing that 15 USD monthly is not a minimum possible donation there, please see other possibilities to donate on the official link for donations (also posted here). Patreon is only one of the options.


Don't let "it's not enough" stop you. Make a one time payment of what you can afford within reason. They don't expect you to put yourself out.


The minimum donation in Bitcoin is probably about US$0.01. Anyway that's what I've paid in transaction fees the last few times I made a donation where I didn't care how long it would take. (They were confirmed within a few hours.) Transaction fees for within-the-hour confirmation are around US$0.20.


If you go to wireguards donation page, you can make a one-time donation too.


it seems there are confusing / multiple sources of income, patreon is only one.

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


Right. We'll stamp a 1.0 on the backports as soon as 5.6 is released and goes through the normal mainline release process. Stamping a 1.0 on the compat backport before mainline would be premature, but doing it the day of is the plan.


> As someone who regularly deals with IPSec in conservative network environments, Wireguard can’t gain broad adoption soon enough, in my opinion.

As someone who does not do heavy NetOps, can you speak more about what's wrong with IPsec?


The over-summarized version is: IPSec is extensible and it's rather tedious to get every implementation to interoperate securely with every other implementation simultaneously (and in the correctly secure way).

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.

https://crypto.stackexchange.com/questions/202/should-we-mac...

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.

https://crypto.stackexchange.com/questions/56354/ipsec-vs-ss...


The 1995 is a little unfair to the current IPsec: The complicated part of the protocol had a compatibility breaking & simplifying major revision in 2005 (IKEv2).

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[1]. 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.

[1] 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


Well, the main advantage of WireGuard then seems to be it doesn't give you any options, so you're less likely to mess it up. Of course there is only one (two?) implementation(s) of it, so "interoperability" as such is not really a thing.

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:

* https://tools.ietf.org/html/rfc5406

(I haven't really used either, so am just spit-balling here.)


Until Cisco (as well as Juniper/AltoPalo/FortiNet/CheckPoint/etc.) implements WG, IPsec will stay with us ;(

I can't deploy WG before that haven't happened... thus time to get WG into RFCs!!!


Most likely it'll drop at the kernel release in April I believe.


Yeah, 5.6 will probably be released on the 28th of March or the 5th of April (depending upon whether Linus feels a -rc8 is needed).


Woud like to use for anything but personal use but cannot use it at work for anything but maybe site to site tunnels.


I’m using WireGuard daily on Linux and iPhone. It’s hard to describe how much better of an experience this is than OpenVPN. Connections are reliable and durable, latency is pretty low, and you can actually understand the software.


I've been using WireGuard on my Android phone for a good while now using a free digital ocean droplet via https://github.com/trailofbits/algo

It's fast. It's easy. You never have to think about it. It just works.


Using myself a Wireguard road warrior install script:

https://github.com/l-n-s/wireguard-install


> using a free digital ocean droplet

I can't seem to find any "free" option on their pricing page. Could you elucidate?


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

Memory sucks.


An engineering approximation to free?


Assuming a spherical VPS in a vacuum...


It’s free given sufficiently small values of 5


I saw this from IBM which doesn't appear to even need a credit card. :0 https://www.ibm.com/cloud/free/ But I haven't checked it out yet.

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 also do this, but with Linode. The only hangup I hit every once in a while is that some services will block access to VPS IP blocks due to spam/malicious traffic. E.g. occasionally I can't get Google search results while on VPN, or Pokemon Go won't connect as they block VPS providers to prevent spoofing.


I see a lot more capchas which is annoying. Also paypal doesn't seem to work most of the time either, which is lame, as I use 2FA for any paypal transaction


Do you have any issues with sites blocking the DO IP addresses? I ran this for a while and a number of sites block connections for coming from a data center.


Yep. DO is industry-blacklisted by the consortium of online content providers who collude on VPN ip-ranges. BBC, Netflix, Sky all are blocking it.


DO is also commonly blacklisted for being slow to deal with network abuse.

I used to build a DDoS mitigation product and we would regularly see 50+ Gbps of inbound attacks originating from DO.


If you want to set up a VPN from a VPS, consider something like LunaHost, it's what I use and I find less issues with it due to being far less known I'd guess.


While noting what the other commenters have said, I don't recall running into any blocks, though I don't visit the sites they mentioned.


I setup WireGuard on my Ubiquiti router and have profiles installed on my phone and Mac.

Extremely convenient for some basic privacy when on a public hotspot.


To anyone interested in running Wireguard on Ubiquiti have a look at https://github.com/dynamist/ansible-role-wireguard-vyatta


I can’t install the official WireGuard on my Macs that are stuck on High Sierra. Love WireGuard for Android and iOS. I think there’s a way to do it on High Sierra with brew but I haven’t dug too deep.


I am considering this to (on a ER4) but since they're are no dedicated ASICs I wonder what the cpu overhead it is for the router.


Nice! Is it one of the UniFi ones?


Have not tried this myself [1]; But I do have a USG, so I might when I have the time.

[1] https://graham.hayes.ie/posts/wireguard-%2B-unifi/


No, it's an EdgeRouter.

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.


It sucks. It doesn't work on Windows reliably. If you're going to do VPN on Ubiquity gear I either install OpenVPN on the EdgeRouter or pass the traffic through to another device to handle the VPN.


Same but Linux and Mac. I have the feeling that online live conferences/meetings are working with Wireguard very good. With OpenVPN I always had the feeling to turn the VPN off to reduce the latency overhead.


I can’t install the official WireGuard on my Macs that are stuck on Sierra. Love WireGuard for Android and iOS. I think there’s a way to do it with brew.


In the same situation, it is indeed in brew.

   brew install wireguard-go wireguard-tools
Pretty painless to use and I haven't experienced any issues.


I’ve been playing with wireguard for the past few days for my personal network. It is likely that I just don’t know what I’m doing yet, but I’ve been having connection issues that I haven’t had with openVPN. One set of issues is from overlapping IP ranges (192.168.1.0/24 is bad news) and another with something I haven’t figured out yet when connecting from work. OpenVPN doesn’t have issues but wireguard does. My thought is the specific port is filtered by my work, but I’m using a rather obscure and high value port.


My greatest misunderstanding before getting it to work was that Wireguard uses the `AllowedIPs` setting both for defining which source IPs to allow, and also for routing traffic back. Means you can't have multiple peers on your machine with the same set of `AllowedIPs` - you need to configure each separately with their exact IP address.

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.


Yep, AllowedIPs should really be called IPs (or PeerIPs).


I've run into both issues, for the first I moved my internal network to a subnet in the 10.0.0.0 range and the second was a DPI firewall at a hotel I stayed at - in the end I have a dual mode setup where if I HAVE to I connect to an OpenVPN endpoint in my network, otherwise it's wireguard all the way.


That’s irritating at best. The whole point of using wireguard, to me, was to move away from openVPN. If I can’t do that then why would I bother hosting a second way to punch through to my network?


Well, it's a lot faster for one, and I suspect it will be allowed through like OpenVPN is once traction is higher.


Same here. It also seems to use a bit less battery than openvpn as well on my phone.


Fantastic news. I deploy WireGuard to provide a private network (mesh) between VPS servers. Each VPS instance has each other vps as peer. So no single source of failure. I run PostgreSQL with Patroni and GlusterFS over this mesh with no issues. When I add or destroy a VPS with Ansible all VPS nodes get an updated config and reload. This way I don't rely on a single cloud provider because I do not use their private network service.


I used to do the same thing, but adding one node meant I had to reprovision all other nodes so each had an updated config file written and reloaded. I decided I want something akin to DHCP, which seems to be worked on here: https://github.com/WireGuard/wg-dynamic It's still WIP though.


I use tinc for this. It does the mesh dynamically so I have a few nodes that are fixed and the others will connect directly or indirectly automatically. I deploy it using puppet and there's no need to update all nodes to add a new one. The cryptography and performance is probably not as good as wireguard but more than good enough for my uses. I think there's been consideration to using wireguard as the transport instead of doing everything in userspace.


Yeah, tinc is great in that scenario. I use it similarly.


This problem has be prevented me all the time from rolling out wireguard. But how dows wg-dynamic help which seems just to be a DHCP on wireguard implementation? You still have to sent every existing node and updated configuration because you provisoned a new one.

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.


While WG is pretty cool, you're starting to describe a simple version of ZeroTier. You can achieve exactly what you say with it, along with multiple networks, chosen/assigned ips, p2p routing, shared keys for authentication to the network, etc. You can put extra filtering or routing rules on top of each of the networks.


Do u maybe know when wireguard would be better than ZeroTier?, been using it for months for p2p(Hamachi like), and for access to the internet like a VPN service. Seems to be most versatile since it works everywhere even behind the deepest nat jungle, and with blazing fast speeds (compared to openvpn haven't tried wireguard yet)


If you have a stable (network) configuration with no roaming machines, and you want as few dependencies as possible, wg sounds perfect. If you want features and don't mind an extra daemon, and don't know what what nats/firewalls are in the way, zerotier rules.


If you want an open source ZeroTier, try Slack's Nebula.

https://github.com/slackhq/nebula


I thought about doing something similar, but with Slack's Nebula or with ZeroTier (v2, which is not released yet). They're specifically designed for this kind of overlay network if I'm not mistaken, taking care of node additions and removals automatically. Nebula with fixed "lighthouses", ZeroTier with a decentralized KV store.

Did you look into these as alternatives?

https://github.com/slackhq/nebula

https://www.zerotier.com/zerotier-2-0-status/


Didn't know about nebula, definitely interesting. I looked into ZeroTier but I believe it has a central control server for connection initiation, and I read some comments about slow connections if I remember correctly.


OP is referring to ZeroTier 2.x which makes it easier to run your own control servers (called root servers in ZT).

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.


That's really interesting. So you essentially implemented a Virtual Private Cloud(VPC) on top of the "PHY" network of your hosts?

Does that mean that all your nodes have to be accessible to the public internet?


In my case yes and yes, but mostly because I spread out over two cloud providers.


But it only needs to be accessible on the port WireGuard uses for communications, and WireGuard also has a nice property where it acts passively for non-wireguard packets.

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.


afaik, both ends can move, they just send packets to the latest IP they received a valid packet from.


Not necessarily, no. All hosts talk to each other on their private (v)NIC.


I'm also doing this with internet-connected vms, but I have closed all ports using Iptables


Did you follow a particular tutorial or do you have any resources you'd recommend to help replicate this setup?

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


I'm considering writing a blog post about it as I documented most steps. Plus having everything in Ansible is more or less a guide / tutorial in itself.


Oh awesome, well if you need someone to test out a draft of the post let me know. I'd be glad to help


Can you talk a bit more about your setup with patroni, postgresql and glusterFS. Are you running postgres on a glusterfs? How well does that work?

From my experience file locking on a distributed filesystem is either not implemented correctly or has piss-poor performance -- and databases use them


I run a distributed Node.js Express app that has a media folder mounted (fuse) across all node instances. GlusterFS runs with replicated volumes. As GlusterFS is not super fast, I use an Nginx cache in front of all media files. (I should probably use a CDN) PostgreSQL does not run over GlusterFS for the reasons you mentioned. For ease of configuration each node has an HAProxy instance that knows where the master PostgreSQL instance lives. Patroni as well as the Node.js (typescript) app uses Consul for leader election.


Is there a way to implement a mesh using only the public IP addresses?


Someone else linked https://tailscale.com in this thread. Could that be similar to what you're looking for?

I haven't dug fully into but definitely will later today.


It seems like it isn't free, I would appreciate not handing my network over to anyone. Since ZeroTier only runs over udp (which can be problematic) and doesn't route over other peers if p2p isn't possible between nodes I've been thinking about building the same admin and ease of deployment around tinc, which can fall back to tcp443 if necessary.


WireGuard is absolutely fabulous. I route all my traffic from a couple servers at home to a small GCP instance (don’t want IP to be public) and I added my laptop to this WireGuard network (although technically a peer) and I can ssh into it remotely.

I’m serving a 1,000,000+ page views a month through WireGuard and can’t say anything less about it it.


Do you set up nginx or haproxy as a reverse proxy to the wireguard network, or something else? Been wondering if there's an easy way to expose an internal service like that. TCP seems easy, but UDP seems much more problematic.


Check out https://tailscale.com/ a mesh VPN built on top of wireguard.


I just learned about tailscale today on twitter. Here's the tweet from the founder https://twitter.com/davidcrawshaw/status/1222203472461926401...

Looks really promising


It does look very nice. It's a shame that it depends on third parties for authentication, and that they have gems like this in their documentation:

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


The idea of a vulnerability in any app I run having access to all my things is quite scary. Status quo is that they at least have to reach the file storing browser cookies before they "become me"; the way Tailscale is talking about their system sounds like fewer barriers.


> That does not mean my applications I access through the VPN are now magically subject to MFA.

Why not? Doesn't the VPN authenticate you via VPN before you can access the apps?


Network authentication is not the same as application authentication.

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)


Another example of a product that looks interesting, but the folks responsible for marketing it make it a pain in the arse.

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.


I don't think there are "folks responsible for marketing". They aren't ready for crotchety customers. They have no funding. https://www.crunchbase.com/organization/tailscale

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.


How does this thing even work? do they host the gateways for you and do the authentication at the start of VPN sessions and generate the wireguard keys for you? so you simply need to connect your networks hosting services and such to their gateways?


I'm doing something similar with a random VPS provider, using and some NAT rules to forward selected ports across the VPN interface. If there's interest, I could write up a more detailed explanation.


If you've followed standard / generic wireguard configuration, then 'client' peers are all able to route to each other via the server on their wireguard-local peer IPs.


Traefik.

Recently they started supporting TCP so now I do both HTTP for websites and TCP for databases


If you need any help, let me know at hn@sdan.cc. I'm going to write a couple blog posts documenting how to do this (because it took me a full brain-wrecking week to figure out how to do this properly).

WireGuard for networking and Traefik for loadbalancing is so easy to do (if you do it correctly).


> because it took me a full brain-wrecking week to figure out how to do this properly

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.


While waiting for your interesting blog post, I have a few questions if you don't mind :-) :

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?)

Thanks! :-)


I would love to see a blog post on this.


Are you using TLS over TCP to route to the DBs?


I think I was doing TLS at one point, but removed it temporarily in an effort to focus on other infrastructure stuff.


Just checked and I'm doing TLS. You can easily do this with Traefik (which I will include in my upcoming post).


I do this too! Works super well, I use haproxy on the cloud side.


I’ve been nothing but happy with WireGuard. Connecting from my iPhone to my home and it works great, it’s fast and reliable. I’m never waiting to connect. Switching between WiFi, mobile, and sleeping go unnoticed.


The On-Demand feature is amazing. It just works and it so smooth.


What software do you use on the iPhone?



Your home has publicly accessible^1 IP address

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


In the US for home connections (cable, fiber, DSL) everybody gets an accessible IP address pretty much -- the worst is that some ports are blocked like port 80 or 25. Phones don't get a dedicated IPv4.


In other parts of the World that didn't get as many IPv4 addresses as the US, the standard for home connections is that you DON'T get a public IP address, you get a private IP address behind carrier grade NAT

And that's really NAT, not a firewall, so nothing is "blocked".

You do get public IPv6 addresses from some ISPs, though.


Finally some truth.


For most people it's dynamic. Mine is dynamic with the PPPoE fibre session.


I have a rpi set up with a minutely cron job to update my domain name to point to home. Works pretty well. At the worst you lose connection for a minute but usually the IP address only changes when the home connection fails which can take more than a minute to reset anyway.


Isn't this what the DynDNS protocol and various daemons are for? Why write your own? :P


That's precisely how they work. You install a client that pings their server. They see if there's an IP address change and switch the A DNS record.

If your DNS provider has an API, this is probably the very first example in the docs.


Why not? It is pretty simple and very fun! My first project in golang was a program that polled for the machine's IP address and updated a AWS Route53 record.


Its not exactly "write your own" I have a single line in my crontab that just uses curl to post to a url and the remote server takes the IP address it got the request from and sets the dns to that.


Though usually on firmware like openwrt the request going out is tied to a particular interface going up (and down) as it should be, so its somewhat more robust and 'correct' than crontab would be.


Dynamic in theory, but for many people the IP is unchanged for a long time. I remember reading an article that said the average length of time between dynamic IP changes tracked by some company was something like seven months, though I can't find it now.

I have cable with a theoretically dynamic DNS but it's changed once in >4 years.


Can you be sure that during 4yrs it never changed >1 even for a short time, maybe hours or days, then reverted back


That's not really a thing. The pools are large-ish; the chances of winding back on the same IP after a change are tiny.


Not speaking for all ISPs worldwide.


Maybe running dynamic DNS client that keeps logs of IP address changes. Do DDNS clients keep logs. Maybe passive DNS would detect changes.

The point of the comment was that cannot just assume it never changed unless monitoring it contiuously.


Well if you don't notice it, for a home vpn, well... you wont notice it.


You can usually get companies to drop the blocked ports though if you call customer service.


"This means you can use it to create inbound network tunnels to computers that don't have a public IP, are behind firewalls or get assigned new IPs frequently."

Sure enough, look what appears on HN front page a few hours later...

https://news.ycombinator.com/item?id=22167627

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
and person B typing

    nc -w1 -vvn [person A home IP address] [port] > file
where port is not one that is blocked, e.g., 80, 25, etc. and is known by both persons.

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.


I have a public IP.


A previous thread about WG had some discussion about obtaining a publicly reachable^1 IP address. No doubt many readers are interested

Can you tell us anything about how you obtained one

1. No ISP firewall blocking unsolicited incoming traffic


I think it's pretty common in the US with the various providers. You get a public IP. I didn't do anything special for that.


Yeah, I don't think I've ever encountered an ISP in the US that didn't give you a public IP. Maybe they exist?

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.


Come to rural western Ohio, where the only non-dial-up options, in some places, are super-high latency satellite and a local "WISP" who NATs their whole Customer base into what appears to be a /29 (your "public" IP assigned by their CPE lands in 10.0.0.0/8).


NAT and double-NAT are common in WISP networks. Also of course most hotels, Starbucks, schools, conferences, airplanes, albeit those are not ISP services. And cellular carriers often NAT.


Almost every ISP will have a firewall of some kind, but in the US this is usually just blocking 25 incoming, sometimes 80 (fios), maybe a few other ports.

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?


"I have run services on port 443 on Optimum and FIOS for years."

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.


Optimum and Fios are two isps in 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.


"No reason to run DNS."

Hmmm, it was a yes or no question. Are you suggesting it work would if you did.


Yes, pretty much since most ISPs do not block UDP port 53.

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.


As someone else pointed out, the issue is mainly NAT not necessarily just "blocked" ports. What works with your ISP may not work with someone else's.


Just to confirm what you are saying.

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.


Does anyone know anything about Wireguard-p2p? It's a tool for automatic management of endpoints and NAT-traversal for wireguard. It was announced on FOSDEM 2018[0]. Main repo[1] is stale, unfortunately.

Some tool that would augment WG with more features a-la Tinc would be awesome.

[0] https://archive.fosdem.org/2018/schedule/event/bulletinboard... [1] https://github.com/manuels/wireguard-p2p


WireGuard is cool and we really like it at our company (a bunch of infosec consultants). The management of it for an even small number (20) of users is a no-go. OpenVPN is ultra reliable and provides legit 2FA options when set up well. I look forward to legit management tools and improvements. For personal use it has been great. Much simpler than OpenVPN for a few (3) users.


The way you're managing WireGuard today is like directly configuring KAME IPSEC. The Linux WireGuard implementation is low-level and, from a systems perspective, unopinionated, which is as it should be.

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.


I'm a big fan of Wireguard, and am using it in a few places, but OpenVPN still has its place - namely if you need a VPN tunnel from behind a firewall that only allows outgoing connections to small number of TCP ports, and no UDP ports.


You're not wrong. OpenVPN can be useful in that case, but in general you shouldn't use TCP as the underlying protocol for other TCP traffic, if you can avoid it. The better solution in this case would be to open a UDP port in the firewall.


My entire point was that in this case, I can not avoid it, it is my only option. Beggars can't be choosers and all that.


I would dearly love to see it make its way into pfsense, at which point I could reasonably execute on that vision. Right now I'm using both OpenVPN and Wireguard, and I'd rather not be.


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


The WireGuard paper is a good start.



I got the feeling that it's presently aimed more as a replacement for IPSEC site-to-site VPN, which is annoying as hell to configure considering the number of implementations and likelihood that one messed up setting will cause an inscrutable problem. Cipher suite incompatibility, subnet export and routing issues, and there's always the delightful fact that it never seems completely clear that you've got a tunnel up and running. I welcome a clear alternative.


Those will be widespread eventually, it's still relatively new, just hitting Linux mainstream kernel dev, so probably 2 or 3 years before tried and proven management tools come out.


If you're wondering what it is:

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.

https://www.wireguard.com/


What does it mean to be "in Linus' tree" if it's already on Linux and everywhere else? Like it will be built in somehow?


Right now, it is not part of the Linux kernel. It is just some random external software that you have you download and compile yourself against the source headers of the kernel you're currently running.

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.


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


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

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.


It will now end up in all Linux distros by default. Instead of having to chase it down and apply a bunch of patches it’s now just a single config option away.


Not all linux kernel modules are in the main sources. Many projects begin outside the main tree and are pulled in later after they have proven themselves and have matured, responded to criticism, etc.


True but now they have to put some small effort into excluding it, rather than a reasonable amount of effort to include it.


Right now Wireguard is using DKMS which is like a external Kernel module which needs to be rebuild on every Kernel update. When WG is already inside the Kernel no dynamic created DKMS are needed anymore.


So like IPSec?

e: I mean that doesn’t suck


A major difference, besides WireGuard's simplicity, is that IPSec is a layer 4 protocol (ESP packets instead of TCP/UDP packets) whereas WireGuard is a layer 5 protocol (runs over UDP), so switches don't choke on it, and so a WireGuard peer doesn't need a public-routable IP address, but can be behind NAT.


IPSec works fine with UDP and NAT.


"fine" with NAT is a bit of an overstatement, I don't think anyone who has seriously interacted with IPSEC would call it anything but a gigantic pain in the ass


I'm not "seriously" interacted, but I have VPN server and I'm using it on all devices in my hope (laptop, PC, phone) which are behind WiFi NAT. They work just fine. I'm using strongswan and IKEv2 on server.


Your NAT behaves and likely has (working) IPSEC ALG stuff, plenty of setups don't.


More likely is that both ends are using IPSec NAT-T (https://tools.ietf.org/html/rfc3947), which has been widely supported for some time. NAT-T encapsulates IP packets inside UDP, with the IKE daemons (usually) as the UDP endpoints.


NAT-T is unfortunately not very reliable.


Try having more than one IKE responser behind same nat gw. Gets tricky to have both/all respond to udp 500...


WireGuard operates at layer 3. The first sentence from the white paper by Jason A.: “ WireGuard is a secure network tunnel, operating at layer 3...”. [1]

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.

References [1] https://www.wireguard.com/papers/wireguard.pdf


The tunnel does not have to encapsulate messages at the same layer as the tunnel itself. Consider this thought experiment: if you send Ethernet frames over WebSockets, what layer is the protocol?

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.


I see what you mean. Specifically in the context of VPNs I’ve always interpreted the layer in terms of the payload that’s being encapsulated - which as far as I understand is IP (L3) packets in Wireguard’s case.

Maybe due to my own ignorance I misunderstood the meaning of derefr’s comment. Apologies if I sounded rude!


No worries, you're fine, just trying to clear up the confusion. I've heard both terms used interchangeably depending on context. _Usually_ as an administrator you care about what's in the tunnel, but _usually_ as a designer you're worried about how the tunnel itself is communicated, so, yeah, confusing :)


The internet does not use OSI.


It never ceases to amaze me how stubbornly educators have clung to the OSI model. It describes a non-Internet protocol stack which was designed in the 1970s, and which was never fully implemented. Attempting to use its layers as an ontology for Internet protocols is doomed to failure, as some of its layers (especially Layer 6) describe components which have no direct equivalent on the Internet.


Layer 6 exists, it’s just that most layer 7 protocols “fix” their layer 6 protocol. E.g., JSON/RPC requires JSON; SOAP requires XML; etc.

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.


OK? The Internet does not use OSI, but it sure was helpful just now as an educational tool for describing that "what layer a VPN operates on" can be confusing. Even if you don't literally use OSI layers, knowing that UDP builds on top of TCP and having a common vernacular to express that is pretty useful. Given that the entire thread was already using specific OSI layers (which have clear mappings to things the Internet does do), starting by saying "the OSI model is not what the Internet actually does" does not seem to be the most productive avenue towards fostering understanding :)


L1 to L4 are just a shorthand way network engineers talk about:

  1. The physical connection and voltage/light levels
  2. Switching and MAC addresses
  3. Routing and IP addresses
  4. TCP/UDP and port numbers
Of course we know it's more complicated than that, but it's still a useful simplification.


this is subject to interpretation


In that it's “leaner, and more secure than IPSec”?


I dont know why you're being downvoted. It is a vpn protocol, just like IPSec, with the main difference being its much simpler, and hence "sucks" less.


Super cool. WG is a such a great tunnel tool. They've told me not to use in production but I've been ignoring that advice for months. My first test was using in as a replacement everywhere I still has stunnel. Then right after it was proved I started using this hammer for everything.

AND! This part is critical: all of my interactions with the team and the community around it have been positive.

Brilliant!


This is great news, and I'm looking forward to giving it a try once it's released as part of the kernel.

I've been using tinc[1] 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?

[1]: https://tinc-vpn.org/


As far as I understand, the killer feature of Tinc is automatic mesh routing. You can add a node to one instance and the information spreads through the network, wireguard doesn't do that.

Also, I heard maintainers were contemplating replacing the protocol with Wireguard.

https://www.tinc-vpn.org/pipermail/tinc/2017-February/004755...


Tinc as a manger of a mesh of Wireguard connections would be incredible.


IPsec also supports this - give certs signed by a mutually tusted CA to all nodes and they can all communicate host-to-host in a full mesh without needing to reconfigure when adding a host etc.


What they mean is that with tinc, you can connect from node A to node Z without A and Z being directly connected. Tinc discovers who is connected to whom and will route through nodes to reach one another dynamically in user space.

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.


Can you please elaborate? As far as I see it, IPsec is encrypting traffic. IKE is for setup of security associations. What part of IPsec would do routing, and in this case: potentially multi-hop mesh routing?


IKE obviously does the key management part, it's part of IPsec in this picture.

There is no separate mesh routing in this scenario, everyone just uses normal internet routing and addressing.


I use WireGuard on OpenBSD and Linux and it is just simply beautiful.

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.


WireGuard is nice but needs 2FA support. Until then it can’t be used in various corporate road warrior scenarios.

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.


What you're describing (authentication/2FA) should be handled by a client application. VPN client software should handle authentication/authorization with the corporate VPN server. Once it's authenticated, it can exchange/generate the public-private keys used for the WireGuard tunnel. The VPN client then installs those keys and starts the tunnel. After that, it's up to the client and server VPN software to handle session timeouts, reconnections, host machine security policies, etc etc. None of that is the job of WireGuard itself.


That’s still just one factor on the tunnel itself, which is the problem. If the keypair is discovered somehow, attackers could connect to your network without 2FA. Or am I missing something?

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


This is awesome news. I’ve been using my self written access server deployed as a docker container at my home for ages now with no problems at all. Wg is a pleasure to use and their apps for iOS and desktop are great. The QR code feature in the mobile app is really good.

I can’t wait for better adoption amongst businesses for corporate VPNs.

https://github.com/Place1/wg-access-server


Glad to see it finally officially accepted. I've been using it on all my devices for over a year now and it's been rock solid. The ease of setup and initial connection speed alone blow any of the alternatives (that I'm aware of, at least) out of the water. Long may it continue!


The only place where it falls shorts is that it doesn't go through as easily as SSL/IPSec on restrictive networks like corporate firewalls, but maybe that will go away when it becomes more common (and hopefully adopted in enterprises).


I've honestly not had a lot of issues with that up until now. Real world it doesn't seem to be blocked by a whole lot of things, except where you only have port 80 and 443 anyway. I've actually seen it work in a lot of places I wouldn't have expected it to, like hotel wifi.


I've seen the same, likely because the DPI boxes haven't yet caught up.


Actually there are workarounds to get Wireguard running over TCP and port 80/443 described here (like udp tunnel). I also wanted to check them out for very restrictive networks in the near future:

https://github.com/StreisandEffect/streisand/issues/1633


Wrote a little post some time ago on how to set it up on linux and use it on android. Super simple.

https://blog.oxplot.com/wireguard-vpn-on-android/


Nice! Any idea what the minimum system requirements are? I'm wondering how cheaply I could run this.


Basically nothing for wireguard itself. I've run it on some seriously underpowered hardware and it seems to have basically no performance impact to speak of. I probably have it set up on around 30 machines presently and have used it in production environments.


This thing should run fine just about anywhere, down to RPi Zero


Just yesterday I was looking at tinc [1] and wireguard was mentioned briefly. I'd like a way to access my home computers via ssh to keep them updated via ansible, even if they are on different networks (parents' laptops, my laptop, my raspberry servers, etc).

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 cannot comment on tinc, but I use WireGuard to do the same thing as you, and it works brilliantly. It was “easy” to set up and use.

I wrote up what I did for my Raspberry PI server that I have at home [0].

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.

[0]: https://qasimk.gitbooks.io/piserver-book/content/personal-vp...


That's good news.

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


Is the Windows client offering better now? I'm still using the old alternative Tunsafe client on Windows because it is more stable than the official client on my laptop (got several bugs with sleep/resume/hibernation/long lived session).

Well... I just tried to install the latest official Windows client and got an error about Wintun missing when activating a tunnel :/


I thought the Wintun driver was bundled with the WireGuard installation but if you need to install it separately I believe you can do it from https://www.wintun.net/

Hope it helps. The Windows client is very stable now.


Thank you for your help. Unfortunately, the files available on wintun.net can't be used.


So,curious here: I'v been reading about how the focus these days is to move networking code to userspace because you can squeeze out more PPS performance,does the fact that WC makes use of kernel code heavily give it a performance disadvantage?


Most of the userspace high-performance networking stuff is still pretty exotic. It requires plenty of tuning, specific network hardware, and sometimes extreme conditions, to be viable. DPDK does not work on the wireless connection I'm using to post this reply, for example (nor any wireless connection for that matter).

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.


You could always use a userspace implementation of WireGuard like https://blog.cloudflare.com/boringtun-userspace-wireguard-ru... . I imagine the advantage of the kernel module is good performance for normal users who are not trying to wring every last bit of performance out of their network setup.


If all networking happens inside kernel, it'll be as fast as possible. People write userspace code because they don't want to put their application into kernel for obvious reasons. And with userspace code it makes sense to move everything into userspace, including network drivers, etc. But it's not a standard configuration and compromises on security.


A polling/batching implementation of WireGuard would be faster than the Linux kernel implementation although it would be much less convenient to use. If WireGuard spends, say, 90% of its time in ChaCha20-Poly1305 (which is already highly optimized) then there's only room for less than 10% speedup.


it could be faster with a hardware chacha20 implementation. if wireguard gets really popular, we might see that eventually. I'd wager a guess that we would get hardware wireguard first though, with fast path acceleration, similar to hardware TLS.


Modern CPUs are pretty close to being ASICs for ARX ciphers like ChaCha. Add, rotate, and XOR all have dedicated die area. Bernstein designed it that way.

Are there any hardware ASIC implementations of ChaCha or are they basically unnecessary?


You're only half right - projects attempting to achieve very high speed networking (packets per second) go to great lengths to remove the traditional syscall per packet that normal linux networking involves.

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.


I don’t know what PPS is, but that is an inaccurate sentiment. Running as a kernel module allows you to achieve higher throughout and lower latency.


You're correct. I don't know why you're downvoted. Anything you can do to get performance with kernel bypass techniques can be done inside the kernel as well.


¯\_(ツ)_/¯ It’s alright. You sometimes get downvoted by the early two people who are offended that I’d dare comment without knowing what PPS is (or something equally offensive).


PPS means Packets Per Second. Here’s a press release from the FD.io project (“Fido”), take it as you will: https://fd.io/latest/singles/kubernetes/


FD.io uses the VPP stack under the hood, which ultimately uses DPDK[1] for the actual IO acceleration.

The reason it's faster is because it's polling your hardware. You spend a lot of cpu time to buy the lower latency.

[1] http://doc.dpdk.org/guides/prog_guide/overview.html


It's possible to write a driver that doesn't use polling - for example https://arxiv.org/pdf/1901.10664.pdf which discusses using vfio though doing so is apparently much harder than polling alone due to the complexity of the vfio interface and that most users care more about maximizing PPS performance at peak vs saving CPU cycles when less busy. Presumably one other option would be to try and tune the CPU to run slower when less demand is expected, and only run at faster peak performance when absolutely required. Also, it sounds like you might want to look at pinning cores to workloads, such that only one of your CPU cores is polling while the rest act as dynamic worker cores and could do other activities. Note that I'm largely speaking theoretically, for my use cases (mostly at home), the incompatibility of user space networking stacks often gets in the way.


> It's possible to write a driver that doesn't use polling

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.


Since a couple of years I've been running iked [0] on my VPSed OpenBSD. It took me around 5 minutes to setup and it "just works" since then with my iPhone and MacOS clients out of the box, not requiring any additional software.

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

[0] https://man.openbsd.org/iked.8


For me it's just easier to get my head around having a new network interface presented rather than this pile of security associations and transform configurations. I can just re-use my firewalling and routing knowledge and do not have to put my mind into IPsec mode to manage this. That aside, I think it's still quite a lot easier to use IPsec tooling when you want something that plays along with certificate based multi-level trust models.


Same question here but using iked on on linux


Wireguard is really, really awesome. I've been using it for a bit now and it almost completely Just Works™. I've only had two issues, one of which is known and the other of which I think is probably my fault somehow.

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.


I just started looking into WireGuard and was disappointed to find out that pfSense has no support for it. I don’t like messing around with packages outside of the pfSense repo, even if it’s kinda supported in FreeBSD.


I run Wireguard on a freebsd server behind pfsense. Works well once you have a nat setup. What is stopping you from going that route?


That's the direction I was headed, yeah. I do like the convenience of managing it all from the firewall web interface, however.


Anyone aware of a VPN provider that offers WireGuard and supports more than 5 simultaneous connections? I've been using Mullvad but the 5 connections limit is starting to feel really restrictive.


I set up a home router that I can connect to through Wireguard from all my devices, and it forwards all traffic to Mullvad. Bonus: I use PiHole on the same instance so all my devices get transparent ad- and tracker blocking


Does mullvad allow five connections at the same time or five different keys overall?


IVPN Pro = 7 connections limit


Very glad to see WireGuard getting more adoption. I've been using it while mobile and traveling and it's been absolutely rock solid.

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.


Mullvad supports WireGuard tunnels, been using it for a couple of months now, pretty solid in any device, in all the regions I tried.


I found the speeds to be lacking quite a bit and it was never completely reliable with both the WireGuard app and the official Android app, which also doesn't support split tunneling or allowing specific apps to bypass the interface. I will revisit when my subscription with current provider expires.


Great news! Definitely going to be changing the landscape of VPN.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: