Re: [Babel-users] [RFC] Replace WireGuard AllowedIPs with IP route attribute

[Alexander Zubkov <green@qrator.net>]

Hello all,

I heard recently about the lightweight tunnel infrastructure in Linux
kernel (ip route ... encap ...). And I think this might be helpful in
the context of this thread. Linux kernel allows already to add
encapsulation parameters to the route entry in its table. So you do
not need to create tunnel devices for that. And wireguard
encapsulation and destination might be added there too. But as I
understood the technology, it works only in one way (for outgoing
packets) and the decapsulation should be processed separately, for
example in case of VXLAN and MPLS they have their own tables.

Regards,
Alexander Zubkov
Qrator Labs


On Mon, Sep 11, 2023 at 5:46 PM Maria Matejka via Bird-users
<bird-users@network.cz> wrote:
>
> Hello!
>
> On 8/29/23 00:13, Daniel Gröber wrote:
>
> On Mon, Aug 28, 2023 at 07:40:51PM +0200, Juliusz Chroboczek wrote:
>
> I've read the whole discussion, and I'm still not clear what advantages
> the proposed route attribute has over having one interface per peer.  Is
> it because interfaces are expensive in the Linux kernel?  Or is there some
> other reason why it is better to run all WG tunnels over a single interface?
>
> Off the top of my head UDP port exhaustion is a scalability concern here,
>
> For enterprise setups, this very easily _can_ get a scalability concern fairly easily.
>
> One wg-device per-peer means we need one UDP port per-peer and since
> currently binding to a specific IP is also not supported by wg (I have a
> patch pending for this though) there's no good way to work around this.
>
> There is a theoretical frankenstein approach, running a virtual machine (maybe netns is enough) for each of the public IP address, and connect them by veth. You do not want to do this, but theoretically, it should work.
>
> Frankly having tons of interfaces is just an operational PITA in all sorts
> of ways. Apart from the port exhaustion having more than one wg device also
> means I have to _allocate_ a new port for each node in my managment system
> somehow instead of just using a static port for the entire network. This
> gets dicy fast as I want to move in the direction of dynamic peering as in
> tinc.
>
> Even with my 6 machines running in weird locations, it's a mess.
>
> All of that could be solved, but I would also like to get my wg+babel VPN
> setup deployed more widely at some point and all that friction isn't going
> to help with that so I'd rather have this supported properly.
>
> All in all, I would also like to see this setup deployed worldwide. If we could somehow help on the BIRD side, please let us know.
>
> Thank you for bringing this up.
>
> --
> Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.