[RFC] Replace WireGuard AllowedIPs with IP route attribute

[Ivan Labáth]

Hi,

IMO, a good tunnel solution may be if what is now called AllowedIPs,
were functionally split into:
 - AcceptIPS (to be different from AllowedIPs)
 - RouteIPs
Perhaps with a default shorthand of, say, IPs, setting both, as
AllowedIPs historically caused confusion wrt. it's meaning.

Wireguard API is a bit clunky, but I think one could dynamically manage
routes in reasonably efficient ways without extra interfaces and layers.

Not sure if it would fullfill all reasonably achievable goals.

Don't really have the time to implement anything, and I'm sure it would
not be easy, so just a possible tip to consider.

Regards,
Ivan Labáth

On Tue, Aug 29, 2023 at 12:13:12AM +0200, Daniel Gröber wrote:
> Hi Juliusz,
> 
> 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,
> just as an example, not that I'd actually ever need that many peers in my
> network :)
> 
> 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.
> 
> 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.
> 
> Other than that my `ip -br a` output is getting unmanagably long and having
> more than one device means I have to keep ACL lists in sync all over the
> system. This is a problem for daemons that don't support automatic reload
> (babeld for example :P). I also have to sync the set of interface to
> nftables which is easy to get wrong as it's still manual in my setup.
> 
> 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.
> 
> --Daniel