Routing regression between 5.9.8 (Debian Bookworm deb12u1) and 5.9.13 (Ubuntu 24.04 (2ubuntu4)) about strongswan

[tobiasbrunner]

I can't find this route before anywhere, not sure if that is related.

It should be in table 220 (ip route list table 220). And that table should only be used for traffic that is not marked with the value 220 (ip rule), which IKE as well as ESP packets should be. That is, these packets should not go via XFRM interface but via regular routing table/interfaces (thus avoiding the loop).

What additional information can I provide to help solve this issue?

Logs by NetworkManager/charon-nm would be helpful (e.g. via journalctl -u NetworkManager).

[marcust]

So directly after reboot ip rule looks like this:

0:	from all lookup local
220:	from all lookup 220
32766:	from all lookup main
32767:	from all lookup default

Funnily enough table 220 does not even exist then

$ip route list table 220
Error: ipv4: FIB table does not exist.
Dump terminated

After connect there is an additional rule:

$ip rule
0:	from all lookup local
220:	from all lookup 220
220:	not from all fwmark 0xdc lookup 220
32766:	from all lookup main
32767:	from all lookup default

The table after connect of 220 is then

$ip route list table 220
default dev nm-xfrm-3648987 proto static src 172.29.52.13 
throw 10.179.0.0/16 proto static 
throw 10.179.1.3 proto static 
throw 172.17.0.0/16 proto static 

The logs contain a lot of names that I don't want to share here, what would you be looking for?

[tobiasbrunner]

Funnily enough table 220 does not even exist then

Obviously, as it's created by charon-nm ;)

That all looks fine so far. Traffic should be routed via XFRM interface, except for IKE and ESP packets (due to the mark they have applied) and packets destined to the subnets that got a throw routes installed (you probably have the bypass-lan plugin enabled, which will install such routes for locally connected subnets).

You can check if the SAs look right via ip -s xfrm state (the mark should be mentioned, it also shows the traffic counters). But as I said, this all looks as it should. Do you still get Local routing loop detected errors? If so, for any particular traffic? (The other log message could be caused if the XFRM interface is deleted before the policy and route got uninstalled, this happens concurrently, as the latter will be gone then already.)

[tobiasbrunner]

Also, regarding DNS, did you configure ~. as "additional search domain"? That's required to force DNS resolution via VPN.

[marcust]

Obviously, as it's created by charon-nm ;)

I was more saying that it is funny that the rule is already there, where does that come from then?

As far as I can see the ip -s xfrm state mentions the mark as output-mark. Not sure what else I read out of that.

Do you still get Local routing loop detected errors? If so, for any particular traffic?

I see these messages all the time (155 messages for the last try, and that is without the message repeated N times), up to a point where I think it decides to kill the VPN afer a while (from the logs it looks like it reconnects because it can't reach something)?

charon-nm: 07[IKE] giving up after 5 retransmits
charon-nm: 07[IKE] peer not responding, trying again (2/0)

I guess the traffic is actually from the DNS also, because resolved complains that it is switching between TCP and UDP.

Also, regarding DNS, did you configure ~. as "additional search domain"? That's required to force DNS resolution via VPN

That is only the initial symptom, but I can't even ping or dig directly at the nameservers. I can't reach anything inside the VPN network.

[tobiasbrunner]

I was more saying that it is funny that the rule is already there, where does that come from then?

Oh, sorry, I missed that. Do you have any other IKE daemons running (charon-systemd, charon)? If so, disable them as that will definitely mess with the rule required by charon-nm (you could theoretically use other IKE daemons concurrently, but they have to be configured the same way for it to work).

[marcust]

That was apparently it....

Even though I am not 100% sure what fixed it now, I uninstalled a strongswan-starter and a charon-systemd. Now the existing rule after reboot is gone and everything works nicely again. Thanks for your help.

I am just wondering if this used to be a combination that worked (because the ip rule was the same) and now stopped working if I am the only one who will hit that after upgrade.

[tobiasbrunner]

Yeah, I suppose this combination worked before 5.9.12 out of the box, as charon-nm did not actually use the XFRM interface (i.e. did not install special routes/marks etc.) or didn't use such interfaces at all. We should probably change the default routing table used by charon-nm to avoid that conflict. Just for reference, it's possible to change the table already via charon-nm.routing_table in strongswan.conf. I pushed a patch to the 2230-nm-routing-table branch.

[Jancis]

I have very similar issue and same error after fresh Ubuntu 24.04 install. Removing strongswan-starter and charon-systemd did not fix the issue.
I patched this by disabling disabling xfrm interface module and now it works, but it's not a proper solution -

Edit /etc/strongswan.d/charon/kernel-netlink.conf and change kernel-netlink.load = yes to no.

[tobiasbrunner]

Removing strongswan-starter and charon-systemd did not fix the issue.

Why not? What IKE daemon was still running (besides charon-nm)?

I patched this by disabling disabling xfrm interface module and now it works, but it's not a proper solution -

Well, that basically prevents IKE daemons from starting (on Linux they require that plugin). Since charon-nm does not include these config snippets, it won't be affected, only the other ones. But yeah, that's not really a solution. Remove the IKE daemons if you don't need them, or change the routing table that charon-nm uses (see my last reply above).