[HN Gopher] WireGuard 1.0 for Linux 5.6
___________________________________________________________________
WireGuard 1.0 for Linux 5.6
Author : zx2c4
Score : 436 points
Date : 2020-03-30 02:46 UTC (20 hours ago)
(HTM) web link (lists.zx2c4.com)
(TXT) w3m dump (lists.zx2c4.com)
| 2OEH8eoCRo0 wrote:
| This is good to hear. There is a lot of trendy junk that people
| seem to want in the linux kernel. I've been waiting for WireGuard
| to prove itself before I give it a shot.
| dang wrote:
| https://arstechnica.com/gadgets/2020/03/wireguard-vpn-makes-...
| is a related article.
|
| (Via https://news.ycombinator.com/item?id=22731279, but no
| comments there.)
| newscracker wrote:
| For anyone wanting to try it, WireGuard with Algo VPN [1] to set
| it up on a server is a great combination. I found it quite easy
| to setup and use.
|
| Algo has built-in support for various cloud providers, where,
| when you run it from, day, your desktop, it can setup the VPN
| server for you based on answers to some questions (with sensible
| defaults) and some information on connecting to the provider
| (like an API key, for example). You also get QR code images that
| you can use to install a VPN profile on your phone.
|
| You can also run Algo from within a server and have it setup the
| VPN for you.
|
| [1]: https://github.com/trailofbits/algo
| wisam wrote:
| Just be careful when setting up Algo VPN.
|
| Its secure defaults will probably block all other services
| you're running on your server and render them inaccessible.
|
| You might even end up not being able to ssh to your server if
| you choose not to let Algo set up ssh configurations (because
| you have your own).
|
| I would say install Algo on a dedicated droplet or backup your
| VPS before setting it up.
| libria wrote:
| > I would say install Algo on a dedicated droplet or backup
| your VPS before setting it up.
|
| droplet == host?
| jszymborski wrote:
| VPS/VM offered by Digital Ocean
| apawloski wrote:
| This is the intended behavior/deployment model of Algo (as a
| dedicated VPN server on a dedicated VM).
|
| If you are running other co-resident services and need more
| lenient firewall rules / system configuration, you should
| consider another option.
| Diederich wrote:
| Second this: I've been using Algo+Wireguard with digital ocean
| for the past year or so, and it's been seamless and excellent.
| Very easy to setup.
| rubenbe wrote:
| Does the VPS have unencrypted access to the VPN? It's something
| I would want to avoid. (A VPS is a prime candidate to be
| compromised)
| wolrah wrote:
| In the scenario proposed the VPS is the VPN endpoint. It's an
| alternative to commercial VPN services or hosting something
| on your own systems.
|
| Whether that fits your security scenario is up to you.
|
| If your primary goal is to get from an untrusted network (say
| public wifi) to a trusted network then a VPS with a provider
| you trust is great.
| tw04 wrote:
| If you're subject to state level actors attacking you, a VPS
| is probably the least of your worries. If you're just trying
| to make sure some kiddiot in a coffee shop isn't doing mass
| collections, a VPS is perfectly secure.
| somehnguy wrote:
| Linode has been compromised how many times now?
|
| I don't think considering a VPS insecure is really that far
| fetched.
| derefr wrote:
| The bad actors who want to steal your passwords and
| credit-card data, and the state actors who want to spy on
| Persons of Interest, don't know each-other or talk to
| one-another. A VPS provider being compromised _by a
| series of private individuals_ doesn 't imply that your
| VPN running on such a service is going to be sneakily
| MITMed, because there's no obvious profit motive in doing
| so (unless you're a very publicly super-rich person who
| is also very publicly using the service, and it's very
| obvious how to blackmail you if you could just get data
| exfiltration via that service. Like Jeff Bezos with
| WhatsApp.)
|
| Instead, you might get whatever elements of your identity
| stolen that Linode's account-management servers have
| possession of; or your VPS instance might become host to
| crypto-mining malware and then get shut down by Linode
| (which will come at no cost to you, other than the
| downtime.) But neither of these things will really focus
| on _you_ personally. They 're automated bulk attacks.
| ac29 wrote:
| A couple times, nearly a decade ago.
| https://en.wikipedia.org/wiki/Linode#Security_incidents
|
| If you dont want to trust them now, in 2020, don't - they
| aren't the only provider of VMs. I'd imagine the big
| cloud providers (AWS/GCP/Azure) have fairly significant
| security teams - has there ever been a disclosure of
| customer VMs being compromised on any of them?
| bawolff wrote:
| That's kind of a tautology. If you assume the system is
| insecure, then yes its going to be insecure with that
| assumption. This is going to be true of any VPN system,
| so i think its an unfair criticism to level against this
| particular VPN setup.
|
| If you want to be secure against local adversaries, use
| TOR.
| zeveb wrote:
| > That's kind of a tautology.
|
| More specifically, it's begging the question. The actual
| definition of begging the question, not the mistaken
| usage.
|
| To beg the question is to assume the thing which is to be
| proven.
| kryogen1c wrote:
| this is my favorite extremely annoying but massively
| useful "acktually..."
|
| begging the question as a logical fallacy is prevalent in
| politics and media representations, and is a
| differentiatior between reasoned debate and talking head
| nonsense.
|
| Polictician 1: UBI! P2: free market competition! P1: why
| do you want poor people to suffer, P2?!
|
| P2: 2nd amendment! P1: Ban firearms! P2: why do you want
| americans to be put in danger, P1?!
|
| both of these are begging the question
| chrisweekly wrote:
| +1 for good points.
|
| Also, ty for "kiddiot" (much better than "script kiddie"
| term)
| kitotik wrote:
| Aka "skids"
| SkyMarshal wrote:
| Or "skiddie".
| fulafel wrote:
| Yes.
| fraidy-cat wrote:
| > Does the VPS have unencrypted access to the VPN?
|
| Not quite sure what you are asking about in this first part
| of your comment, but I'll get back to that.
|
| Firstly though, I think I might see what you are getting at,
| but correct me if I am misunderstanding what you are saying.
|
| > It's something I would want to avoid. (A VPS is a prime
| candidate to be compromised)
|
| So, I think that what you are saying here is that by passing
| all of your traffic through a VPS that you set up yourself,
| you are increasing the attack surface that others have
| against you in a specific and potentially particularly
| dangerous way.
|
| And to some extent I agree with that.
|
| Unlike what the first one of the other commenters said in
| their response to you, I think you are not talking about
| state level actors. I also think that you are not talking
| about the VPS provider wanting to look at your traffic. I
| think what you are pointing out is that:
|
| 1. Keeping the operating system and services that are running
| on the VPS up to date with patches will be the responsibility
| of the person that is renting the VPS.
|
| 2. The VPS is more or less permanently connected directly to
| the public Internet. As such, it is under constant "fire"
| from automated attacks. (Anyone who has run a VPS or other
| server or device directly connected to the public Internet
| knows this to be true. It doesn't matter how big or small you
| are, or who you are.)
|
| 3. As a consequence of points 1 and 2, failure to keep the OS
| and services patched could result in compromise of your VPS.
| (Most likely the purpose of the compromise is that the
| attackers want to use the machine for things like having it
| participate in DDoS attacks, sending spam, compromising other
| actually valuable targets, or mining crypto currency. But it
| can indeed not be ruled out that they would potentially
| listen in on the traffic you are passing through your VPN on
| it also. And even if most of the criminals don't care about
| the VPNs running on the compromised servers today, they might
| in the future. Especially if there is a common wide-spread
| VPN configuration that a lot of the compromised servers are
| all running, so that they could mass-intercept all of the
| data on all of those compromised servers with little
| work/effort on their part.)
|
| If that is what you mean then I agree that it might be a
| problem.
|
| Compared to professional VPN providers, any individual
| renting a VPS is probably comparatively less skilled at
| keeping their VPS secure than the VPN provider is at keeping
| the VPN service secure from _external_ attackers. And even if
| someone has all of the skill that they need to securely
| configuring their VPS and keeping it up to date with patches,
| they still have far less time on their hand available for
| auditing, monitoring, and all of that, than all of the people
| that are being paid to take care of those things at a large
| scale VPN provider with many employees.
|
| So again, that's another point that I agree with you about if
| that is also what you mean.
|
| At the same time, however, it should also be pointed out that
| it can be really hard to know who the people behind any
| particular VPN service provider is. But the same argument
| applies against a lot of the VPS providers out there.
|
| Any random VPN service provider could claim that they have a
| big team, that the service they are offering is secure, and
| that they don't keep logs and don't record traffic. But at
| the end of the day for most of them, you have nothing more
| than their word to go on.
|
| The same applies to random VPS providers though. With most of
| them you have no idea about who they are and what they are
| actually spending their time doing.
|
| Sorry my comment is getting real long and yet there is more
| that I would like to touch on.
|
| For example, another point in favour of the argument that I
| think you are making is that _potentially_ , VPN service
| providers are monitoring their whole networks of hosts
| specifically for attacks that seek to intercept the traffic
| of their customers, in addition to the regular type of
| attacks that all hosts on the internet are subject to.
|
| Whereas with a VPS provider, I imagine that they are
| primarily monitoring for the regular type of attacks
| mentioned before. VPS providers will notice, and shutdown
| VPSes that have been compromised if those compromised
| machines are participating in DDoS attacks on other hosts,
| sending spam, or burning too many CPU cycles as a result of
| cryptocurrency mining malware having infected them. But
| unless notified by one of their customer about the specific
| type of attack where data is being exfiltrated or tampered
| with on an infected VPS itself, most VPS providers would be
| unlikely to notice such a type of attack I think, and
| furthermore I think this is natural to expect. After all,
| when you rent a VPS, you are specifically paying the company
| for the privilege of you being in charge of what that VPS is
| doing, and for them to largely stay out of and away from your
| VPS itself, no? At least, that's the way that I think about
| it. As long as the VPSes are not consuming excessive amounts
| of resources and not being disruptive or malicious towards
| external hosts, I think both the VPS companies and their
| customers expect the VPS company to not interfere with what
| the VPS itself is doing, and to not be surveilling the
| processes, disk and memory of the VPSes. It's a virtual
| _private_ server after all, right?
|
| So that's another point for the argument I think you are
| trying to make.
|
| But I don't see VPN service providers as being much safer as
| a whole. I think it is highly probable that among _all of the
| companies_ that provide VPN services, it is likely that a
| significant portion of them are straight up malicious. By
| that I mean, they say they don 't look at your traffic and
| they say they don't keep logs. But for all we know, and given
| the fact that many forms of cyber crime is profitable enough
| that criminals are engaging in it, I think it is reasonable
| to suspect that quite a few of the providers are mining your
| data or worse.
|
| This brings me back to the first part of your comment, which
| has me confused about what you mean.
|
| > Does the VPS have unencrypted access to the VPN?
|
| Confused because yes, this is how any VPN works. You get an
| encrypted link between your device and the other end of the
| VPN connection. The VPN connection extends only to the VPN
| server/gateway that you connected to in the first place, no
| matter if that is some VPN server you are running on a VPS
| yourself, or if you are paying a VPN service provider for it.
|
| The extent to which your data is encrypted or not all the way
| to the final destination will be entirely dependent on what
| kinds of traffic your device itself is sending in the first
| place.
|
| If your device is tunneling unencrypted traffic inside of the
| VPN connection, then unencrypted traffic will be what comes
| out at the other end where the VPN tunnel is terminated.
| There is no way around that. The only thing you can do, is to
| ensure that your device does not try to send that kind of
| data through the VPN in the first place, if you are concerned
| about said traffic being visible at the other end of the VPN
| tunnel.
| rubenbe wrote:
| Thanks for the elaborate answer on my, in hindsight, not
| very clear question.
|
| The use case I was referring too is where the VPN is
| between e.g. your corporate network and your pc when
| working from home. In this case the VPS doesn't need to see
| the unencrypted traffic.
|
| A sibling comment made clear that the ansible recipe
| mentioned is to setup a VPN between e.g. a laptop in the
| VPS.
| mcdevilkiller wrote:
| I id have some problems with algo behind a NAT. Though my
| usecase is a bit different, more of a road warrior, as I wanted
| to be able to access a server in one property (behind NAT) from
| my home PC (also NAT). I suppose I just need port forwarding.
| L_Rahman wrote:
| I was in a similar situation. Port forwarding worked
| perfectly. In my case the server I was trying to access was
| behind an ISP (Comcast) managed NAT so I had to go through
| them to open the port. Much to my surprise they were
| extremely helpful and understanding of the request.
| joombaga wrote:
| Was this residential or business? I didn't know there were
| Comcast managed NATs beyond their internal network.
| dzonga wrote:
| Algo vpn is the best way to set up wireguard.
| curiousgal wrote:
| I wish people would stop automatically recommending Algo, for
| instance it doesn't support Arch. It's the best if your
| platform is supported. Otherwise, it's easier to just
| manually set up everything.
| huijzer wrote:
| For anyone wanting to set up WireGuard with the Pi-hole DNS
| blocker: I would advise https://github.com/racbart/wireguard-
| pihole. Just a simple shell script. No Docker or Kubernetes
| required. I installed it on the cheapest DigitalOcean VPS, and it
| has been running without issues for over a month now. (About 6
| phones of me and my friends, and a few desktops are using it.)
| kaylynb wrote:
| WireGuard is great, but I think it's really undersold when it's
| described as being just a vpn. It's really an encrypted tunnel
| that is configured like a network adapter in the Linux network
| stack.
|
| This lets you configure it with stuff like systemd-networkd and
| unit files, or easily spin up a tunnel with a few `ip` commands,
| and setup some simple nftables rules to do all sorts of stuff.
|
| I do use it as a vpn as well, but it's so much easier to setup
| than, say, OpenVPN, where you need to create tun/br interfaces
| and then tie them together with a service, etc. That said,
| OpenVPN and other actual VPN software does more than just a
| tunnel (like pushing routes, config settings, etc), so WireGuard
| cannot replace everything by itself.
|
| The documentation is rather sparse, but there isn't much to it
| either. The manpages have what you need to know and the rest is
| just general Linux network stack knowledge.
| sirtoffski wrote:
| Congratulations and big thanks to all of the project developers
| and contributors!
| djsumdog wrote:
| I recently setup WireGuard on my new dedicated server and it is
| amazingly easier compared to OpenVPN. I've setup several site-to-
| site and client-to-site VPNs on OpenVPN so maybe I'm just use to
| all the iptables/route gotchas, but not needing to do the whole
| CA/easyrsa stuff is a huge bonus.
|
| I like how their official tutorial video shows all the raw ip
| commands and then shows their wg-quick configuration script. That
| way you understand what the script is doing and what commands its
| running.
|
| One big limitation is that it cannot bind to a specific IP
| address. The author states it shouldn't matter because it won't
| respond without the right auth key (and it doesn't support TCP so
| people can't tell if it's sitting there listening) but I found I
| did get into weird routing loops where packets will come in on
| one IP and go out on another one. The primary outgoing IP is what
| shows up when you run `wg show`.
|
| It is super weird to implement a brand new service and have a
| config option for the port, but not the IP address(es) to listen
| on.
| Florin_Andrei wrote:
| > _not needing to do the whole CA /easyrsa stuff is a huge
| bonus_
|
| That's good to hear, but how does it handle authentication /
| authorization?
| tptacek wrote:
| Pretty much the same way vanilla SSH does, without the trust-
| on-first-use bit.
| PureParadigm wrote:
| Before connecting each client needs to be set up with (1) its
| own private key and (2) the server's public key. The server
| also needs to have each client's public key. Once you have
| securely shared this information out-of-band, there cannot be
| a man-in-the-middle attack because both sides know the
| expected public key of the other side, and can prove
| ownership of their own public key.
| Godel_unicode wrote:
| And no, out of the box there's no equivalent to "trust any
| cert issued by this CA and lookup the username in ldap
| based off of the cn". Enterprisey auth is left as an
| exercise for the reader.
| [deleted]
| willis936 wrote:
| Now I really want to know when raspbian will get linux kernel
| 5.6. The most recent version of raspbian came out in February
| 2020 and uses linux kernel 4.19, which came out in late 2018.
|
| https://en.wikipedia.org/wiki/Linux_kernel_version_history
| nick2k3 wrote:
| it can actually work with 4.19 and the unstable repo. I'm using
| 4.19.105-v7+ (to solve a macvlan bug in the default .97 and it
| works. It's a pain to install the headers on raspbian though
| willis936 wrote:
| That's what I've been doing, but I would like more official
| support for something as critical as VPN. I don't forward
| many ports across my NAT, so I really rely on the VPN to be
| rock solid. I am considering getting a second raspberry pi
| and running wireguard on two ports on two pis for redundancy
| (the ability to fix stuff after a bad update or me breaking
| something).
| Medicalidiot wrote:
| How does raspberry pi run on stock Ubuntu?
| willis936 wrote:
| I am actually not sure. I know raspbian has modifications in
| it that take care of board specific issues in it, such as
| high power consumption/heat from some issue related to USB PD
| and/or power states. I am not too familiar with the inner
| workings of distros and how hardware-specific fixes are
| propagated, but I like the idea of sticking with officially
| supported OS/hardware combos for "set and forget" boxes.
|
| Wireguard was too alluring to not try though, and now I
| really like it. I would like to move away from my homemade
| pull, build, and install scripts, but not for any
| good/justified reason. I suppose I just like the idea of
| someone being responsible for a software stack that I rely
| on.
| gen220 wrote:
| YMMV, but I was able to get https://archlinuxarm.org/
| running on my pis without too much head-scratching.
|
| arch is on 5.5.6 as of 3/1/2020
| (https://www.archlinux.org/download/), and it seems like
| the ARM porters are pretty good about keeping their project
| in sync (two day delay):
| http://de3.mirror.archlinuxarm.org/os/rpi/.
|
| My best guess is that by April or May, Arch will do the
| minor version bump, and then a couple days later Arch ARM
| will get it.
|
| It doesn't have the same hardware/software synergy that you
| like, but it might be a fun weekend experiment.
| baseballdork wrote:
| Arch is on 5.5.13 and has already been marked out of
| date:
| https://www.archlinux.org/packages/core/x86_64/linux/
|
| I would guess that we'll get 5.6 in the coming days.
| gen220 wrote:
| Interesting, can you cure my ignorance on why they don't
| claim to include 5.5.13 kernel in the main download page?
| I'm not super familiar with how distros are packaged up
| for consumers
|
| Is the main download page the rough equivalent to
| `master`, and your link is like the feature branch for
| merging the latest kernel version into the distro?
| arccy wrote:
| The download page is for the monthly generated install
| isos, during the install process it will sync with repos
| and install the latest version
| gen220 wrote:
| Thank you!
|
| That makes perfect sense, actually: no sense crippling
| install the .iso with (potentially) unstable program
| versions, to stymie the install process.
| kbaker wrote:
| It might get 5.4 sometime, but it is probably sticking to the
| Longterm stable kernel release set like the rest of Debian
| Buster:
|
| https://www.kernel.org/category/releases.html
| rasengan wrote:
| We have all been waiting for this. Congratulations to Jason and
| the whole WireGuard team and community! And, thank you Linus!
| Hamuko wrote:
| Has the codebase been audited now?
| tptacek wrote:
| Multiple organizations have done both formal and semi-formal
| WireGuard audits.
| tjoff wrote:
| Does anyone know of a decent bash-script (or even self-hosted
| page) that one could use to administer wireguard?
|
| Could go very far with trivial functionality, such as listing,
| adding, removing users and download a config file/qr-code.
| djclay wrote:
| The PiVPN project makes installing / administering WireGuard on
| the raspberry pi super easy - it has some scripts that nicely
| wrap WireGuard [1]. I'm not sure how generally applicable they
| are, but it might be a good starting point.
|
| [1]
| https://github.com/pivpn/pivpn/tree/master/scripts/wireguard
| oedmarap wrote:
| I forked such a script [0] and use it for setup/admin of my
| WireGuard server/users for my PCs and phone.
|
| [0] https://github.com/oedmarap/wg-install
| BrandoElFollito wrote:
| Please have a look at https://github.com/vx3r/wg-gen-web. It is
| great and the dev is very responsive.
|
| It was featured on Show HN but did not get enough traction.
| tomcooks wrote:
| Should you want to try it on a cheap VPS and fail at it, make
| sure that your shared host has tun-tap and wireguard modules
| installed (open a ticket)
| jeltz wrote:
| Yeah, I noticed that it failed on Hetzner when I tried it about
| a year ago. What I did instead was use boringtun from
| Cloudflare. Did not open any ticket though. I might want to try
| again and see if it works.
| peterwwillis wrote:
| I like the idea of WireGuard as a simple tunnel, but I wish
| people would stop comparing it with VPNs. VPNs have lots of extra
| functionality that is necessary to support a variety of use
| cases, both functionally (like pushing routes or scripts to
| clients) and security-wise (like real key management and SSO).
|
| I literally can't replace any VPN I currently use with Wireguard
| because I would lose needed functionality. I could maybe replace
| the tunnel to a bastion host, but even then I would actually be
| worse off security wise, because I'd be losing cert-based key
| management. (ex. https://smallstep.com/blog/use-ssh-
| certificates/)
| exabrial wrote:
| One thing I wish for wireguard: the ability to look up keys/ips
| in an external system like LDAP. I moved an entire call center
| [50+ people] fully remote last week. We're using wireguard. Key
| management stinks, and that is my only complaint! It is an
| incredible piece of software and I'm very thankful for it.
| vbezhenar wrote:
| Why not OpenVPN?
| recrof wrote:
| Because ovpn is not as efficient as wireguard.
| eadmund wrote:
| I think the idea is that you're supposed to build a system to
| manage WireGuard using that sort of information. I.e. WireGuard
| provides the basic primitives and second- or third-party
| tooling uses them.
|
| I like that idea, because it means that the actual WireGuard
| core is small and it's usable right now. It _is_ annoying that
| someone hasn 't yet developed neat integrations for WireGuard
| and stuff I might want to use, but -- _I 'm_ someone! I (or
| you, or whoever) can build something, and as surely as day
| follows the night someone else will build some neat things in
| the future.
|
| It's early days yet!
| exabrial wrote:
| Yep, that's what I'm asking for... right now wireguard can
| only look at configuration text files AFAIK. If it had a way
| to invoke a command/script to lookup a key/ip, any number of
| external management systems could be created!
| [deleted]
| darkwater wrote:
| You can already easily do the other way round: populate the
| config files with keys retrieved in an external system
| igetspam wrote:
| This is what I do. I have a small dynamo table and a
| Python script I run from cron. I grab all updates since
| the last run and apply all changes to the running
| service. I have the config option set to write out the
| config on service stop, so I don't lose anything on a
| restart and don't have to replay everything. I have lots
| of room for improvement but it's a quick hack that works
| for my needs. (Not sharing yet because it doesn't fully
| CRUD right now.)
| MartijnBraam wrote:
| actually wireguard doesn't look at text files at all, it
| only has a netlink interface so you can configure it using
| the `ip` command. The current tools read the text files and
| set up the network interface.
| exabrial wrote:
| Interesting... I'll have to take a look at what the
| utilities are actually done then and how they're loading
| the keys into the interface
| djsumdog wrote:
| If you look at their tutorial video, you can see what's
| going on. The tutorial has a lot of commands like
| ip link add wg0 type wrieguard ip addr add
| 10.1.20.1/24 dev wg0 wg set wg0 listen-port 5100
| private-key /etc/path/to/key ip link set wg0 up
| wg set wg0 peer........
|
| If you look at the wg-quick script, it basically reads an
| /etc/wireguard/<adapter>.conf and runs the same commands
| based on your settings.
|
| It's great when you're just trying to test things out.
| You can do a lot of stuff by hand, make sure it's
| working, try the conf file, enable the systemd or runit
| service, reboot and make sure it comes up.
| inetknght wrote:
| Can you link to the video you're mentioning?
| djsumdog wrote:
| The side-by-side video:
|
| https://www.wireguard.com/quickstart/
| briffle wrote:
| that sounds like an ideal candidate for orchestration tools
| like ansible, puppet, etc. Have them build/template out the
| config files for you
| L_Rahman wrote:
| I'm looking forward to the days when we have good user
| management for Wireguard. It's so hard to scale it across
| just my family right now.
| blacksmith_tb wrote:
| Algo (mentioned above) will generate a bunch of profiles
| for you (including QR codes to configure mobile devices
| without needing to type awkward strings), which works
| pretty well for me - at least with a family you won't need
| to add or revoke identities very often I'd hope...
| katnegermis wrote:
| I think this is what https://tailscale.com/ is trying to solve
| :)
|
| (I'm in no way affiliated, but stumbled upon it on twitter a
| few weeks ago)
| tw04 wrote:
| Tailscale looks like it's creating a mesh network - he's not
| asking for end-users to have VPN connections between each
| other (what Tailscale is doing).
|
| He's asking for a central server where he can
| retrieve/update/manage end-user keys, likely: because
| helpdesk.
|
| You could in theory do this with any number of the existing
| team password managers, but I think he'd like integration
| directly to wireguard.
|
| Edit: care to reply rather than just downvote? All of their
| documentation and examples state exactly what I'm saying.
| They're turning all the devices into endpoints and creating a
| mesh - he doesn't want users bypassing his _SINGLE_ VPN
| endpoint into the company or talking directly to each other
| based on his description. He wants Cisco Anyconnect - only
| wireguard.
| api wrote:
| We get this question about ZeroTier from time to time and
| the answer is the same: set rules (or ACLs in Tailscale) so
| as to allow only traffic to/from what you want users to
| communicate with.
| tw04 wrote:
| Sure - you can block access but the fundamental problem
| you're appearing to target isn't what he's after. Heck to
| even get the user-auth he's asking for you have to use
| tailscale + some third party app whether that's okta or
| azure or google. I'm not saying he can't sort-of
| accomplish what he's trying to do but it very much feels
| like you've got a hammer and think his screw looks like a
| nail.
| basch wrote:
| You can use ACLs to control what clients can connect to.
|
| https://news.ycombinator.com/item?id=22665589
|
| It doesnt look like a nail/hammer/screw at all. Tailscale
| isnt configured how he wants out of the box, but using SSO
| to control access isnt a massively complex hurdle. Anyone
| with Office 365 will be able to use their Office account to
| authenticate, which is basically Cloud Active Directory,
| and way better (if its something you have) than maintaining
| a separate username/password database for the VPN.
|
| ACLs and a relay node are a good fit for the request.
| https://tailscale.com/kb/1019/install-subnets
|
| Cloud SSO might be a deal breaker, but it doesnt make the
| solution the wrong class of solution.
| dfcarney wrote:
| (Tailscale co-founder here.)
|
| Building on what katnegermis said, this is what we're trying to
| help with. We integrate with identity management systems and
| handle the key management (and NAT traversal) on top of
| WireGuard, making it easier to deploy and manage.
|
| If you're interested, a colleague of mine wrote up a blog post
| on how things work: https://tailscale.com/blog/how-tailscale-
| works/
| [deleted]
| [deleted]
| pkrumins wrote:
| Very exciting! Does anyone know a good howto or a tutorial about
| it?
| newscracker wrote:
| I'd recommend using Algo VPN. See my comment in this discussion
| here: https://news.ycombinator.com/item?id=22727713
| sccxy wrote:
| Easiest way with pivpn:
|
| https://github.com/pivpn/pivpn
| nikisweeting wrote:
| https://github.com/pirate/wireguard-docs
|
| There are a bunch linked from the links section at the bottom.
| hectormalot wrote:
| I used the Stavros one: https://www.stavros.io/posts/how-to-
| configure-wireguard/
|
| Great to see 1.0.0 released. I've been using it for a VPN to my
| home network and have been really impressed with how fast it is
| (and how fast it connects!). The corporate VPNs I've used in
| the past we're so much slower that it feels like a completely
| different league, although they support many more features of
| course.
| kertis wrote:
| Actually WireGuard is pretty easy in configuration. You can try
| any documentation in Internet, it's not hard at all
| https://www.ckn.io/blog/2017/11/14/wireguard-vpn-typical-set...
|
| I advise you to try it on mobile devices or with unstable
| interested. It's a miracle!
| pricechild wrote:
| Try https://www.wireguard.com/quickstart/
|
| For real world use, I'm a fan of
| https://wiki.debian.org/Wireguard
| Glosster wrote:
| Do I understand correctly? You use WireGuard to set up your own
| VPN servers? Doing this is a lot more expensive than buying a VPN
| subscription, but it can be more secure if you know what you're
| doing, right?
| nessunodoro wrote:
| A VPN is one use of a Wireguard tunnel. Wireguard establishes a
| stateless encrypted connection between two peers, and exposes
| it to the user as a network interface. Endpoints can roam as
| with mosh
| andrepew wrote:
| I think it depends on what you're trying to achieve. If it is
| anonymity, setting it up yourself is probably not going to be a
| good idea.
|
| If you can't trust a VPN provider for some reason or are trying
| to secure a route to a specific network, setting it up yourself
| starts to make sense.
| outworlder wrote:
| 'Buying a VPN subscription' is just one use-case. Usually,
| those VPN services are intended to be used to circumvent geo
| restrictions.
|
| WireGuard is not only about that. Sure you could do it. But it
| is applicable for any use-case where you have two or more
| machines that need to talk over a secure tunnel, over an
| otherwise not proven to be secure network(which is usually, but
| not always, the Internet). This ranges from connecting to a
| machine you have at home, to exchanging data between two office
| branches, and so on.
| lifty wrote:
| I really hope WireGuard becomes a standard and get's included in
| the macOS/iOS and Windows kernels as well. Key management and and
| other fancy features could be left to userspace applications but
| having the basic wg capability in the kernel would be great.
| kitotik wrote:
| Seems like a very long shot to make it into Apple products both
| because of the license and the fact it wasn't invented in
| Cupertino.
|
| FWIW the userspace implementations are quite good, and still
| out performs IPSec.
| felipelemos wrote:
| I don't think there license would be a problem, as it's
| GPLv2, not v3.
|
| But the 'not invented here' syndrome is very real.
| stock_toaster wrote:
| Boringtun is bsd licensed. clean room implementations and
| all that...
|
| https://github.com/cloudflare/boringtun
| kitotik wrote:
| Good point, but that's still a userspace implementation.
|
| Apple would need to do the XNU work since their open
| source model is so broken, and they seemed to have
| deprioritized Unix nerds awhile back so...
| donaldihunter wrote:
| This is a good guide to getting a WireGuard server working on
| macOS: https://barrowclift.me/post/wireguard-server-on-macos
| [deleted]
| xal wrote:
| Given the occasion, could someone write a paragraph about what
| downstream effects are expected by wireguard existing? So far
| I've seen mostly technical arguments for it. VPNs have become a
| more important piece of infrastructure now. The most significant
| approachability increase really came from mobile based solutions
| and auto pilot systems like Google's Outline.
|
| Will WG make a marked difference in stability, speed,
| approachability for normal users, or what can we expect?
| igetspam wrote:
| Anecdotally: I have run ipsec based VPNs, openvpn, SSH tunnel
| based VPNs, etc. Almost all have been a bit of a PITA. I walked
| someone through setting up a WG based VPN two weeks ago, at a
| wework in Jakarta. Took 10m via slack. The machine is behind a
| NAT and I haven't had a single problem connecting. I've done
| tests where I rolled a new server and as soon as it was up, the
| tunnels were back. It's a thing up beauty.
| myu701 wrote:
| Someone else can give a much better comparison than me, this is
| just to get you started.
|
| Compared to the 80% use case of OpenVPN, Wireguard is:
|
| 1. Much less code. A few thousand lines of code vs lots more
| for OpenVPN
|
| 2. Speedier. WG does UDP traffic so there is less overhead on
| the protocol level for syncs acks etc.
|
| 3. Easier on mobile battery life due to decreased complexity
|
| For one example use case comparing them side by side, see
| PiVPN, which I use to setup a Raspberry Pi Zero W on my home
| network, create a client key for my phone, open a single port
| forward to the pivpn server, download the wireguard app, scan
| the qr code the pivpn key generated, and poof, I can check a
| box and 'be' on my home network, behind my pihole, and with
| access to my LAN resources.
|
| OpenVPN can do that usecase with pivpn as well but its more
| processor intensive and a little more setup vs wireguard.
| kertis wrote:
| > little more setup
|
| A lot more! PKI infrastructure, chiphersuites and so on and
| so forth...
|
| By the way OpenVPN also can work with UDP, even it's default
| mode.
| K0SM0S wrote:
| It's a lot more if you do it all manually, however for most
| "common" use cases, one should probably go with
| automatically generated config files.
|
| For instance pfSense provides you with single-click configs
| for any target platform, with certs, credentials etc.
| properly tied to some ACL or ID management system, etc.
| It's neat and pain-free and just works.
|
| You could learn all the theory underneath (I mean systems,
| IT, not the crypto!) and do it manually (and you probably
| should for a big-enough infra, or specific-enough use-
| case), but that will be premature optimization I think.
|
| Basic VPN is easy (take a weekend to learn / implement and
| you'll have all the great benefits of VPNs). Wireguard is
| "just" more efficient by an order of magnitude as I see it,
| it'll become the de facto low-profile implementation me
| thinks.
| kertis wrote:
| First setup _always_ needs to be manual.
| K0SM0S wrote:
| ... yes, obviously? : )
|
| We might not be using the word "manual" to mean the same
| here.
|
| I meant not writing the whole xml json yaml or whatever
| yourself, manually copying certs and credentials etc --
| you're likely to make mistakes, it's tedious and useless
| most of the time. You rather use tools like Viscosity.
| Just efficient / best practice sysadmin.
|
| You _obviously_ need access to the target machine in the
| first place... it 's a VPN setup.
| vbezhenar wrote:
| I wonder how WireGuard compares to IPsec with regards to the
| mobile battery. AFAIK IPsec implemented in kernel while
| WireGuard uses user-space implementation on mobile devices,
| at least for now.
| yjftsjthsd-h wrote:
| I'm pretty sure some ROMs already have kernel support,
| although I don't know details.
| kertis wrote:
| For some Android kernels official WireGuard application
| supports in-kernel module. Fox example for pixel 3.
| packetlost wrote:
| The code has been merged into the kernel as of 5.4(?) I
| believe, but we won't see that on mobile for quite awhile.
| I'm guessing IPSec will still have a lead on mobile for
| awhile for that reason, not that it has sort of majority on
| there anyway.
| fullstop wrote:
| It was merged in 5.6, which was tagged less than 24 hours
| ago.
| packetlost wrote:
| Ah, I remember reading about it like a month ago or so
| but I though it had already been released
| AnIdiotOnTheNet wrote:
| Wiregard may be speedier (I've never used it so I can't say
| for certain), but OpenVPN can also use UDP.
| api wrote:
| WG is much faster in our tests than OpenVPN, and a bit
| faster than IPSec depending on the system. OpenVPN uses UDP
| too but OpenVPN is kind of slow.
| zajio1am wrote:
| Or much slower on systems with AES-NI, but relatively
| slow CPU. Like are used in some hi-end SOHO routers.
|
| I did not test IPSec vs WireGuard, but scp from/to my
| home router/NAS is about three times faster with AES
| (used by IPSec) than with Chacha20 (used by WG).
| api wrote:
| Good point. AES hardware acceleration makes a massive
| difference. It's why ZeroTier 2.x will use AES. Tiny
| boxes that lack HW acceleration are generally not used in
| cases where they're pushing enough bandwidth to matter
| anyway.
| jeltz wrote:
| No, but boxes who lack hardware acceleration might care
| about battery life.
| api wrote:
| How many 32-bit ARM phones without AES units are there
| still around?
| bjoli wrote:
| i did test it. in my setup we couldn't get IPsec to not
| drop a lotmof packages, so the benefits of aes-ni was
| lost in retries. switching that IPsec setup to
| chacha20-poly1305 actually made most of the drops go
| away.
|
| I have no idea what was going on, but wireguard and IPsec
| was comparable in that test, with ispec being sliiiightly
| faster. the network has almost no latency, so if the
| retries remain on slower networks, that would change.
| Brakenshire wrote:
| Makes a good argument for having a mobile phone on the
| mainline kernel, rather than on some ancient kernel with a
| thousand hacks layered on top. Something like Pinephone
| should get access to this more quickly than a standard
| Android device.
| middleclick wrote:
| On that note, I wish and hope Wireguard did TCP as well. Some
| countries block UDP traffic or at least throttle it.
| jeltz wrote:
| Maybe the best solution is to use a tool like
| https://github.com/wangyu-/udp2raw-tunnel.
| middleclick wrote:
| I know, but the performance takes a massive hit. Have you
| tried it? Maybe it was something I did wrong.
| labawi wrote:
| Native wireguard is kernel-only. Udp2raw creates a detour
| via userspace, so more CPU time, delay, jitter ..
|
| Was it worse than you would expect? Worse than say
| openvpn or wireguard-rs/wireguard-go?
| RcrdBrt wrote:
| It's not that bad. Overhead is less than a full TCP
| encapsulation. I use it all the time
| alexellisuk wrote:
| Have you taken a look at inlets / inlets PRO? Might be a
| suitable replacement for your use-case where UDP is not
| available. https://docs.inlets.dev/
| api wrote:
| ISPs or _countries_?
| fnordsensei wrote:
| In some cases, countries. In the country I'm thinking of
| (name omitted on purpose), you have an effective choice
| of two ISPs, both government-controlled.
| api wrote:
| Do they actually block/throttle all UDP?
|
| What about encrypted TCP? Do they block/throttle
| everything but web and recognized traffic? If that's the
| case wrapping WG or ZeroTier or whatever in TCP would do
| nothing since it would still look like a weird
| unrecognized protocol with a max entropy (encrypted) data
| stream.
| kertis wrote:
| As I know WireGuard team have no plans and desire for that.
| djsumdog wrote:
| huh .. OpenVPN is UDP by default but you can force it to
| TCP (we had to do that at one University site that would
| only open limited tcp ports for us).
|
| I also discovered Wireguard cannot bind to a specific
| adapter or IP address if you have multiple address on a
| server. That might not seem like as a big a deal since it
| only responds to fully authenticated packets, but it does
| mean that outgoing packets could be leaving from a
| different IP address than incoming packets.
|
| It's weird that something that's now making it into
| mainline can't do this very simple kind of bind that
| almost every other userlevel service, and OpenVPN, can
| do.
| RcrdBrt wrote:
| https://github.com/wangyu-/udp2raw-tunnel
| kertis wrote:
| Among other features WireGuard has roaming mode, it's fantastic
| for mobile devices. Just try it, it's easy and quick!
| tw04 wrote:
| In my experience the problem with roaming mode is it blocks
| the login page for wireless networks. IE: in a coffee shop.
| Maybe that's been fixed recently, but it was a giant PITA in
| the past.
| kertis wrote:
| I suppose because of DNS servers. Shops give you own
| "correct" dns for showing you adds on any first request.
| djsumdog wrote:
| You can use iodine for those wi-fi hotspots that charge
| for access. It tunnels TCP-over-DNS
| kertis wrote:
| My congratulations to Jason and team! I am very happy that your 6
| years effort led to merging in mainline.
| samgranieri wrote:
| Congratulations Jason! Wireguard is a joy to use.
| saber6 wrote:
| Can we please just ban any mention of TailScale and ZeroTier from
| any article containing WireGuard? This place is becoming fucking
| spam central.
| ur-whale wrote:
| This is _really_ good news.
|
| I've used a ton of VPN over the years, even some I wrote myself,
| and I've never seen anything that comes close to wireguard in
| terms of: ease of use, speed, cleanliness of code.
|
| The world just got a whole lot secure and flexible.
| jannes wrote:
| Unfortunately not in time for Ubuntu 20.04 which will be shipping
| with a 5.4 kernel. Can't wait for Ubuntu to have this builtin!
| jabl wrote:
| Ubuntu 20.04 will have wireguard backported to their version of
| 5.4.
| laktak wrote:
| I use WireGuard and it works perfectly fine as it is.
|
| Can someone explain why we need/want to put it into the Linux
| kernel?
| catalogia wrote:
| If you've been using it on linux, you've almost certainly
| already been using the kernel version. Anecdotally, using it on
| my home LAN, the kernel implementation on linux performs much
| better than the userland implementation on MacOS. (Admittedly
| not the same hardware, the linux machine is a i5-3427U while
| the MacOS machine has an i5-5250U. I think the former might
| have an L2 cache advantage, but I'm not sure if that would
| explain the difference.)
| mikepurvis wrote:
| If nothing else, the long term maintenance commitment is
| important for companies being willing to adopt and build on it.
| ac29 wrote:
| Here's an answer from the author back in 2016:
| https://news.ycombinator.com/item?id=11994544
| cyphar wrote:
| WireGuard on Linux has always been implemented as a kernel
| module (a very small one at that). If you've used it on Linux,
| you've used the code that has been included in Linux 5.6.
|
| This is about the code being merged upstream into the main
| kernel repository which means that it'll likely be built-in to
| lots of distribution kernels and will no longer have the
| second-class status that most out-of-tree kernel modules have.
| cjbprime wrote:
| The version you've been using on Linux was already in the Linux
| kernel. It's a Linux kernel module. Now it's just part of the
| official Linux source release, so groups like Linux
| distributions such as Ubuntu will start turning it on by
| default.
| tandav wrote:
| still no good tutorial for complete beginners
| ac29 wrote:
| Yeah, the documentation on the webpage isn't great - there
| isn't actually an example that you can follow step by step to
| get a usable tunnel. That's unfortunate, because it isn't
| actually that hard.
|
| Much better documentation is here:
| https://github.com/pirate/wireguard-docs
| MrStonedOne wrote:
| This is not an appropriate announcement post for a product, as it
| does not explain what the fuck a wireguard is, and given that it
| has been in beta up until now, the number of people who read
| hacker news and won't know what the fuck a wireguard is, is high
| enough to warrant only a proper announcement post for the
| product.
| dang wrote:
| We assume HN readers are smart enough to figure things out.
|
| https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
|
| https://arstechnica.com/gadgets/2020/03/wireguard-vpn-makes-...
| is a related article, if that helps!
___________________________________________________________________
(page generated 2020-03-30 23:00 UTC)