Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WireGuard Gives Linux a Faster, More Secure VPN

wired.com

Post reply on HN
Print view View original

241–250 of 306 posts

Re: WireGuard Gives Linux a Faster, More Secure VPN

#241

Post by marktangotango »

jcrawfordor wrote: post #54
fivesixzero wrote: post #13

Increasingly it seems like heavily opinionated foundational tools and frameworks are overtaking more highly configurable alternatives, at least in terms of breadth of usage or popularity. Could this be a positive change? Does this represent a healthy response cognitive fatigue in a world with configuration options at every possible layer? Or does this shift to less readily configurable tools represent an overall nega…

At least in some ways, it feels to me like Wireguard is more of a return to the "unix philosophy" (if there is such a thing) when compared to solutions like OpenVPN and ipsec/StrongSwan. Doug McIlroy, amongst the designers of Unix, said that tools should "Do One Thing And Do It Well." Wireguard seems like a great example: it offers very few knobs and levers in large part because the scope of its capabilities is very…

> if there is such a thing

There is indeed such a philosophy:

https://www.jwz.org/doc/worse-is-better.html

Re: WireGuard Gives Linux a Faster, More Secure VPN

#242

Post by api »

AceJohnny2 wrote: post #237
api wrote: post #230

Earlier quoted context omitted.

MACs are computed directly from cryptographic hashes. For normal ZeroTier P2P traffic the MAC and Ethernet header are elided entirely too, which saves about 14 bytes of per-frame overhead.

Wait, are we talking about MAC as in cryptographic Message Authentication Code, or MAC as in ethernet Medium Access Control (addresses)?

MAC as in 48-bit Ethernet addresses.

https://github.com/zerotier/ZeroTierOne/blob/master/node/MAC...

There's a tiny chance of a collision, but for it to be meaningful you'd have to have a virtual LAN with millions of devices on it.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#243

Post by netflixandkill »

josteink wrote: post #107

WireGuard is nice and fast indeed, but unusable for me at work, because pretty much all outbound UDP-traffic is filtered. Having a TCP-based option sure would be nice.

I've had consistent success running wireguard over 443 on a wide variety of otherwise limited networks now that quic has been around a while.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#244

Post by dragonsh »

ahnick wrote: post #7
dragonsh wrote: post #4

I hope WireGuard can come to feature parity with TincVPN will be nice. Especially automatic routing and mesh VPN formation, it can really help our multi-cloud container clusters connected using TincVPN to be bit more performant. The difference is WireGuard is part of Linux kernel so speed of processing packets is faster than TincVPN. Still experimenting with WireGuard and manually creating peer to peer mesh.

Tailscale looks promising. ( https://tailscale.com/ )

Is tailscale open source like Tinc?

From the website cannot see it.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#245

Post by 1_player »

tosh wrote: post #124

I think Tailscale [1] can be to WireGuard what Github and Gitlab are to git. If you haven’t checked them out yet: worth taking a look! [1] https://tailscale.com

Works only with some identity providers, for some reason I could not understand. If you don’t have a Google, Microsoft or corporate email identity provider, you can’t use it.

There might be a reason for this, but still it’s not in the same space as Wireguard.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#246

Post by upofadown »

tptacek wrote: post #229
upofadown wrote: post #220

Earlier quoted context omitted.

So at midnight July 23 2026 everyone upgrades to wireguard2 all at once? Perhaps I am not getting what you are proposing here...

Just like with TLS and its "ciphersuites", you expose the vulnerable components for as long as (1) you're required to by your users and (2) the risk is bearable. At some point, you stop exposing the vulnerable component at all. Ciphersuite negotiation doesn't free you from this requirement, but it does make it harder to ensure that peers who agree on non-vulnerable parameters are actually able to use them. None of th…

My understanding is that Wireguard has no way to do anything other than what it does now. There is no way to use an upgrade in the protocol.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#247

Post by loeg »

kseifried wrote: post #219
jlgaddis wrote: post #130

Earlier quoted context omitted.

I'm sure you know this but, for the benefit of others... With this exception, WireGuard does not CVEs because it is (for now) still considered pre-release software and not recommended for production use.

CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases

Sure, but Donenfield has specifically declared that CVEs not be issued for "pre-release" Wireguard components[1]:

> Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software).

[1]: https://www.wireguard.com/

Re: WireGuard Gives Linux a Faster, More Secure VPN

#248

Post by kseifried »

loeg wrote: post #247
kseifried wrote: post #219

Earlier quoted context omitted.

CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases

Sure, but Donenfield has specifically declared that CVEs not be issued for "pre-release" Wireguard components[1]: > Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). [1]: https://www.wireguard.com/

Yeah and he's not the boss of CVE. If someone wanted a CVE for wireguard I'd be happy to help them get one.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#249

Post by rattray »

pathseeker wrote: post #176
rattray wrote: post #160

Earlier quoted context omitted.

Can you say more to explain the utility of this to those unfamiliar with networking?

Many device discovery protocols work by sending out broadcast or multicast packets (either to announce themselves to devices who might be listening or to request devices to send them data). These packets are expected to go out to either everyone on the same layer-2 network (the broadcast case) or everyone who has subscribed to a particular multicast address (the multicast case). In addition to device discovery, these…

Thanks! That's helpful/interesting and makes sense

Re: WireGuard Gives Linux a Faster, More Secure VPN

#250

Post by kseifried »

loeg wrote: post #247
kseifried wrote: post #219

Earlier quoted context omitted.

CVE does cover "pre-release" software, part of the argument being you can't simply label something as "beta" and escape CVE coverage especially if millions of people are using it (Google's Chrome web browser was a good example of this). For example: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=prereleases

Sure, but Donenfield has specifically declared that CVEs not be issued for "pre-release" Wireguard components[1]: > Current snapshots are generally versioned "0.0.YYYYMMDD" or "0.0.V", but these should not be considered real releases and they may contain security quirks (which would not be eligible for CVEs, since this is pre-release snapshot software). [1]: https://www.wireguard.com/

Also to reiterate: "which would not be eligible for CVEs, since this is pre-release snapshot software" is not correct. It's usually correct, but not 100%.
Post reply on HN