Live data from Hacker News

Identity management for WireGuard

lwn.net

91–100 of 107 posts

Re: Identity management for WireGuard

#91
post #83
post #71

Earlier quoted context omitted.

Yes, there is plenty of evidence for this; see for instance the WireGuard paper. Numerous code size comparisons have been done here. Further, that is not what the WireGuard paper concludes. For instance: the paper makes a note of the fact that WireGuard is designed to be implemented without dynamic memory allocation, which is not a function of lines of code (in fact, it probably adds lines of code). You do you, but a…

Plenty of code size comparisons with Wireguard and 3rd party apps providing feature parity with OpenVPN? Can you provide some links? The Wireguard paper makes notes of many things including the lines of code needed to implement. "I'd say using OpenVPN or IPSEC in 2022 without some powerful compatibility, regulatory, or network complexity concern to support it is malpractice." Life is complicated and those type of con…

The hand waving and moving goalposts would be less glaring if you, you know, mention a single use case where WG is supposedly the inferior solution?

Re: Identity management for WireGuard

#92

I'm currently running Tailscale at home, but will switch to Headscale once they get iOS support sorted out. It's magical. It's well on the way towards being a critical piece of infrastructure in my mind.

I felt the same way until Tailscale mysteriously stopped working one day for iOS. There’s no way to troubleshoot. A bunch of forum posters reported the same issue after an update, but no solution for a few months.

Same here for Windows, I believe I got this one https://github.com/tailscale/tailscale/issues/5531

Re: Identity management for WireGuard

#93
post #81

Earlier quoted context omitted.

Split DNS is super complicated to implement client side. We halfway implemented a solution and backtracked, eventually settling on just setting /etc/hosts. There's way too many variables involved across all the different operating systems.

These days it's pretty simple to achieve with systemd-resolved. I've been playing with split DNS and VPNs for a while and it seems it's a solved problem on Linux, finally. The big hurdle is understanding the concept of search domain vs routing domain and the interaction with resolved and NetworkManager.

Funny, systemd is like an opposite of wireguard in design goal. I believe the UNIX way would be /etc/hosts but some way to sync these within clients. Like etcd or whatever.

Re: Identity management for WireGuard

#94
post #93
post #81

Earlier quoted context omitted.

These days it's pretty simple to achieve with systemd-resolved. I've been playing with split DNS and VPNs for a while and it seems it's a solved problem on Linux, finally. The big hurdle is understanding the concept of search domain vs routing domain and the interaction with resolved and NetworkManager.

Funny, systemd is like an opposite of wireguard in design goal. I believe the UNIX way would be /etc/hosts but some way to sync these within clients. Like etcd or whatever.

An issue with /etc/hosts is that it is just one file and you do not want etcd to own all the config you would need to use something like NIS instead.

Re: Identity management for WireGuard

#95
post #94
post #93

Earlier quoted context omitted.

Funny, systemd is like an opposite of wireguard in design goal. I believe the UNIX way would be /etc/hosts but some way to sync these within clients. Like etcd or whatever.

An issue with /etc/hosts is that it is just one file and you do not want etcd to own all the config you would need to use something like NIS instead.

Ah yes, my bad. /etc/nsswitch.conf (which is also a Linux-ism but BSDs have something similar) supports LDAP. However, an advantage of /etc/hosts is the low latency since its not networked, while LDAP would result to overhead. Still, I believe that would be a suitable alternative. There's some non-bloated alternatives to OpenLDAP, and also an option could be caching.

Re: Identity management for WireGuard

#96

Earlier quoted context omitted.

Another thing I wish it would use is the built in kernel support for wireguard.

Wireguard already does this. Did you mean something else?

Yes Wireguard but not tailscale. Tailscale can only use the userspace implementation of Wireguard. Not sure why exactly.

Re: Identity management for WireGuard

#97

Earlier quoted context omitted.

You already have to open your fw for wg traffic, doesn't seem too obnoxious to just allow/drop there.

Deny by default and Defense in depth are good security approaches in many organisations. I may have a critical server that only comes from 1-2 known, static, IPs. Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my…

My point is, you deny by default and only allow your static ips at the FW.

You need a firewall rule anyway to let the wg traffic through.

WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.

Re: Identity management for WireGuard

#98

Earlier quoted context omitted.

Wireguard already does this. Did you mean something else?

Yes Wireguard but not tailscale. Tailscale can only use the userspace implementation of Wireguard. Not sure why exactly.

Yeah, that would make Tailscale a non-starter for me.

Re: Identity management for WireGuard

#99

Earlier quoted context omitted.

Deny by default and Defense in depth are good security approaches in many organisations. I may have a critical server that only comes from 1-2 known, static, IPs. Repeat this for dozens of servers. Now treat each of these servers as third parties not under your control. I don’t want one of these third parties using a key that doesn’t belong to them. As a silly example, let’s say I send one third party the key for my…

My point is, you deny by default and only allow your static ips at the FW. You need a firewall rule anyway to let the wg traffic through. WG was built to handle roaming, and the FW can do a great job of filtering by address already, so it makes sense to not bloat wg with extra code to me.

But the FW can’t filter by source IP and key, which is important to some people. There’s a gap in security coverage between WG and FW. This is commonly supported by IPsec implementations already.

Remember your WG service could be terminating many tunnels from many different sources. Some yes roaming may be valid. Others not. There is no way in WG to selectively disable roaming for some keys but not others. This may be an intentional design decision in WG but I would argue it’s a poor one due to the above.

Re: Identity management for WireGuard

#100
post #56
post #4

When Wireguard was 1st rolled out the smaller code base vs OpenVPN was touted as a feature. Now that 3rd party systems are available to bring feature parity with OpenVPN, it would be interesting to see a comparison of the size of the code base inclusive of these 3rd party systems. Not interesting enough for me to put forth the effort to do it but still interesting.

First, even with third-party code, WireGuard is going to be significantly smaller than OpenVPN (and significantly easier to audit). But more importantly, you can't just count lines of code as if they're all equivalent. There's a trusted core of code that is more important than the rest of the code, and WireGuard's trusted code is microscopic compared to OpenVPN. That's the right word in this case: "microscopic". It's…

Large organizations sometimes use Strongswan bc it has stuff like CAs integrated. (Ok, it's using IPsec, but that's still not OpenVPN)
Post reply on HN