Score:1

Netplan and Ipsec - tell netplan to leave interface alone?

pl flag

I'm trying to use Strongswan to create an Ipsec tunnel on a server with Netplan. Netplan has currently no configuration for the tunnel1 and tunnel2 interfaces that Ipsec brings up when the tunnels are created. This seems (almost) correct to me.

The ipsec services run a script which creates the tunnel[1,2] interfaces (these could possibly called vti[1,2] if needs be). If a tunnel fails, ipsec will "down" the interface associated with it (using this script). This script also sets a route for the network the other side of the VPN. This route only persists until Netplan runs, whereupon it is removed. The tunnel interfaces look like this:

25: tunnel2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 1.2.3.4 peer 2.3.4.5
    inet 169.254.9.238 peer 169.254.9.237/30 scope global tunnel2
       valid_lft forever preferred_lft forever
    inet6 fe80::200:5efe:c6f4:8f78/64 scope link
       valid_lft forever preferred_lft forever
26: tunnel1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1419 qdisc noqueue state UNKNOWN group default qlen 1000
    link/ipip 1.2.3.4 peer 3.4.5.6
    inet 169.254.199.162 peer 169.254.199.161/30 scope global tunnel1
       valid_lft forever preferred_lft forever
    inet6 fe80::200:5efe:c6f4:8f78/64 scope link
       valid_lft forever preferred_lft forever

The route I'd like to add via netplan is can be added manually like this:

ip route add 10.1.0.0/16 dev tunnel1 scope link src 10.0.16.170/24 metric 100

Is there a way to tell netplan any of these:

  • to leave the routes for specific interfaces/destinations alone?
  • To tell netplan to ignore anything to do with the tunnel[1,2] interfaces?
  • to tell netplan to create routes for interfaces that don't exist and aren't under its control?

...or any other way to make Netplan play nicely with ipsec. I'd rather not have to go the "heavy" route of disabling netplan just to make my ipsec VPNs work.

What's the right way to make all this stuff hang together?

Score:1
pl flag

The problem is caused by systemd-networkd. It will remove routes that it doesn't know about at some later date. I had previously answered that making devices "unmanaged" would solve the problem, but sadly it does not:

[Match]
Name=tunnel1

[Link]
Unmanaged=yes

This solution seems to stop systemd-networkd from creating any config for the unmanaged device, but doesn't stop it removing all that config when it stops all network devices (which it does during restarts).

Configuring the devices and routes fully in networkd (or netplan) doesn't work because of configuration ordering problems.

So far, the only viable solution I have found is to completely disable and stop systemd-networkd (and uninstall Netplan as it's no longer needed). This seems a rather drastic solution and does mean some functionality is lost. In my case I don't think that's a problem, but it may be for some.

Score:0
us flag

You do not need to tell netplan to ignore an interface. It only changes the configuration of interfaces that it's told to. But it sounds like what you want here is to use netplan to add a route to an interface that netplan does not manage, and that is not supported.

For one thing, if at any point your tunnel drops, netplan is not in a position to readd the route.

Whatever you are using to manage the IPsec tunnels should also have support for adding routes. There's really no need to manage them separately, and as mentioned above, doing so prevents the system from properly handling tunnel restart events

pl flag
As I described, ipsec runs a script which adds the route - but it only seems to remain until Netplan runs, hence I'm trying to stop netplan removing the route.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.