wireguard: Missing routes for AllowedIPs

[Andreas Hasenack]

I posted about this in https://discourse.ubuntu.com/t/netplan-with-wireguard/30168, but figured a bug is perhaps better.

Hi,

I'm following https://netplan.io/reference#properties-for-device-type-tunnels%3A to configure wireguard using netplan, and came up with this yaml file snippet:

```yaml
network:
  version: 2
  tunnels:
    home0:
      mode: wireguard
      key: /etc/wireguard/laptop-private.key
      port: 51000
      addresses: [10.10.11.2/24]
      peers:
        - keys:
            public: syR+psKigVdJ+PZvpEkacU5niqg9WGYxepDZT/zLGj8=
          endpoint: 10.48.132.39:51000
          allowed-ips: [10.10.11.0/24, 10.10.10.0/24]
```

After I run `netplan apply`, however, I only have a route through the `home0` interface for the `10.10.11.0/24` network, not the second network `10.10.10.0/24`.

    # ip route|grep home0
    10.10.11.0/24 dev home0 proto kernel scope link src 10.10.11.2

The generated systemd netdev file contains both networks in `AllowedIPs`:

```ini
[NetDev]
Name=home0
Kind=wireguard

[WireGuard]
PrivateKeyFile=/etc/wireguard/laptop-private.key
ListenPort=51000

[WireGuardPeer]
PublicKey=syR+psKigVdJ+PZvpEkacU5niqg9WGYxepDZT/zLGj8=
AllowedIPs=10.10.11.0/24,10.10.10.0/24
Endpoint=10.48.132.39:51000
```
And the corresponding `network` file is this:

```ini
[Match]
Name=home0

[Network]
LinkLocalAddressing=ipv6
Address=10.10.11.2/24
ConfigureWithoutCarrier=yes
```
I suspect I only have a route for `10.10.11.0/24` because of the IP I chose for the `home0` interface.

Googling around, I found this upstream systemd issue: https://github.com/systemd/systemd/issues/14176

Which has a lot of discussions, and PRs, but I'm left unclear whether this should work by default, or if more configuration tuning is needed. In any case, this is netplan generating the networkd configuration files, so if some extra tuning is needed, it should be netplan doing it.

The [systemd.netdev(5)](https://manpages.ubuntu.com/manpages/jammy/en/man5/systemd.netdev.5.html#[wireguardpeer]%20section%20options) manpage does say that an extra route will be needed for the networks listed in `AllowedIPs`:

> Note that this only affects routing inside the network interface itself, i.e. the packets that pass through the tunnel itself. To cause packets to be sent via the tunnel in the first place, an appropriate route needs to be added as well — either in the "[Routes]" section on the ".network" matching the wireguard interface, or externally to systemd-networkd.

I can add the missing route manually, after which the traffic is sent to the home0 interface as expected:

    # ip route add 10.10.10.0/24 via 10.10.11.2
    # ip route | grep home
    10.10.10.0/24 via 10.10.11.2 dev home0
    10.10.11.0/24 dev home0 proto kernel scope link src 10.10.11.2
    # telnet 10.10.10.90 22
    Trying 10.10.10.90...
    Connected to 10.10.10.90.
    Escape character is '^]'.
    SSH-2.0-OpenSSH_8.9p1 Ubuntu-3

Is this a bug in netplan?

[Lukas Märdian (slyon)]

I don't think this is a bug, but rather a feature request about automatically/implicitly adding new routes for WG allowed-ips.

The feature was discussed in systemd-networkd upstream and rejected, initially. Then implemented, but reverted due to issues with the catch-all 0.0.0.0/0 ::/0 allowed-ips (which would install new default routes by default).

netplan allows configuring routes explicitly, but does not install any WireGuard related routes implicitly, so you could try something like this:
```yaml
network:
  version: 2
  tunnels:
    home0:
      mode: wireguard
      key: /etc/wireguard/laptop-private.key
      port: 51000
      addresses: [10.10.11.2/24]
      peers:
        - keys:
            public: syR+psKigVdJ+PZvpEkacU5niqg9WGYxepDZT/zLGj8=
          endpoint: 10.48.132.39:51000
          allowed-ips: [10.10.11.0/24, 10.10.10.0/24]
      routes:
        - to: 10.10.11.0/24
          from: 10.10.11.2
          scope: link
```

In the future we can think about adding such routes automatically, but we should double-check the lengthy discussion on systemd-networkd to avoid any issues like the one with the default routes.

[Andreas Hasenack (ahasenack)]

I understand the concern, and somewhat share it, that we don't want to break networking, and need to be careful about this. However, this means there is no feature parity in an important aspect of the wireguard support in netplan/systemd.

I'll try your suggestion, thanks for bringing it up.