allowed-ips: separation of concerns, routing and firewalling

[Kim Nilsson]

Hello wireguard project,


I am currently working on several projects that make use of wireguard as 
part of a larger networking scheme. Since there are many details about 
tunneling, network routing, and firewalling that are considered 
must-know for many of my coworkers I recently had to make a presentation 
on how packets move through the network stack and, for example, how they 
end up on the receiving end of a wireguard tunnel. During the 
presentation a question arose on what happens when an IP packet is 
routed through a gateway and what wireguard does.


When an IP packet is to be sent over e.g. ethernet, the link layer 
destination address is usually discovered using ARP. In the case of 
wireguard, a lookup is performed into a table which maps the entries of 
allowed-ips to their corresponding wireguard peer. This behavior is 
relatively straightforward and does what one would expect from a link layer.


However, when an IP packet is to be routed through a gateway the 
interaction with link layer processes such ARP is usually performed 
using the gateway address as opposed to the actual destination address 
of the packet (in Linux this is attached to a given skb as dst info). 
 From what I understand, wireguard completely ignores the presence of 
such routing information and instead requires the user to manually 
populate a particular peer with all possible destination addresses. In 
effect, the concern of packet routing is placed inside the wireguard 
implementation instead of being left to the routing subsystem.


As for possible motivations for this design choice, I can think of 
security as one that could be considered motivating enough - A packet 
cannot travel to a wireguard peer unless its destination address is in 
the set of allowed-ips. Looking at the implementation it is also evident 
that wireguard also will not receive packets with source addresses not 
present in allowed-ips (and complain that there is a "dishonest peer").

However, is this not also a case of the concerns of another subsystem 
viz. the firewall being placed inside the wireguard implementation? As 
it stands, what is traditionally considered routing and firewall 
information has to be shared with wireguard in order to maintain a 
working tunnel.


Would it not be more reasonable if wireguard acted as a common link 
layer and respected the boundaries of internet layer routing and 
firewalling? To this effect I have created and tested a small patch 
which does two things, namely;

1. Checks for the presence of routing information on outgoing payloads 
and, if present, uses the specified gateway address as input to the peer 
lookup.

2. Removes the restriction w.r.t. the source address of incoming payloads.


I'm sure it is not possible at this stage to just fundamentally alter 
the semantics of allowed-ips, but, if you agree with my observations, 
perhaps the patch can serve as the foundation of something new which can 
begin to deprecatee allowed-ips as we know it today?


Regards,

Kim Nilsson


P.S.

Apologies if this has already been discussed before.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: wireguard_routing.patch
Type: text/x-patch
Size: 3627 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20230819/31d6be9e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20230819/31d6be9e/attachment.sig>