resolve Plugin: dots shouldn't be used in protocol part in resolvconf

[worldowner]

System:

• OS: Arch Linux
• Kernel version (if applicable): 6.0.2
• strongSwan version(s): 5.9.8
• Tested/confirmed with the latest version: yes

Describe the bug
I came from systemd/systemd#25032
Recently systemd changed resolveconf to chop off the "protocol" part at the last instead of the first dot, to deal with the fact that in vlan envs its common to use a dot. Lennart Poettering says that using dots in protocol part in resolvconf results in ambiguous mess.

To Reproduce
Steps to reproduce the behavior:

1. Use systemd released after e8d0eb3 (251.6 for example).
2. Configure strongSwan as roadwarrior client using XFRM interface where DNS addresses are to be installed: iface_prefix = xf.inet.ipsec.
3. The result is:

installing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf192.168.35": No such device
removing DNS server 192.168.35.2 via resolvconf
resolvconf: Failed to resolve interface "xf192.168.35": No such device

So it seems that strongSwan concats iface_prefix with DNS IP as protocol in resolvconf's interface[.protocol] which results in multiple dots which systemd doesn't like because of ambiguity. Setting iface_prefix to xf doesn't solve the issue because there are multiple dots in IP address.

Additional context
I was asked by Lennart Poettering to fill this report.
systemd/systemd#25032

[tobiasbrunner]

systemd's tying of DNS server's to interfaces always conflicted with IPsec, at least without XFRM interfaces. But even then it makes not much sense because you usually don't know what interface to use until you know the IP address to reach and what route to take. And there could be multiple XFRM interfaces involved per IKE_SA (e.g. per CHILD_SA or just some of them) or a single interface could be shared by multiple IKE_SAs and all their CHILD_SAs.

The resolve plugin doesn't know what interfaces (if any) will be involved and it installs individual DNS servers, that's why a unique name was generated for each DNS server with lo as base interface (i.e. the additional dots were not in the interface name, which was assumed to not be allowed to contain dots, but the "protocol" part).

I suppose their upcoming fix should work around this again. But we could maybe avoid the dots in the protocol (not sure what that would mean in regards to prioritizing DNS servers with classic resolvconf). I pushed a commit to the 1353-resolve-naming branch, which replaces the . (and also :) in IP addresses with _ (no idea if the "protocol" part has any restrictions).

[worldowner]

