81–90 of 214 posts
Earlier quoted context omitted.
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.
It was merged in 5.6, which was tagged less than 24 hours ago.
Earlier quoted context omitted.
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.
+1 for good points. Also, ty for "kiddiot" (much better than "script kiddie" term)
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.
FWIW the userspace implementations are quite good, and still out performs IPSec.
Earlier quoted context omitted.
Maybe the best solution is to use a tool like https://github.com/wangyu-/udp2raw-tunnel .
I know, but the performance takes a massive hit. Have you tried it? Maybe it was something I did wrong.
Was it worse than you would expect? Worse than say openvpn or wireguard-rs/wireguard-go?
Earlier quoted context omitted.
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)
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 rep…
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.
Earlier quoted context omitted.
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.
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
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........
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.
Earlier quoted context omitted.
On that note, I wish and hope Wireguard did TCP as well. Some countries block UDP traffic or at least throttle it.
As I know WireGuard team have no plans and desire for that.
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.
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?
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.
Earlier quoted context omitted.
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.
I suppose because of DNS servers. Shops give you own "correct" dns for showing you adds on any first request.