Live data from Hacker News

WireGuard Gives Linux a Faster, More Secure VPN

wired.com

251–260 of 306 posts

Re: WireGuard Gives Linux a Faster, More Secure VPN

#251

I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment. The level 3-only tunnel is motivated as "…

In most scenarios, you want to avoid L2 tunnels to reduce complexity and/or performance issues.

The chain of thought typically goes like this:

* Remote networks are connected via L2 tunnel.

* ARP requests are broadcasted over L2 tunnel to all connected networks, introducing scalability issues

* Proxy ARP is introduced to cache ARP responses

* Proxy ARP may become out of date or not scale as the L2 domain grows.

* BGP is introduced to keep track of and broadcast all topology changes

* How do you mitigate issues caused if Proxy ARP fails?

Most of these issues go away if you use IP tunnels instead of Ethernet because IP was designed to be routable.

For your point on security... Whitelisting MAC addresses doesn't provide security. These are trivial to spoof. Same with IP. Please start relying on cryptographic primitives to establish workload identity instead. I highly suggest looking at SPIFFE to get started here.

If you must send L2 over the VPN, please go use a L2 EVPN which is designed to handle the complexity and provide fault tolerance. There are numerous SDNs out there you can use to implement this including Tungsten Fabric and OpenDaylight. No need to complicate Wireguard to support EVPN.

[edited to improve formatting of bullets and clarity of wording]

Re: WireGuard Gives Linux a Faster, More Secure VPN

#252
post #165

I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment. The level 3-only tunnel is motivated as "…

Substituting MAC for IP address is exactly what ZeroTier does. MACs can't be spoofed, though nodes can be designated as bridges and that allows them to impersonate MACs. There's still the issue of authenticating IPv4 IPs though, which are too small to embed anything useful into. ZeroTier has a certificate system for that but it requires the use of the rules engine to enable it.

MACs can be spoofed. There are entire companies which begin their sales pitch with "So, I can poison the ARP cache to take over your DNS in your Kubernetes Cluster" due to the NET_RAW capability required to respond to ICMP (ping). :)

You'll want to use a crypto based identity if you want to ensure spoofing isn't occurring. Even then, you can still be DOSed by a malicious actor. Tools like eBPF may be able to help here by filtering out source MAC addresses that don't match the source interface's hwaddr.

edit: Sorry, I didn't read this comment properly. In ZeroTier I can believe that they cannot be spoofed across the VPN due to relying on a cryptographic hash. :)

Re: WireGuard Gives Linux a Faster, More Secure VPN

#253

I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment. The level 3-only tunnel is motivated as "…

Hmm, but MACs (and Ethernet?) are on their way out with IPv6, replaced by specifically software-set GUIDs ?

Most IPv6 packets are encapsulated in Ethernet frames which use MAC addresses. What may change is the vendor specific MAC address could be replaced with a MAC address generated by a cryptographic hash to preserve privacy.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#254
post #171

Earlier quoted context omitted.

I don't know try to type "Wireguard NetworkManager Ubuntu" in your favorite search engine? https://blogs.gnome.org/thaller/2019/03/15/wireguard-in-netw...

I don't know try to read parent's comment again and see it's about GUI?

this doesn't even work for me in CLI. I'm able to create a connection from a wg0.conf file, but it's not coming up, while regular wireguard tools work just fine

Re: WireGuard Gives Linux a Faster, More Secure VPN

#255
post #5

Is there a version of Ubuntu that has GUI NetworkManager support for WireGuard? I’m missing the convenience of toggling the VPN on and off from the system menu.

Agreed. I have Wireguard installed, but am positive I don't have it configured properly.

it's pretty hard to misconfigure it, and then it either works or it doesn't.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#256
post #175

I really like wireguard, but one thing that bugs me is the fact that it's layer 3 (an ip tunnel) and has no code to support layer 2 (ethernet MAC tunnel). The downside for me is that you have to manage static ips in the configurations (specifically it's not compatible with ipv6 slaac and NDP). There is https://git.zx2c4.com/wg-dynamic but it's very experimental at the moment. The level 3-only tunnel is motivated as "…

It should be possible to run GRE, L2TP, or VXLAN over WireGuard although such tooling probably doesn't exist yet.

I've run VXLAN over top of wireguard connections. One advantage is that you can have multiple intermediate wireguard connections that are not visible at the VXLAN layer.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#257
post #232

Earlier quoted context omitted.

Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. The Web PKI is something we live with because we have to, not something anyone sets out to re-create. There are organizations that benefit from a PKI-ier deployment of SSH, but even there, the "I" part of the PKI is extremely attenuated, and most of the real interesting work is done by a single centralized p…

> Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point. I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends. > The Web PKI is something we live with because we have to, not something anyone sets out to re-create. We have to because it's crucial. If public key attestation…

> > Neither Signal nor SSH in their most common mode of use have a "PKI" in the sense you mean, which is my point.

> I assume then that you exchange the public keys of your Signal contacts over SMS. Over perhaps you scp them to a server you share with friends.

You are meant to verify your contacts' keys (aka "safety numbers") either in-person or otherwise out-of-band. The Signal server does not in any way sign or endorse the identity keys they serve to users (yes, they're delivered over TLS but that doesn't count).

Yes, Signal does do some best-effort verification of your phone number when you register a device but that's just to avoid DoS. SMS can be easily intercepted.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#258
post #167

Earlier quoted context omitted.

Someone else said broadcast/multicast, so I'll also add communication with legacy systems that don't speak IP or have other wacky requirements. These do exist in industrial and embedded settings. It's a niche use case but it's very useful there.

I suspect Novel/IPX is still out there

I went through training on it back in 2012 - apparently it (at least at the time, not sure about now) was dominant in the australian mining industry, so the larger tertiary education providers were requested to at least familiarise students with it.

It was a strange beast but there were a few odd spots it was better than active directory - e.g. an "Organizational Role" could be created and have a user assigned to it, so you could more easily seperate the user (john smith) from their position and the permissions that go with it (finance director). So when john smith retires it is trivial to replace the occupant of the finance director organisational role.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#259

Earlier quoted context omitted.

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.

And that is a good thing.

Re: WireGuard Gives Linux a Faster, More Secure VPN

#260

Earlier quoted context omitted.

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.

The same was true of TLS!
Post reply on HN