[WireGuard] Troubleshooting with WireGuard

[Jason A. Donenfeld]

> On Wed 2016-07-13 18:57:45 +0200, Baptiste Jonglez wrote:
>> Actually, it does !  This dual usage brings more confusion.  Despite the
>> name, "AllowedIPs" controls both:
>>
>> 1) packets that are *received* from a peer (by looking at the source IP
>>    address after decrypting an incoming packet, and only allowing the
>>    packet if it matches an AllowedIPs rule for this peer)
>>
>> 2) packets that are *sent* through a wireguard interface, where the right
>>    peer is found by looking for a matching AllowedIPs entry (using the
>>    destination IP address of the packet, this time).  That's the
>>    "cryptokey routing" part.
>

Baptiste is exactly right here. It's a routing table on the way out
and an ACL on the way in.
Now, theoretically, these don't actually have to be the same list.
About a year ago I was experimenting with keeping these separate, but
opted to keep them the same because... which leads me to Daniel's
remark.


On Wed, Jul 13, 2016 at 7:39 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net> wrote:
> so if a given interface has two peers, their AllowedIPs (or whatever we
> end up calling it) are not permitted to overlap?  That constraint should
> probably be better documented as well.  It makes sense now that you
> describe it, but it wasn't obvious from the current docs.

If the AllowedIPs overlap, on the way out, it functions in the exact
same way as a routing table: the most specific route is the one that's
chosen.
On the way in, for checking the ACL, the way it works is NOT by (A)
checking to see if that peer has an AllowedIPs that matches the
incoming packet's src. RATHER, (B) it consults the entire cryptokey
routing table, globally, to see to whom this packet would be routed on
the way out, and if that peer matches the receiving peer, then it's
allowed. By making AllowedIPs cover both, we get this nice property of
(B). Namely, with (B) we have a stronger variant of reverse-path
filtering that ties packets to keys. (B) then enables userspace to be
completely sure that the peer they're talking to is necessarily the
one single peer who has a particular public key and specific
AllowedIPs entry. The stronger crypto reverse-path filtering (B) is
actually something that mitigates real vulnerabilities with certain
misconfgured IPsec boxes I've owned (as part of my day job) in the
wild.

You're right -- I should document this. There's a lot of thought that
went into all these little components, and at the time of
documentation-writing, it was hard to enumerate what they all were.
It's good that things are surfacing organically now.