Development discussion of WireGuard
 help / color / mirror / Atom feed
From: "Daniel Gröber" <dxld@darkboxed.org>
To: Juliusz Chroboczek <jch@irif.fr>
Cc: Kyle Rose <krose@krose.org>,
	bird-users@network.cz, babel-users@alioth-lists.debian.net,
	wireguard@lists.zx2c4.com
Subject: Re: [RFC] Replace WireGuard AllowedIPs with IP route attribute
Date: Tue, 29 Aug 2023 00:13:12 +0200	[thread overview]
Message-ID: <20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at> (raw)
In-Reply-To: <87v8czqd3w.wl-jch@irif.fr>

[-- Attachment #1: Type: text/plain, Size: 1727 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  parent reply	other threads:[~2023-08-28 22:18 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19 14:02 Daniel Gröber
     [not found] ` <5112ea1f-0f67-4907-a3c5-b6c7b9e591ca@kr217.de>
2023-08-19 18:17   ` Daniel Gröber
2023-08-19 20:00 ` [Babel-users] " Steffen Vogel
2023-08-19 21:23   ` Daniel Gröber
2023-08-28 15:40     ` Kyle Rose
2023-08-28 16:07       ` Daniel Gröber
2023-08-28 17:40         ` Juliusz Chroboczek
2023-08-28 17:55           ` Kyle Rose
2023-08-28 22:13           ` Daniel Gröber [this message]
2023-09-03  3:21             ` Ivan Labáth
2023-09-29 13:12               ` Daniel Gröber
2023-09-29 16:19                 ` Reto
     [not found]             ` <804a0c0a-78df-7f4c-1d0d-213e8bdb4120@nic.cz>
2023-11-09 11:57               ` [Babel-users] " Alexander Zubkov
2023-11-18  2:19                 ` Daniel Gröber
     [not found]                   ` <918e1d5b-9f11-4f9c-bf9a-94cb0d41ce2b@app.fastmail.com>
2023-11-18 12:22                     ` Juliusz Chroboczek
2023-11-20  2:05                       ` Daniel Gröber
     [not found]                         ` <CABr+u0b6vrZoYzQcMiCXX7W0XsQRNMzQfZnT5cK1MQoZ4NoqkA@mail.gmail.com>
2023-11-22  7:39                           ` Daniel Gröber
2023-08-19 20:05 ` Kyle Rose

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230828221312.fw5pvnt4x7p2c52k@House.clients.dxld.at \
    --to=dxld@darkboxed.org \
    --cc=babel-users@alioth-lists.debian.net \
    --cc=bird-users@network.cz \
    --cc=jch@irif.fr \
    --cc=krose@krose.org \
    --cc=wireguard@lists.zx2c4.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).