<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'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 <<a href="mailto:cyphar@cyphar.com">cyphar@cyphar.com</a>> 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'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 "wg setconf" should'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>
<<a href="https://www.cyphar.com/" rel="noreferrer noreferrer" target="_blank">https://www.cyphar.com/</a>><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>