I applied patch from 1353-resolve-naming to 5.9.8 (I build it using Arch's PKGBUILD) and I got critical error:

generating AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
sending packet: from LOCAL_IP[500] to REMOTE_IP[500] (676 bytes)
received packet: from REMOTE_IP[500] to LOCAL_IP[500] (580 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID V V V V NAT-D NAT-D HASH ]
received XAuth vendor ID
received DPD vendor ID
received FRAGMENTATION vendor ID
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
local host is behind NAT, sending keep alives
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from LOCAL_IP[4500] to REMOTE_IP[4500] (140 bytes)
received packet: from REMOTE_IP[4500] to LOCAL_IP[4500] (92 bytes)
parsed TRANSACTION request 929562309 [ HASH CPRQ(X_USER X_PWD) ]
generating TRANSACTION response 929562309 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from LOCAL_IP[4500] to REMOTE_IP[4500] (108 bytes)
received packet: from REMOTE_IP[4500] to LOCAL_IP[4500] (92 bytes)
parsed TRANSACTION request 2725704030 [ HASH CPS(X_STATUS) ]
XAuth authentication of 'MY_LOGIN' (myself) successful
IKE_SA XF[1] established between LOCAL_IP[...]...REMOTE_IP[REMOTE_IP]
scheduling reauthentication in 86080s
maximum IKE_SA lifetime 86260s
generating TRANSACTION response 2725704030 [ HASH CPA(X_STATUS) ]
sending packet: from LOCAL_IP[4500] to REMOTE_IP[4500] (92 bytes)
generating TRANSACTION request 2409656544 [ HASH CPRQ(ADDR DNS) ]
sending packet: from LOCAL_IP[4500] to REMOTE_IP[4500] (92 bytes)
received packet: from REMOTE_IP[4500] to LOCAL_IP[4500] (348 bytes)
parsed TRANSACTION response 2409656544 [ HASH CPRP(ADDR DNS DNS U_DEFDOM U_SPLITINC) ]
thread 13 received 11
 dumping 22 stack frame addresses:
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c63f1a00]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c650cb81]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 (chunk_create_clone+0x31) [0x7fe1c66a6791]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 (chunk_printable+0x68) [0x7fe1c66a79f8]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 (identification_printf_hook+0x88) [0x7fe1c66aa408]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 [0x7fe1c66b164f]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c64116e8]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c6412a3c]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c6434a9e]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 (__snprintf_chk+0xa4) [0x7fe1c64cef14]
    -> ??:?
  /usr/lib/ipsec/plugins/libstrongswan-resolve.so @ 0x7fe1c57c1000 [0x7fe1c57c24db]
    -> ??:?
  /usr/lib/ipsec/plugins/libstrongswan-resolve.so @ 0x7fe1c57c1000 [0x7fe1c57c2c76]
    -> ??:?
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c65cd445]
    -> ??:0
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c6631663]
    -> ??:?
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c663182d]
    -> ??:?
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c6623112]
    -> ??:?
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c65f4527]
    -> ??:?
  /usr/lib/ipsec/libcharon.so.0 @ 0x7fe1c65c0000 [0x7fe1c65ecf63]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 [0x7fe1c669b446]
    -> ??:?
  /usr/lib/ipsec/libstrongswan.so.0 @ 0x7fe1c665d000 [0x7fe1c66af6a9]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c643f8fd]
    -> ??:?
  /usr/lib/libc.so.6 @ 0x7fe1c63b9000 [0x7fe1c64c1a60]
    -> ??:?
killing ourself, received critical signal

[tobiasbrunner]

Sorry about that. I used the wrong printf-specifier there (should be %H not %Y).

[worldowner]

It works with %H on both patched and unpatched systemd.
However strongSwan is supposed to set 2 DNS servers but installs only one:

parsed TRANSACTION response 1611578406 [ HASH CPRP(ADDR DNS DNS U_DEFDOM U_SPLITINC) ]
installing DNS server 192.168.35.2 via resolvconf
resolvconf: Dropped protocol specifier '.ipsec.192_168_35_2' from 'xf.ipsec.192_168_35_2'. Using 'xf' (ifindex=5).
installing DNS server 192.168.35.3 via resolvconf
resolvconf: Dropped protocol specifier '.ipsec.192_168_35_3' from 'xf.ipsec.192_168_35_3'. Using 'xf' (ifindex=5).
handling UNITY_DEF_DOMAIN attribute failed

$ resolvectl 
[...]
Link 5 (xf)
    Current Scopes: DNS
         Protocols: -DefaultRoute -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.35.3
       DNS Servers: 192.168.35.3
[...]

My guess is that it invokes resolvconf for each DNS server overwriting previous entry because only last one is being set.

[tobiasbrunner]

The problem is probably that it strips the protocol specifier, which makes the whole thing unique. So the second call likely overrides the server installed by the first as they reference the same interface. Looks like it strips everything after the first dot. I don't think we can modify the interface name to make it unique as it probably checks that it exists (maybe interface labels work, what happens if you configure iface_prefix = xf:, that would result in xf:192_168_35_2). We probably can't fix this, unless we change the resolve plugin completely (so it installs all the servers, which it receives one at a time, together with one call). I might be able to have a look at this later this week.

[tobiasbrunner]

I've pushed a commit to the 1353-resolve-naming branch that changes how the plugin installs DNS servers via resolvconf. It now always installs all the available servers without creating unique names but instead just using the configured prefix (or rather interface/protocol name now, although the old config option is used as fallback). Please let me know if that works for you.

[tobiasbrunner]

The changes are now in master.

[worldowner]

Sorry for the delay, I didn't have an opportunity to try this out earlier. Using 5.9.9 both DNS servers are set correctly. Thank you.

[tobiasbrunner]

Great, thanks for the feedback.