[Bug]: Fedora 40 aarch64 - systemd-resolved DBus interface (org.freedesktop.resolve1) is not available

[luckylinux]

Version in use.

Version Git Main Branch (1741719).

Your Linux distribution.

Fedora 40 aarch64

Your systemd version.

systemd 255 (255.8-1.fc40)

Your network management software.

NetworkManager

Please describe the bug.

I am using this Script quite successfully on Debian/Ubuntu Distributions (it comes pre-packaged).

However on Fedora 40 aarch64 (installed by cloning Git Repository & running make according to the README) the OpenVPN Service would fail immediately on Startup with the Following Error:

systemd-resolved DBus interface (org.freedesktop.resolve1) is not available.
update-systemd-resolved requires systemd version 229 or above.
WARNING: Failed running command (--up/--down): external program exited with error status: 1

Output of resolvectl status.

Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub

Link 2 (enu1u1)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.1.4
       DNS Servers: 192.168.1.3 192.168.1.4 2xxx:xxxx:xxxx:1::7 2xxx:xxxx:xxxx:1::1:3 2xxx:xxxx:xxxx:1::1:4
        DNS Domain: MYDOMAIN.TLD

Link 3 (wlan0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

Other helpful details.

░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit openvpn-client@MYVPNSERVER.service completed and consumed the indicated resources.
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD systemd[1]: Starting openvpn-client@MYVPNSERVER.service - OpenVPN tunnel for MYVPNSERVER...
░░ Subject: A start job for unit openvpn-client@MYVPNSERVER.service has begun execution
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit openvpn-client@MYVPNSERVER.service has begun execution.
░░ 
░░ The job identifier is 37044.
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you nee>
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: OpenVPN 2.6.11 aarch64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO]
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: library versions: OpenSSL 3.2.1 30 Jan 2024, LZO 2.10
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: DCO version: N/A
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD systemd[1]: Started openvpn-client@MYVPNSERVER.service - OpenVPN tunnel for MYVPNSERVER.
░░ Subject: A start job for unit openvpn-client@MYVPNSERVER.service has finished successfully
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ A start job for unit openvpn-client@MYVPNSERVER.service has finished successfully.
░░ 
░░ The job identifier is 37044.
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: TCP/UDP: Preserving recently used remote address: [AF_INET]123.456.789.012:1194
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: UDPv4 link local: (not bound)
Jul 09 16:05:11 MYHOST.MYDOMAIN.TLD openvpn[11056]: UDPv4 link remote: [AF_INET]123.456.789.012:1194
Jul 09 16:05:12 MYHOST.MYDOMAIN.TLD openvpn[11056]: [MYVPNSERVER] Peer Connection Initiated with [AF_INET]123.456.789.012:1194
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: register-dns (2.6.11)
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: TUN/TAP device tun0 opened
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: net_iface_mtu_set: mtu 1500 for tun0
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: net_iface_up: set tun0 up
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: net_addr_v4_add: 10.10.0.2/20 dev tun0
Jul 09 16:05:13 MYHOST.MYDOMAIN.TLD openvpn[11056]: /usr/local/libexec/openvpn/update-systemd-resolved tun0 1500 0 10.10.0.2 255.255.240.0 init
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD update-systemd-resolved[11088]: systemd-resolved DBus interface (org.freedesktop.resolve1) is not available.
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD update-systemd-resolved[11088]: update-systemd-resolved requires systemd version 229 or above.
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD openvpn[11056]: WARNING: Failed running command (--up/--down): external program exited with error status: 1
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD openvpn[11056]: Exiting due to fatal error
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD systemd[1]: openvpn-client@MYVPNSERVER.service: Main process exited, code=exited, status=1/FAILURE
░░ Subject: Unit process exited
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ An ExecStart= process belonging to unit openvpn-client@MYVPNSERVER.service has exited.
░░ 
░░ The process' exit code is 'exited' and its exit status is 1.
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD systemd[1]: openvpn-client@MYVPNSERVER.service: Failed with result 'exit-code'.
░░ Subject: Unit failed
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit openvpn-client@MYVPNSERVER.service has entered the 'failed' state with result 'exit-code'.
Jul 09 16:05:14 MYHOST.MYDOMAIN.TLD systemd[1]: openvpn-client@MYVPNSERVER.service: Consumed 1.185s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
░░ 
░░ The unit openvpn-client@MYVPNSERVER.service completed and consumed the indicated resources.

