WireGuard Archive on lore.kernel.org
 help / color / Atom feed
* Overlapping AllowedIPs Configuration
@ 2019-05-06 21:08 Aleksa Sarai
  2019-05-11 15:19 ` Henning Reich
  2019-05-25 18:39 ` Paul Zillmann
  0 siblings, 2 replies; 10+ messages in thread
From: Aleksa Sarai @ 2019-05-06 21:08 UTC (permalink / raw)
  To: wireguard

[-- Attachment #1.1: Type: text/plain, Size: 1880 bytes --]

Hi all,

I just found out that WireGuard apparently allows you to configure an
interface that has peers with overlapping AllowedIPs ranges -- which
obviously won't work with cryptokey routing -- but additionally is
strange since I feel this should cause an error when configuring the
interface.

In my case, I accidentally used /32 when generating the IPv6 addresses
of my clients and ended up with a config like:

  [Interface]
  Address = 10.13.37.1/32,fd00:dead:beef:cafe::1/64
  ListenPort = 51820
  PrivateKey = [key]

  # Peer A.
  [Peer]
  PublicKey = [pub]
  PreSharedKey = [psk]
  AllowedIPs = 10.13.40.1/32,fd00:dead:beef:1000::/32

  # Peer B.
  [Peer]
  PublicKey = [pub]
  PreSharedKey = [psk]
  AllowedIPs = 10.13.41.1/32,fd00:dead:beef:1001::/32

This config is wrong (because both peers have overlapping addresses
specified for AllowedIPs), but wireguard will happily accept it:

  % wg-quick up wg-foo
  [#] ip link add wg-yavin type wireguard
  [#] wg setconf wg-yavin /dev/fd/63
  [#] ip address add 10.13.37.1/32 dev wg-yavin
  [#] ip address add fd00:dead:beef:cafe::1/64 dev wg-yavin
  [#] ip link set mtu 1420 up dev wg-yavin
  [#] ip route add fd42:dead::/32 dev wg-yavin
  [#] ip route add 10.13.41.1/32 dev wg-yavin
  [#] ip route add 10.13.40.1/32 dev wg-yavin

This configuration results in only one of the peers actually being given
the IPv6 range, but I feel like "wg setconf" should've rejected this
configuration.

  % wg
  interface: wg-foo
    public key: [pub]
    private key: (hidden)
    listening port: 51820

  peer: [peer A]
    preshared key: (hidden)
    allowed ips: 10.13.40.1/32

  peer: [peer B]
    preshared key: (hidden)
    allowed ips: 10.13.41.1/32, fd42:dead::/32

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

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

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  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
  1 sibling, 1 reply; 10+ messages in thread
From: Henning Reich @ 2019-05-11 15:19 UTC (permalink / raw)
  To: Aleksa Sarai; +Cc: WireGuard mailing list

[-- Attachment #1.1: Type: text/plain, Size: 2536 bytes --]

No, I think its correct behaviour.
If you have overlapping networks  the more specific route is preferred.
10.10.10.0/24 overrule 10.10.0.0/16.
If the subnets are the same, the last one is the more specific (because
most recent one) and should be used.

And in germany, we say (literal translation): You're allowed to shoot
yourself in the knee.
(to be self-defeating) :-)



Aleksa Sarai <cyphar@cyphar.com> schrieb am Sa., 11. Mai 2019, 15:09:

> Hi all,
>
> I just found out that WireGuard apparently allows you to configure an
> interface that has peers with overlapping AllowedIPs ranges -- which
> obviously won't work with cryptokey routing -- but additionally is
> strange since I feel this should cause an error when configuring the
> interface.
>
> In my case, I accidentally used /32 when generating the IPv6 addresses
> of my clients and ended up with a config like:
>
>   [Interface]
>   Address = 10.13.37.1/32,fd00:dead:beef:cafe::1/64
>   ListenPort = 51820
>   PrivateKey = [key]
>
>   # Peer A.
>   [Peer]
>   PublicKey = [pub]
>   PreSharedKey = [psk]
>   AllowedIPs = 10.13.40.1/32,fd00:dead:beef:1000::/32
>
>   # Peer B.
>   [Peer]
>   PublicKey = [pub]
>   PreSharedKey = [psk]
>   AllowedIPs = 10.13.41.1/32,fd00:dead:beef:1001::/32
>
> This config is wrong (because both peers have overlapping addresses
> specified for AllowedIPs), but wireguard will happily accept it:
>
>   % wg-quick up wg-foo
>   [#] ip link add wg-yavin type wireguard
>   [#] wg setconf wg-yavin /dev/fd/63
>   [#] ip address add 10.13.37.1/32 dev wg-yavin
>   [#] ip address add fd00:dead:beef:cafe::1/64 dev wg-yavin
>   [#] ip link set mtu 1420 up dev wg-yavin
>   [#] ip route add fd42:dead::/32 dev wg-yavin
>   [#] ip route add 10.13.41.1/32 dev wg-yavin
>   [#] ip route add 10.13.40.1/32 dev wg-yavin
>
> This configuration results in only one of the peers actually being given
> the IPv6 range, but I feel like "wg setconf" should've rejected this
> configuration.
>
>   % wg
>   interface: wg-foo
>     public key: [pub]
>     private key: (hidden)
>     listening port: 51820
>
>   peer: [peer A]
>     preshared key: (hidden)
>     allowed ips: 10.13.40.1/32
>
>   peer: [peer B]
>     preshared key: (hidden)
>     allowed ips: 10.13.41.1/32, fd42:dead::/32
>
> --
> Aleksa Sarai
> Senior Software Engineer (Containers)
> SUSE Linux GmbH
> <https://www.cyphar.com/>
> _______________________________________________
> WireGuard mailing list
> WireGuard@lists.zx2c4.com
> https://lists.zx2c4.com/mailman/listinfo/wireguard
>

[-- Attachment #1.2: Type: text/html, Size: 4288 bytes --]

<div dir="auto">No, I think its correct behaviour.<div dir="auto">If you have overlapping networks  the more specific route is preferred. <a href="http://10.10.10.0/24">10.10.10.0/24</a> overrule <a href="http://10.10.0.0/16">10.10.0.0/16</a>.</div><div dir="auto">If the subnets are the same, the last one is the more specific (because most recent one) and should be used.</div><div dir="auto"><br></div><div dir="auto">And in germany, we say (literal translation): You&#39;re allowed to shoot yourself in the knee.</div><div dir="auto">(to be self-defeating) :-)</div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Aleksa Sarai &lt;<a href="mailto:cyphar@cyphar.com">cyphar@cyphar.com</a>&gt; schrieb am Sa., 11. Mai 2019, 15:09:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
I just found out that WireGuard apparently allows you to configure an<br>
interface that has peers with overlapping AllowedIPs ranges -- which<br>
obviously won&#39;t work with cryptokey routing -- but additionally is<br>
strange since I feel this should cause an error when configuring the<br>
interface.<br>
<br>
In my case, I accidentally used /32 when generating the IPv6 addresses<br>
of my clients and ended up with a config like:<br>
<br>
  [Interface]<br>
  Address = <a href="http://10.13.37.1/32,fd00:dead:beef:cafe::1/64" rel="noreferrer noreferrer" target="_blank">10.13.37.1/32,fd00:dead:beef:cafe::1/64</a><br>
  ListenPort = 51820<br>
  PrivateKey = [key]<br>
<br>
  # Peer A.<br>
  [Peer]<br>
  PublicKey = [pub]<br>
  PreSharedKey = [psk]<br>
  AllowedIPs = <a href="http://10.13.40.1/32,fd00:dead:beef:1000::/32" rel="noreferrer noreferrer" target="_blank">10.13.40.1/32,fd00:dead:beef:1000::/32</a><br>
<br>
  # Peer B.<br>
  [Peer]<br>
  PublicKey = [pub]<br>
  PreSharedKey = [psk]<br>
  AllowedIPs = <a href="http://10.13.41.1/32,fd00:dead:beef:1001::/32" rel="noreferrer noreferrer" target="_blank">10.13.41.1/32,fd00:dead:beef:1001::/32</a><br>
<br>
This config is wrong (because both peers have overlapping addresses<br>
specified for AllowedIPs), but wireguard will happily accept it:<br>
<br>
  % wg-quick up wg-foo<br>
  [#] ip link add wg-yavin type wireguard<br>
  [#] wg setconf wg-yavin /dev/fd/63<br>
  [#] ip address add <a href="http://10.13.37.1/32" rel="noreferrer noreferrer" target="_blank">10.13.37.1/32</a> dev wg-yavin<br>
  [#] ip address add fd00:dead:beef:cafe::1/64 dev wg-yavin<br>
  [#] ip link set mtu 1420 up dev wg-yavin<br>
  [#] ip route add fd42:dead::/32 dev wg-yavin<br>
  [#] ip route add <a href="http://10.13.41.1/32" rel="noreferrer noreferrer" target="_blank">10.13.41.1/32</a> dev wg-yavin<br>
  [#] ip route add <a href="http://10.13.40.1/32" rel="noreferrer noreferrer" target="_blank">10.13.40.1/32</a> dev wg-yavin<br>
<br>
This configuration results in only one of the peers actually being given<br>
the IPv6 range, but I feel like &quot;wg setconf&quot; should&#39;ve rejected this<br>
configuration.<br>
<br>
  % wg<br>
  interface: wg-foo<br>
    public key: [pub]<br>
    private key: (hidden)<br>
    listening port: 51820<br>
<br>
  peer: [peer A]<br>
    preshared key: (hidden)<br>
    allowed ips: <a href="http://10.13.40.1/32" rel="noreferrer noreferrer" target="_blank">10.13.40.1/32</a><br>
<br>
  peer: [peer B]<br>
    preshared key: (hidden)<br>
    allowed ips: <a href="http://10.13.41.1/32" rel="noreferrer noreferrer" target="_blank">10.13.41.1/32</a>, fd42:dead::/32<br>
<br>
-- <br>
Aleksa Sarai<br>
Senior Software Engineer (Containers)<br>
SUSE Linux GmbH<br>
&lt;<a href="https://www.cyphar.com/" rel="noreferrer noreferrer" target="_blank">https://www.cyphar.com/</a>&gt;<br>
_______________________________________________<br>
WireGuard mailing list<br>
<a href="mailto:WireGuard@lists.zx2c4.com" target="_blank" rel="noreferrer">WireGuard@lists.zx2c4.com</a><br>
<a href="https://lists.zx2c4.com/mailman/listinfo/wireguard" rel="noreferrer noreferrer" target="_blank">https://lists.zx2c4.com/mailman/listinfo/wireguard</a><br>
</blockquote></div>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-05-11 15:19 ` Henning Reich
@ 2019-05-11 17:11   ` Aleksa Sarai
  0 siblings, 0 replies; 10+ messages in thread
From: Aleksa Sarai @ 2019-05-11 17:11 UTC (permalink / raw)
  To: Henning Reich; +Cc: WireGuard mailing list

[-- Attachment #1.1: Type: text/plain, Size: 952 bytes --]

On 2019-05-11, Henning Reich <henningreich@gmail.com> wrote:
> No, I think its correct behaviour.
> If you have overlapping networks  the more specific route is preferred.
> 10.10.10.0/24 overrule 10.10.0.0/16.
> If the subnets are the same, the last one is the more specific (because
> most recent one) and should be used.

But none of the AllowedIPs is "more specific" -- they're all /32.

In addition, the preferred one is the last one in the config file
(presumably because it gets configured last) even if you use more
specific route earlier in the config.

> And in germany, we say (literal translation): You're allowed to shoot
> yourself in the knee. (to be self-defeating) :-)

In English we say "shooting yourself in the foot" (hence a "foot-gun").
But I'd argue that you should avoid designing foot-guns when possible.

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

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

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-05-06 21:08 Overlapping AllowedIPs Configuration Aleksa Sarai
  2019-05-11 15:19 ` Henning Reich
@ 2019-05-25 18:39 ` Paul Zillmann
  2019-06-06 10:09   ` Toke Høiland-Jørgensen
  2019-06-08  7:32   ` Markus Grundmann
  1 sibling, 2 replies; 10+ messages in thread
From: Paul Zillmann @ 2019-05-25 18:39 UTC (permalink / raw)
  To: wireguard; +Cc: henningreich

Hello,

we have the same problem here, although our allowed IP ranges should be 
0.0.0.0/0 for all peers.
We have OSPF traffic on the wireguard links so it should be task of the 
Kernel's routing table to decide where to send what.

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. Right now Wireguard isn't very friendly 
to dynamic routing.

I came up with multiple solutions:
- create multiple interfaces + tunnels.
or
- create a bash script that injects the Kernel's routing table into the 
wg tool every other minute.

Do you guys have a better idea? If not I would create the bash script.

- Paul
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  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
  2019-06-07 23:58     ` Paul Zillmann
  2019-06-08  7:32   ` Markus Grundmann
  1 sibling, 2 replies; 10+ messages in thread
From: Toke Høiland-Jørgensen @ 2019-06-06 10:09 UTC (permalink / raw)
  To: Paul Zillmann, wireguard; +Cc: henningreich

Paul Zillmann <paul@zil.li> writes:

> Hello,
>
> we have the same problem here, although our allowed IP ranges should be 
> 0.0.0.0/0 for all peers.
> We have OSPF traffic on the wireguard links so it should be task of the 
> Kernel's routing table to decide where to send what.
>
> 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.

> Right now Wireguard isn't very friendly to dynamic routing.
>
> I came up with multiple solutions:
> - create multiple interfaces + tunnels.
> or
> - create a bash script that injects the Kernel's routing table into the 
> wg tool every other minute.
>
> Do you guys have a better idea? If not I would create the bash script.

IMO, the "right" way to fix this is to make your routing daemon aware of
wireguard and have it configure the routes directly into the wireguard
table. That also gives you security for your routing protocol
automatically (since only authenticated sources/destinations will be
allowed), as long as you have a secure way of bootstrapping the
wireguard keying.

-Toke
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-06-06 10:09   ` Toke Høiland-Jørgensen
@ 2019-06-07  8:05     ` Ivan Labáth
  2019-06-07 10:07       ` Matthias Urlichs
  2019-06-07 23:58     ` Paul Zillmann
  1 sibling, 1 reply; 10+ messages in thread
From: Ivan Labáth @ 2019-06-07  8:05 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen; +Cc: henningreich, wireguard

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-06-07  8:05     ` Ivan Labáth
@ 2019-06-07 10:07       ` Matthias Urlichs
  2019-06-13  7:29         ` Vincent Wiemann
  0 siblings, 1 reply; 10+ messages in thread
From: Matthias Urlichs @ 2019-06-07 10:07 UTC (permalink / raw)
  To: wireguard

On 07.06.19 10:05, Ivan Labáth wrote:
> 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.

It might be helpful to have an option that disallows (silently)
replacing another peer's route.

-- 
-- mit freundlichen Grüßen
-- 
-- Matthias Urlichs

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-06-06 10:09   ` Toke Høiland-Jørgensen
  2019-06-07  8:05     ` Ivan Labáth
@ 2019-06-07 23:58     ` Paul Zillmann
  1 sibling, 0 replies; 10+ messages in thread
From: Paul Zillmann @ 2019-06-07 23:58 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, wireguard; +Cc: henningreich

Hello Toke,

thanks for your information.
I've seen a topic came up on the bird user mailing list which you have 
had crosslinked here.

In the mean time I've created this little python script: 
https://github.com/pzillmann/wireguard-dynamic-routing

At least it does the job for me. I think Janne's code needs some time go 
get integrated into upstream plus a few days until it is shipped with 
the distributions. (Maybe we see it in Debian 10?)

Until then there is this script. Feel free to give me some feedback.

- Paul

Am 06.06.19 um 12:09 schrieb Toke Høiland-Jørgensen:
> Paul Zillmann <paul@zil.li> writes:
>
>> Hello,
>>
>> we have the same problem here, although our allowed IP ranges should be
>> 0.0.0.0/0 for all peers.
>> We have OSPF traffic on the wireguard links so it should be task of the
>> Kernel's routing table to decide where to send what.
>>
>> 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.
>
>> Right now Wireguard isn't very friendly to dynamic routing.
>>
>> I came up with multiple solutions:
>> - create multiple interfaces + tunnels.
>> or
>> - create a bash script that injects the Kernel's routing table into the
>> wg tool every other minute.
>>
>> Do you guys have a better idea? If not I would create the bash script.
> IMO, the "right" way to fix this is to make your routing daemon aware of
> wireguard and have it configure the routes directly into the wireguard
> table. That also gives you security for your routing protocol
> automatically (since only authenticated sources/destinations will be
> allowed), as long as you have a secure way of bootstrapping the
> wireguard keying.
>
> -Toke

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-05-25 18:39 ` Paul Zillmann
  2019-06-06 10:09   ` Toke Høiland-Jørgensen
@ 2019-06-08  7:32   ` Markus Grundmann
  1 sibling, 0 replies; 10+ messages in thread
From: Markus Grundmann @ 2019-06-08  7:32 UTC (permalink / raw)
  To: Paul Zillmann; +Cc: henningreich, wireguard

[-- Attachment #1.1: Type: text/plain, Size: 546 bytes --]

I'm running a full meshed WireGuard-based Network between three ASN with
BIRD 1.6.4 & 2.0.4 over OSPFv2/v3 without any issues. When I configure
my transport networks I use the following "allowed-ips" schema:
<a.b.c.d/30>,224.0.0.5/32,0.0.0.0/0,::/0 

a.b.c.d = transport network 

I know some networks are redundent but it works very fine in my case
over LTE, DSL and some other L2 links. 

Regards, 

Markus 

Am 2019-05-25 20:39, schrieb Paul Zillmann:

> make this behavior optional. Right now Wireguard isn't very friendly to dynamic routing.

[-- Attachment #1.2: Type: text/html, Size: 1029 bytes --]

<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt'>
<p>I'm running a full meshed WireGuard-based Network between three ASN with BIRD 1.6.4 &amp; 2.0.4 over OSPFv2/v3 without any issues. When I configure my transport networks I use the following "allowed-ips" schema: &lt;a.b.c.d/30&gt;,224.0.0.5/32,0.0.0.0/0,::/0</p>
<p>a.b.c.d = transport network</p>
<p>I know some networks are redundent but it works very fine in my case over LTE, DSL and some other L2 links.</p>
<p>Regards,</p>
<p>Markus</p>
<p>Am 2019-05-25 20:39, schrieb Paul Zillmann:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ignored -->
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">make this behavior optional. Right now Wireguard isn't very friendly to dynamic routing.<br /> <span style="white-space: nowrap;"></span></div>
</blockquote>

</body></html>

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Overlapping AllowedIPs Configuration
  2019-06-07 10:07       ` Matthias Urlichs
@ 2019-06-13  7:29         ` Vincent Wiemann
  0 siblings, 0 replies; 10+ messages in thread
From: Vincent Wiemann @ 2019-06-13  7:29 UTC (permalink / raw)
  To: Matthias Urlichs, wireguard


> we have the same problem here, although our allowed IP ranges should be
> 0.0.0.0/0 for all peers.
> We have OSPF traffic on the wireguard links so it should be task of the
> Kernel's routing table to decide where to send what.

This is not possible with a layer 3 tunnel as the kernel routing table only
knows which route goes to which interface.
I'm working on a layer 2 WireGuard version, but due to lack of funding and free-time
it is not in a state in which I'd like to release it.

As already stated there is still the possibility to use a separate
WireGuard interface per peer or let OSPF set WireGuard's peer's routes which
requires a modification of the OSPF daemon.

On 07.06.19 12:07, Matthias Urlichs wrote:> On 07.06.19 10:05, Ivan Labáth wrote:
>> 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.
>
> It might be helpful to have an option that disallows (silently)
> replacing another peer's route.

As far as I understand, this should not happen at all as overlapping peers
should not be allowed as this breaks cryptokey-routing.

Regards,

Vincent Wiemann
_______________________________________________
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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
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

WireGuard Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/wireguard/0 wireguard/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 wireguard wireguard/ https://lore.kernel.org/wireguard \
		wireguard@lists.zx2c4.com zx2c4-wireguard@archiver.kernel.org
	public-inbox-index wireguard


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/com.zx2c4.lists.wireguard


AGPL code for this site: git clone https://public-inbox.org/ public-inbox