From: "Ivan Labáth" <labawi-wg@matrix-dream.net>
To: "Toke Høiland-Jørgensen" <toke@toke.dk>
Cc: henningreich@gmail.com, wireguard@lists.zx2c4.com
Subject: Re: Overlapping AllowedIPs Configuration
Date: Fri, 7 Jun 2019 08:05:07 +0000 [thread overview]
Message-ID: <20190607080507.GA26861@matrix-dream.net> (raw)
In-Reply-To: <87lfyfdnyu.fsf@toke.dk>
On Thu, Jun 06, 2019 at 12:09:45PM +0200, Toke Høiland-Jørgensen wrote:
> Paul Zillmann <paul@zil.li> writes:
..
> > The problem is that the allowed-ips configuration has multiple purposes:
> > routing table and firewall/packet filter. This introduces these
> > problems. It would be helpfull to get a compile flag or something else
> > to make this behavior optional.
>
> That is probably not going to happen; the crypto-routing is quite
> integral to Wireguard, and is an important security feature.
>
Disabling source filtering entirely is a bad idea, but permitting
non-routed (duplicate) inputs would be a useful feature for key-rotation,
failover and building resilient and/or exotic routing networks
without adding yet another layer of tunneling headers.
For example by separating parameters as:
AllowedIPs: A, B, C
RouteIPs: A, C
or set both:
IPs: A, C
As per the original question, I do find it strange, that a transient
modification of a peer can remove routes from another peer. Also
discarding routes in general, even more so when done silently.
Regards,
Ivan
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
next prev parent reply other threads:[~2019-06-07 8:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-06 21:08 Overlapping AllowedIPs Configuration Aleksa Sarai
2019-05-11 15:19 ` Henning Reich
2019-05-11 17:11 ` Aleksa Sarai
2019-05-25 18:39 ` Paul Zillmann
2019-06-06 10:09 ` Toke Høiland-Jørgensen
2019-06-07 8:05 ` Ivan Labáth [this message]
2019-06-07 10:07 ` Matthias Urlichs
2019-06-13 7:29 ` Vincent Wiemann
2019-06-07 23:58 ` Paul Zillmann
2019-06-08 7:32 ` Markus Grundmann
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=20190607080507.GA26861@matrix-dream.net \
--to=labawi-wg@matrix-dream.net \
--cc=henningreich@gmail.com \
--cc=toke@toke.dk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.