Live data from Hacker News

WireGuard is in net-next

git.kernel.org

141–150 of 208 posts

Re: WireGuard is in net-next

#141
post #54
post #14

Earlier quoted context omitted.

way simpler (and thus, I would argue, way more secure). way faster. On the other hand: No built-in client in any of the mobile OSes, so a third-party client install is required.

It may be way simpler for basic setups but it quickly becomes as or more complex than ipsec for more advanced setups such as those involving dynamic routing and/or fail over routes. The additional complexity is due to the fallout of allowed-ips and how they are used. What you essentially end up with is that a wireguard interface represents a point to multipoint non-broadcast network. Any one that has dealt with Frame…

This is why I still use Tinc for my personal use cases. The nodes can route through each other in user space. No kernel ip forwarding required. Downside is, it's very slow compared to Wireguard. For my uses cases, that is probably ok.

Re: WireGuard is in net-next

#142

Earlier quoted context omitted.

At the terminal with wg-quick, in NetworkManager, on a phone? Just wondering how impressive your kid is.

On my Macbook there's a drop-down menu hanging off a menu bar icon. I feel like I could definitely show a little kid how to get themselves on the VPN.

I didn't know that. Ubuntu user.

Re: WireGuard is in net-next

#143

Earlier quoted context omitted.

> Second: it's easy. To give you some perspective, it's so easy that my four year old knows how to turn it on when we're traveling and she wants to watch PBS Kids.

At the terminal with wg-quick, in NetworkManager, on a phone? Just wondering how impressive your kid is.

iPhone. But the desktop is super easy too.

Re: WireGuard is in net-next

#145
post #54
post #14

Earlier quoted context omitted.

way simpler (and thus, I would argue, way more secure). way faster. On the other hand: No built-in client in any of the mobile OSes, so a third-party client install is required.

It may be way simpler for basic setups but it quickly becomes as or more complex than ipsec for more advanced setups such as those involving dynamic routing and/or fail over routes. The additional complexity is due to the fallout of allowed-ips and how they are used. What you essentially end up with is that a wireguard interface represents a point to multipoint non-broadcast network. Any one that has dealt with Frame…

I think this is a really strong comment. The only observation I'll make is that making the simple base case for VPNs easy is much more important than making dynamically routed VPNs straightforward.

More people should be using VPN-like-tunnels as an access solution, but don't, because every VPN other than WireGuard builds in extra complexity to support use cases they don't have. What the industry desperately needed was a trustworthy VPN that was as simple to set up as SSH, and that's effectively what WireGuard is.

I agree preemptively: if your VPN is complex enough that you're running OSPF for it, for now, you should probably stick with IPsec, even though commercial IPsec implementations aren't trustworthy. But WireGuard will accommodate complex VPNs long before IPsec or OpenVPN get as simple for the straightforward "get access to staging Postgres" use case as WireGuard is.

Re: WireGuard is in net-next

#146

Great experience with WireGuard so far, but does anyone know a simpler way to use it over networks where UDP is blocked (e.g. university Wi-Fi)? I've only found this comment[1]. [1] https://news.ycombinator.com/item?id=17847008

You could try setting up a WireGuard server that listens on udp port 53, which is typically used by DNS and unlikely to be blocked. I haven't used it, but algo recently added a configuration option to do so[1]. Of course WireGuard traffic will look much different than DNS, so they could still block it if they really care to. [1]: https://github.com/trailofbits/algo/pull/1594

I would say DNS is more likely to be blocked than other UDP ports, to force the use of a specific DNS server (not uncommon on public networks).

Re: WireGuard is in net-next

#147

Earlier quoted context omitted.

What iOS client are you using? I am using the Wireguard one (the the twisty snake/dragon) and don't see any of these options. Is this stuff that is done in the config files? Sorry, all new to me.

It's in there! Scroll down to the "On-demand activation" section of the settings for your connection

There it is! Thank you!

Re: WireGuard is in net-next

#148

Great experience with WireGuard so far, but does anyone know a simpler way to use it over networks where UDP is blocked (e.g. university Wi-Fi)? I've only found this comment[1]. [1] https://news.ycombinator.com/item?id=17847008

You could try setting up a WireGuard server that listens on udp port 53, which is typically used by DNS and unlikely to be blocked. I haven't used it, but algo recently added a configuration option to do so[1]. Of course WireGuard traffic will look much different than DNS, so they could still block it if they really care to. [1]: https://github.com/trailofbits/algo/pull/1594

Blocking DNS to arbitrary IPs is very common in locked down environments. They force you to use their resolver handed out by DHCP.

Re: WireGuard is in net-next

#150

I recently started using OpenVPN (My router comes with it pre-installed). Does anyone know how this compares with OpenVPN? Is is worth setting up my own wiregaurd machine?

WireGuard is much faster than OpenVPN, much simpler to set up than OpenVPN (except for having to set up IP addresses it's approximately as easy to get working as SSH), and it's much, much more secure than OpenVPN.

> WireGuard is much faster than OpenVPN

Not relevant for most home internet connections

> much simpler to set up than OpenVPN

+1

> and it's much, much more secure than OpenVPN.

That’s uselessly vague. Do you mean the protocol, the implementation approach, the underlying crypto, or what?

Post reply on HN