Live data from Hacker News

WireGuard is submitted for Linux kernel inclusion

marc.info

41–50 of 189 posts

Re: WireGuard is submitted for Linux kernel inclusion

#41

Earlier quoted context omitted.

I agree. I've been using Wireguard for about 6 months now. The quick start is great for getting a quick overview but it doesn't really document properly how a configuration file should be made. There is no real detail about how a wg-quick config differs from a wg one, and they're not compatible; it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like w…

> it'll complain about unknown keys/values or something if you use a wg-quick config with extra firewall rules and the like with plain wg. Really? I didn't even know that, thanks. > if you modify your config file and down/up with wg-quick it'll delete anything you entered in your config Ouch. Yeah, these things definitely need to be documented, I had no idea about this either. I would also like to see an easier way t…

> I would also like to see an easier way to configure authentications

Agreed. I like the way home assistant does it with a secrets.yml and you refer to your secrets by !secret

Re: WireGuard is submitted for Linux kernel inclusion

#43
post #14

Earlier quoted context omitted.

I've been using wg for over a year now and never had any difficulty finding documentation. `man wg` works just fine as does `man wg-quick` https://www.wireguard.com/quickstart/ also shows you how to make a config file

The problem is that a regular user [some of them] can follow documentation, set up a server and a client, use wg to connect them and may be even ping the connection. That's it, congratulations. How is this connection can be used? Which IPs should be used to establish a useful connection? How can a user see their LAN resources through it? How can a user route his web browsing through this connection (here we at least…

That's the thing with a vpn - it is just a single component of a fully setup network. The vpn documentation generally just covers how to setup the vpn connection. The routing and rest of the network setup, as per the questions you are asking, generally falls out of its domain and into general networks.. which is quite a huge area!

Re: WireGuard is submitted for Linux kernel inclusion

#44
post #15

The only downside with WireGuard for me is that it only works over UDP. I am in a situation where I only have two or three TCP ports available for a VPN, so I won't be moving off OpenVPN anytime soon. I was following WG development for a while now and I think it's a great project, but sadly not for my particular use case.

You really need to get that fixed, as you are severely handicapped without UDP. Apart from existing UDP usecases, the general progression is away from TCP and onto UDP. QUIC is an example of such progression.

The reason Wireguard doesn't do TCP is that it is only a handicap for tunneling, and impedes Wireguard's connectionless features. Maybe Wireguard could add it as a compat option, but the experience will be worse than over UDP.

In the meantime, making a hacky UDPTCPUDP proxy isn't very hard. Less than 100 lines of Go. It'll handicap Wireguard quite a bit (even more than a built-in TCP compat feature), but it'll probably still be faster than OpenVPN.

Re: WireGuard is submitted for Linux kernel inclusion

#45
post #9

Why does this need to be included in the kernel directly and not just as a loadable module?

When the API it relies on changes, the person doing the change will fix WG rather than the WG maintainers. Also it enables you to update the kernel without having to hunt for the matching release of WG separately.

Like most device drivers it can be included in the mainline kernel but compile as a module.

Re: WireGuard is submitted for Linux kernel inclusion

#49
post #43

Earlier quoted context omitted.

The problem is that a regular user [some of them] can follow documentation, set up a server and a client, use wg to connect them and may be even ping the connection. That's it, congratulations. How is this connection can be used? Which IPs should be used to establish a useful connection? How can a user see their LAN resources through it? How can a user route his web browsing through this connection (here we at least…

That's the thing with a vpn - it is just a single component of a fully setup network. The vpn documentation generally just covers how to setup the vpn connection. The routing and rest of the network setup, as per the questions you are asking, generally falls out of its domain and into general networks.. which is quite a huge area!

this is a very good point.

Also, from a network design perspective, the difference between a tunnel, GRE interface or VPN is nonexistant. They all accomplish the same objective with different technical methods.

Re: WireGuard is submitted for Linux kernel inclusion

#50
post #15

The only downside with WireGuard for me is that it only works over UDP. I am in a situation where I only have two or three TCP ports available for a VPN, so I won't be moving off OpenVPN anytime soon. I was following WG development for a while now and I think it's a great project, but sadly not for my particular use case.

You really need to get that fixed, as you are severely handicapped without UDP. Apart from existing UDP usecases, the general progression is away from TCP and onto UDP. QUIC is an example of such progression. The reason Wireguard doesn't do TCP is that it is only a handicap for tunneling, and impedes Wireguard's connectionless features. Maybe Wireguard could add it as a compat option, but the experience will be worse…

Well, this is a network where only SSH and one or two more TCP ports are open, and it's not something I can "get fixed".

Still, I do not have any practical reason for switching to Wireguard, as I do not really see any reduced speed - it is possible that the bandwidth limitation of this network's internet connection is low enough for that to be the bottleneck, instead of OpenVPN. :)

Post reply on HN