[tomeon]

@luckylinux -- please ensure that you've set up polkit properly if you are running OpenVPN as an unprivileged user, and that the relevant user can run the command busctl status org.freedesktop.resolve1 successfully (exits with code 0).

[luckylinux]

@tomeon: I thought I was running as root. Although it could be, for some reason, the openvpn process itself on Fedora is owned by opnvpn-<something> (column truncated of ps aux | grep openvpn).

I don't recall this being the case on Debian/Ubuntu though (on Debian/Ubuntu openvpn runs as root).

[luckylinux]

@tomeon: I followed the tutorial and applied the required Polkit Policies for Both User openvpn and Group openvpn. It still fails in the same manner.

sudo -u openvpn busctl status org.freedesktop.resolve1 Works Correctly:

PID=737
PPID=1
TTY=n/a
UID=193
EUID=193
SUID=193
FSUID=193
GID=193
EGID=193
SGID=193
FSGID=193
SupplementaryGIDs=193
Comm=systemd-resolve
CommandLine=/usr/lib/systemd/systemd-resolved
Label=system_u:system_r:systemd_resolved_t:s0
CGroup=/system.slice/systemd-resolved.service
Unit=systemd-resolved.service
Slice=system.slice
UserUnit=n/a
UserSlice=n/a
Session=n/a
AuditLoginUID=n/a
AuditSessionID=n/a
UniqueName=:1.1
EffectiveCapabilities=cap_net_raw
PermittedCapabilities=cap_net_raw
InheritableCapabilities=cap_net_raw
BoundingCapabilities=cap_net_raw

Do I need to reboot by any Chance ?

EDIT 1: it might be SELinux (as usual on Fedora) looking at /var/log/audit/audit.log ...

type=AVC msg=audit(1720860177.993:494): avc:  denied  { create } for  pid=2843 comm="openvpn" scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=netlink_generic_socket permissive=0
type=SERVICE_START msg=audit(1720860177.999:495): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvpn-client@VPNServer comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
type=AVC msg=audit(1720860180.369:496): avc:  denied  { write } for  pid=2850 comm="bash" name="fd" dev="proc" ino=24635 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1720860180.648:497): avc:  denied  { write } for  pid=2856 comm="bash" name="fd" dev="proc" ino=22319 scontext=system_u:system_r:openvpn_t:s0 tcontext=system_u:system_r:openvpn_t:s0 tclass=dir permissive=0
type=SERVICE_START msg=audit(1720860180.707:498): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"
type=SERVICE_STOP msg=audit(1720860181.080:499): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=openvpn-client@VPNServer comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'UID="root" AUID="unset"
type=BPF msg=audit(1720860181.111:500): prog-id=132 op=UNLOAD
type=SERVICE_STOP msg=audit(1720860191.222:501): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=NetworkManager-dispatcher comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'UID="root" AUID="unset"

EDIT 2: Adding this to /etc/NetworkManager/conf.d/99-unmanaged-devices.conf to prevent NetworkManager to conflicting with the Systemd Service changed a bit the behavior (no more DBUS related Messages, althought that could be because I restarted dbus and dbus-daemon Systemd Services):

[keyfile]
unmanaged-devices=interface-name:tun0;

Now I only get this, which is not very helpful:

Jul 13 10:52:26 MYHOST.MYDOMAIN.TLD openvpn[3039]: /usr/local/libexec/openvpn/update-systemd-resolved tun0 1500 0 10.10.0.2 255.255.240.0 init
Jul 13 10:52:27 MYHOST.MYDOMAIN.TLD openvpn[3039]: WARNING: Failed running command (--up/--down): external program exited with error status: 1
Jul 13 10:52:27 MYHOST.MYDOMAIN.TLD openvpn[3039]: Exiting due to fatal error
Jul 13 10:52:27 MYHOST.MYDOMAIN.TLD systemd[1]: openvpn-client@VPNServer.service: Main process exited, code=exited, status=1/FAILURE

It's still probably SELinux (same error messages in /var/log/audit/audit.log) ...

EDIT 3: Spoke too soon. The DBUS-related messages are Back once again 😢.