<div dir="ltr">Hi Norm,<div><br></div><div>I'm moving this discussion over to the mailing list. Please be sure to keep <a href="mailto:wireguard@lists.zx2c4.com">wireguard@lists.zx2c4.com</a> CC'd in your replies if you'd like a response.</div><div><br></div><div>Our prior conversation follows below.</div><div><br></div><div>Regards,</div><div>Jason</div><div><br><div class="gmail_quote"><span style="font-size:large;font-weight:bold">Forwarded conversation</span><br>Subject: <b class="gmail_sendername">WireGuard cryptokey routing</b><br>------------------------<br><br><span class="undefined"><font color="#888">From: <b class="undefined">Norman Shulman</b> <span dir="ltr"><<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>></span><br>Date: Tue, Jul 5, 2016 at 5:58 PM<br>To: <a href="mailto:team@wireguard.io">team@wireguard.io</a><br></font><br></span><br><div dir="ltr">You state:<div><br></div><div>"<br clear="all"><div>In the server configuration, when the network interface wants to send a packet to a peer (a client), it looks at that packet's destination IP and compares it to each peer's list of allowed IPs to see which peer to send it to. <br></div><div>...</div><div>In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table<br></div><div>"</div><div><br></div><div>But the allowed IPs can be non-routable addresses, so they are not necessarily unique.<br></div><span class="HOEnZb"><font color="#888888">
</font></span></div></div>
<br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Jason A. Donenfeld</b> <span dir="ltr"><<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>></span><br>Date: Tue, Jul 5, 2016 at 6:09 PM<br>To: Norman Shulman <<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>><br></font><br></span><br>Hi Norman,<br>
<br>
Can you expand what you mean a little bit by "not necessarily unique"?<br>
And why that matters? I'm not sure I understand the thrust of your<br>
point.<br>
<br>
Thanks,<br>
Jason<span class="HOEnZb"><font color="#888888"><br>
</font></span><br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Norman Shulman</b> <span dir="ltr"><<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>></span><br>Date: Tue, Jul 5, 2016 at 6:14 PM<br>To: "Jason A. Donenfeld" <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>><br></font><br></span><br><div dir="ltr">Hi Jason,<div><br></div><div>Many clients use the non-routable <a href="http://192.168.0.0/16" target="_blank">192.168.0.0/16</a> addresses. How can looking up such an address identify the client?</div><div><br></div><div>Thanks.</div><div><br></div><div>Norm</div><div><br></div></div><div class="HOEnZb"></div><br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Jason A. Donenfeld</b> <span dir="ltr"><<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>></span><br>Date: Tue, Jul 5, 2016 at 6:19 PM<br>To: Norman Shulman <<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>><br></font><br></span><br>Hi Norm,<br>
<br>
I think you're misunderstanding how things work. I'll try to explain a<br>
bit more clear here:<br>
<br>
A linux system has several network interfaces, such as lo, eth0,<br>
wlan0, wg0. The ordinary kernel routing table determines which<br>
interface to use when sending outgoing packets. So, let's say the<br>
kernel routing table is setup to route <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> via WireGuard:<br>
<br>
# ip route add <a href="http://192.168.0.0/16" rel="noreferrer" target="_blank">192.168.0.0/16</a> dev wg0<br>
or<br>
# ip addr add <a href="http://192.168.0.5/16" rel="noreferrer" target="_blank">192.168.0.5/16</a> dev wg0<br>
<br>
Now userspace can send packets that will be handled by the wireguard driver:<br>
<br>
# ping 192.168.32.19<br>
...<br>
<br>
When that ping packet hits the wireguard driver, it has a dst IP of<br>
192.168.32.19. What does wireguard do with it now?<br>
<br>
It looks in the cryptokey routing table to see if 192.168.32.19<br>
belongs to any peers. If so, it uses that peer's public key to make a<br>
secure session and encrypt that ping packet. It then sends it off to<br>
the peer's configured external internet endpoint.<br>
<br>
Does this make more sense? Or is there still something you're wondering about?<br>
<br>
Regards,<br>
Jason<br>
<br>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Norman Shulman</b> <span dir="ltr"><<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>></span><br>Date: Tue, Jul 5, 2016 at 6:23 PM<br>To: "Jason A. Donenfeld" <<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>><br></font><br></span><br><div dir="ltr">Hi Jason,<div><br></div><div>I'm still wondering what wireguard does if more than one peer has the address 192.168.32.19.</div><div><br></div><div>Thanks.</div><div><br></div><div>Norm</div><div><br></div></div>----------<br><span class="undefined"><font color="#888">From: <b class="undefined">Jason A. Donenfeld</b> <span dir="ltr"><<a href="mailto:Jason@zx2c4.com">Jason@zx2c4.com</a>></span><br>Date: Tue, Jul 5, 2016 at 6:30 PM<br>To: Norman Shulman <<a href="mailto:norman.shulman@n-dimension.com">norman.shulman@n-dimension.com</a>><br></font><br></span><br>Hi Norm,<br>
<br>
If you run these commands:<br>
<br>
wg set wg0 peer ABCD allowed-ips <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a><br>
wg set wg0 peer EFGH allowed-ips <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a><br>
<br>
After the first command ABCD has <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a>. After the second<br>
command, ABCD has no allowed ips, and EFGH has <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a>.<br>
<br>
However, if you run these commands:<br>
<br>
wg set wg0 peer ABCD allowed-ips <a href="http://192.168.32.0/24" rel="noreferrer" target="_blank">192.168.32.0/24</a><br>
wg set wg0 peer EFGH allowed-ips <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a><br>
<br>
After running both commands, ABCD will have <a href="http://192.168.32.0/24" rel="noreferrer" target="_blank">192.168.32.0/24</a> and EFGH<br>
will have <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a>. However, when sending packets, the routing<br>
table lookups will always match on the most specific match, so ABCD<br>
will not be able to send or receive packets for <a href="http://192.168.32.19/32" rel="noreferrer" target="_blank">192.168.32.19/32</a>.<br>
<br>
Make sense?<br>
<span class="HOEnZb"><font color="#888888"><br>
Jason<br>
</font></span><br></div><div><br></div>
</div></div>