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.