Overlapping AllowedIPs Configuration

Overlapping AllowedIPs Configuration

[Aleksa Sarai]

[-- 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

Re: Overlapping AllowedIPs Configuration

[Henning Reich]

[-- 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 --]

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

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

Re: Overlapping AllowedIPs Configuration

[Aleksa Sarai]

[-- 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

Re: Overlapping AllowedIPs Configuration

[Paul Zillmann]

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

Re: Overlapping AllowedIPs Configuration

[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

Re: Overlapping AllowedIPs Configuration

[Ivan Labáth]

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

Re: Overlapping AllowedIPs Configuration

[Matthias Urlichs]

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

Re: Overlapping AllowedIPs Configuration

[Paul Zillmann]

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

Re: Overlapping AllowedIPs Configuration

[Markus Grundmann]

[-- 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 --]

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

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

Re: Overlapping AllowedIPs Configuration

[Vincent Wiemann]

> 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