Stanislas ๐Ÿ‘จโ€๐Ÿ’ป is a user on mstdn.io. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

@angristan @octobyte
I've mostly ignored it so far as "new hyped user-friendly supposedly-replacement of old tested more flexible solutions" but if Linus says the underlaying code is beautiful... I guess I'll have to look more into it.

@angristan @octobyte
Actually, I think what I didn't like about it is how it added stuff into the kernel instead of using tun/tap like everyone else.

But now that I look at it, it's pretty cool, but it gets one thing wrong. The same thing that was so fuckin' annoying with tun-mode OpenVPN:

It has an internal mapping from destination IP to peer.

@angristan @octobyte
Normally, network interfaces have internal mapping from link-layer address (eg. mac address) to peer, and need not be aware of IPs that are not on-link.

Eg, I can do
ip route add 10.13.37.0/24 via 192.168.0.13 dev eth7

and if eth7 only needs to know macaddress of 192.168.0.13. I don't need to tell it that packets to 10.13.37.0/24 should also go via that macaddress.

OTOH, with OpenVPN, I need to _also_ add `iroute 10.13.37.0/24` to the right peer's file in ccd.

@angristan @octobyte
And with WireGuard, I need to add whole 10.13.37.0/24 to that peer's AllowedIPs.
I wonder what happens when I add overlapping ranges to AllowedIPs of different peers, I guess everything breaks.

What I'd love to is if the VPN interface could use pubkey where ethernet interface uses mac address, so as to play nicely with other parts of the network stack (like routing table, firewalls, etc), and so that I don't need to have everything in two places.

@angristan @octobyte

Why even would a VPN be responsible for figuring out which peer is allowed to use which source IP addresses? That's the job of iptables!
I should be able to

iptables -A PREROUTING -m mac --mac-source SomePublicKeyInB64== ! -s 10.13.37.0/24 -j DROP

@angristan Wow, we get a big green light from Linus for something that is actually security-oriented! This is unusual. Great news for Jason and all the users.

@angristan I've never seen him so consistently positive about something on lkml

@angristan I've been using it between servers for about 2 months now (client's infrastructure involves many hetzner machines) because tinc wasn't coping any more (it's single threaded and can take about 5-600 Mbps in a good day)


maybe if it gets merged it will get actual networking system support (/etc/network/interfaces in debian and friends) instead of the systemd service abomination it currently uses