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

[Maria Matejka]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/babel-users/attachments/20230911/3b8975e5/attachment.htm>