* Allowed IPs Toggling @ 2018-03-15 15:31 Gianluca Gabrielli 2018-03-15 15:56 ` Samuel Holland 0 siblings, 1 reply; 7+ messages in thread From: Gianluca Gabrielli @ 2018-03-15 15:31 UTC (permalink / raw) To: WireGuard mailing list Hi folks, I was setting two peers on the server, but every time I re-add one of these= two the other one is shown with (none) on "allowed ips" field. Of course t= hat blocks communications with that peer. If I try to re-add it, then the other peer loses its configuration, same pr= oblem.=20 I also uploaded a screenshot to show what happen: http://b1.ge.tt/thumbnail= /9mHe41p2/0/user-FmSzCRxxFYeJWFrs22ANXjgqdUW3IX7GvUIDb-/0x675.png I'm pretty sure that is not a bug, but my fault about some misconfiguration= .... anyone knows what I'm doing wrong?? Cheers, Gianluca ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-15 15:31 Allowed IPs Toggling Gianluca Gabrielli @ 2018-03-15 15:56 ` Samuel Holland 2018-03-15 18:39 ` Steve Gilberd 0 siblings, 1 reply; 7+ messages in thread From: Samuel Holland @ 2018-03-15 15:56 UTC (permalink / raw) To: Gianluca Gabrielli, WireGuard mailing list Hello, On 03/15/18 10:31, Gianluca Gabrielli wrote: > I was setting two peers on the server, but every time I re-add one of these > two the other one is shown with (none) on "allowed ips" field. Of course that > blocks communications with that peer. If I try to re-add it, then the other > peer loses its configuration, same problem. Allowed IPs is like a routing table; you can't have two routes for the same set of IPs, or WireGuard doesn't know which peer to send the traffic to. You want to have non-overlapping Allowed IP ranges. This usually means that the range of Allowed IPs is smaller than the host's subnet. For example: Host A: IP configuration for WireGuard interface: 192.168.123.1/24 Allowed IPs for Host B: 192.168.123.2/32 Host B: IP configuration for WireGuard interface: 192.168.123.2/24 Allowed IPs for Host A: 192.168.123.1/32 The IP configuration tells the kernel which IP ranges are accessible via the WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of those IPs is associated with each peer. > Cheers, > Gianluca Cheers, Samuel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-15 15:56 ` Samuel Holland @ 2018-03-15 18:39 ` Steve Gilberd 2018-03-15 18:51 ` Samuel Holland 2018-03-16 2:12 ` Tim Sedlmeyer 0 siblings, 2 replies; 7+ messages in thread From: Steve Gilberd @ 2018-03-15 18:39 UTC (permalink / raw) To: Samuel Holland; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 2474 bytes --] > Allowed IPs is like a routing table; you can't have two routes for the same set of IPs If this is the case, then wireguard does not have proper routing support. Normally, routing tables allow both multiple and overlapping routes present. When making routing decisions, the most-specific route is chosen (e.g. a /29 is higher priority than a /24 which overlaps with it). If there are two identical routes of the same size, then the one with the lowest routing metric is used. I can understand not allowing identical routes of the same size, as wireguard doesn't really have a concept of metric (although it could be useful for backup links). However, it really should allow overlapping routes of different sizes. There's no ambiguity with routing decisions, and it's a standard feature that I would normally expect any IP routing stack to have. Cheers, Steve On Fri, 16 Mar 2018, 04:57 Samuel Holland, <samuel@sholland.org> wrote: > Hello, > > On 03/15/18 10:31, Gianluca Gabrielli wrote: > > I was setting two peers on the server, but every time I re-add one of > these > > two the other one is shown with (none) on "allowed ips" field. Of course > that > > blocks communications with that peer. If I try to re-add it, then the > other > > peer loses its configuration, same problem. > > Allowed IPs is like a routing table; you can't have two routes for the > same set > of IPs, or WireGuard doesn't know which peer to send the traffic to. You > want to > have non-overlapping Allowed IP ranges. This usually means that the range > of > Allowed IPs is smaller than the host's subnet. For example: > > Host A: > IP configuration for WireGuard interface: 192.168.123.1/24 > Allowed IPs for Host B: 192.168.123.2/32 > > Host B: > IP configuration for WireGuard interface: 192.168.123.2/24 > Allowed IPs for Host A: 192.168.123.1/32 > > The IP configuration tells the kernel which IP ranges are accessible via > the > WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of > those IPs > is associated with each peer. > > > Cheers, > > Gianluca > > Cheers, > Samuel > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > -- Cheers, *Steve Gilberd* Erayd LTD *·* Consultant *Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237* *PO Box 10019 The Terrace, Wellington 6143, NZ* [-- Attachment #2: Type: text/html, Size: 3722 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-15 18:39 ` Steve Gilberd @ 2018-03-15 18:51 ` Samuel Holland 2018-03-15 18:55 ` Steve Gilberd 2018-03-16 2:12 ` Tim Sedlmeyer 1 sibling, 1 reply; 7+ messages in thread From: Samuel Holland @ 2018-03-15 18:51 UTC (permalink / raw) To: Steve Gilberd; +Cc: WireGuard mailing list Hello, On 03/15/18 13:39, Steve Gilberd wrote: >> Allowed IPs is like a routing table; you can't have two routes for the same > set of IPs > > If this is the case, then wireguard does not have proper routing support. > > Normally, routing tables allow both multiple and overlapping routes present. > When making routing decisions, the most-specific route is chosen (e.g. a /29 is > higher priority than a /24 which overlaps with it). If there are two identical > routes of the same size, then the one with the lowest routing metric is used. > > I can understand not allowing identical routes of the same size, as wireguard > doesn't really have a concept of metric (although it could be useful for backup > links). However, it really should allow overlapping routes of different sizes. > There's no ambiguity with routing decisions, and it's a standard feature that I > would normally expect any IP routing stack to have. WireGuard *does* support overlapping ranges of AllowedIPs on different peers. It doesn't support having *identical* ranges of AllowedIPs on different peers, which was the situation here. (You're correct, there's no concept of a metric.) > Cheers, > Steve Cheers, Samuel ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-15 18:51 ` Samuel Holland @ 2018-03-15 18:55 ` Steve Gilberd 0 siblings, 0 replies; 7+ messages in thread From: Steve Gilberd @ 2018-03-15 18:55 UTC (permalink / raw) To: Samuel Holland; +Cc: WireGuard mailing list [-- Attachment #1: Type: text/plain, Size: 2018 bytes --] > WireGuard *does* support overlapping ranges of AllowedIPs on different peers. It > doesn't support having *identical* ranges of AllowedIPs on different peers, > which was the situation here. (You're correct, there's no concept of a metric.) Oh good - looks like I just misunderstood your ordinal email then; I thought you were saying that any situation with multiple routes to a single IP was unsupported. Thanks for clarifying :-). Cheers, Steve On Fri, 16 Mar 2018, 07:51 Samuel Holland, <samuel@sholland.org> wrote: > Hello, > > On 03/15/18 13:39, Steve Gilberd wrote: > >> Allowed IPs is like a routing table; you can't have two routes for the > same > > set of IPs > > > > If this is the case, then wireguard does not have proper routing support. > > > > Normally, routing tables allow both multiple and overlapping routes > present. > > When making routing decisions, the most-specific route is chosen (e.g. a > /29 is > > higher priority than a /24 which overlaps with it). If there are two > identical > > routes of the same size, then the one with the lowest routing metric is > used. > > > > I can understand not allowing identical routes of the same size, as > wireguard > > doesn't really have a concept of metric (although it could be useful for > backup > > links). However, it really should allow overlapping routes of different > sizes. > > There's no ambiguity with routing decisions, and it's a standard feature > that I > > would normally expect any IP routing stack to have. > > WireGuard *does* support overlapping ranges of AllowedIPs on different > peers. It > doesn't support having *identical* ranges of AllowedIPs on different peers, > which was the situation here. (You're correct, there's no concept of a > metric.) > > > Cheers, > > Steve > > Cheers, > Samuel > -- Cheers, *Steve Gilberd* Erayd LTD *·* Consultant *Phone: +64 4 974-4229 **·** Mob: +64 27 565-3237* *PO Box 10019 The Terrace, Wellington 6143, NZ* [-- Attachment #2: Type: text/html, Size: 2815 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-15 18:39 ` Steve Gilberd 2018-03-15 18:51 ` Samuel Holland @ 2018-03-16 2:12 ` Tim Sedlmeyer 2018-03-16 12:44 ` Gianluca Gabrielli 1 sibling, 1 reply; 7+ messages in thread From: Tim Sedlmeyer @ 2018-03-16 2:12 UTC (permalink / raw) To: Steve Gilberd; +Cc: WireGuard mailing list Allowed-ips plays a variety of roles which at different times can be mapped to several traditional network roles but one it doesn't really play the role of routing table. Instead they act as a forwarding information base for the wireguard interface matching ip addresses to peers. Wireguard then makes forwarding not routing decisions based upon this "FIB". Since it is acting as a FIB at any given time it can contain only a single destination for any given entry. If you want support for things like equal cost multipath (something that will never be possible over peers on the same interface), route failover and metric weighted routing than a routing process must get involved to make the routing decisions, populate the routing table and then manage entries in the "FIB" based upon the routing table. As it stands today there are not, at least not readily publicly available, any routing processes which can interact with WireGuard to do so. This is why today to do any sort of dynamic routing with wireguard the peers involved need to be assigned to different interfaces and allowed-ips on them set to 0.0.0.0/0 or the total subset of ip addresses which might ever traverse a peer under any routing situation. Existing routing processes can then just treat them as traditional interfaces and not worry about updating the "FIB". On Thu, Mar 15, 2018 at 2:39 PM, Steve Gilberd <steve@erayd.net> wrote: >> Allowed IPs is like a routing table; you can't have two routes for the >> same set of IPs > > If this is the case, then wireguard does not have proper routing support. > > Normally, routing tables allow both multiple and overlapping routes prese= nt. > When making routing decisions, the most-specific route is chosen (e.g. a = /29 > is higher priority than a /24 which overlaps with it). If there are two > identical routes of the same size, then the one with the lowest routing > metric is used. > > I can understand not allowing identical routes of the same size, as > wireguard doesn't really have a concept of metric (although it could be > useful for backup links). However, it really should allow overlapping rou= tes > of different sizes. There's no ambiguity with routing decisions, and it's= a > standard feature that I would normally expect any IP routing stack to hav= e. > > Cheers, > Steve > > > On Fri, 16 Mar 2018, 04:57 Samuel Holland, <samuel@sholland.org> wrote: >> >> Hello, >> >> On 03/15/18 10:31, Gianluca Gabrielli wrote: >> > I was setting two peers on the server, but every time I re-add one of >> > these >> > two the other one is shown with (none) on "allowed ips" field. Of cour= se >> > that >> > blocks communications with that peer. If I try to re-add it, then the >> > other >> > peer loses its configuration, same problem. >> >> Allowed IPs is like a routing table; you can't have two routes for the >> same set >> of IPs, or WireGuard doesn't know which peer to send the traffic to. You >> want to >> have non-overlapping Allowed IP ranges. This usually means that the rang= e >> of >> Allowed IPs is smaller than the host's subnet. For example: >> >> Host A: >> IP configuration for WireGuard interface: 192.168.123.1/24 >> Allowed IPs for Host B: 192.168.123.2/32 >> >> Host B: >> IP configuration for WireGuard interface: 192.168.123.2/24 >> Allowed IPs for Host A: 192.168.123.1/32 >> >> The IP configuration tells the kernel which IP ranges are accessible via >> the >> WireGuard interface. The Allowed IPs tell WireGuard, which _subset_ of >> those IPs >> is associated with each peer. >> >> > Cheers, >> > Gianluca >> >> Cheers, >> Samuel >> _______________________________________________ >> WireGuard mailing list >> WireGuard@lists.zx2c4.com >> https://lists.zx2c4.com/mailman/listinfo/wireguard > > -- > > Cheers, > > Steve Gilberd > Erayd LTD =C2=B7 Consultant > Phone: +64 4 974-4229 =C2=B7 Mob: +64 27 565-3237 > PO Box 10019 The Terrace, Wellington 6143, NZ > > > _______________________________________________ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Allowed IPs Toggling 2018-03-16 2:12 ` Tim Sedlmeyer @ 2018-03-16 12:44 ` Gianluca Gabrielli 0 siblings, 0 replies; 7+ messages in thread From: Gianluca Gabrielli @ 2018-03-16 12:44 UTC (permalink / raw) To: Tim Sedlmeyer; +Cc: WireGuard mailing list Thanks very much to everybody, like always professional and straight to the= point! One of the best ml ever :) Cheers, Gianluca ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2018-03-16 12:34 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-03-15 15:31 Allowed IPs Toggling Gianluca Gabrielli 2018-03-15 15:56 ` Samuel Holland 2018-03-15 18:39 ` Steve Gilberd 2018-03-15 18:51 ` Samuel Holland 2018-03-15 18:55 ` Steve Gilberd 2018-03-16 2:12 ` Tim Sedlmeyer 2018-03-16 12:44 ` Gianluca Gabrielli
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).