v15~beta+focal cannot connect to server

[ds20prefecture]

Background - Ubuntu auto-update upgrades from 13 beta to 14 or 15 beta
Upgrade: openvpn3:amd64 (13beta-1+focal, 14beta+focal)

Issue:
Cannot connect to existing OpenVPN3 profile from OpenVPN cloud which uses SAML to O365 for auth

Error
"session-start: ** ERROR ** Failed to start new session: Failed calling D-Bus method Ready: GDBus.Error:net.openvpn.v3.sessions.error: Backend VPN process have died. Session is no longer valid." .

Debug log:
** ERROR ** org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code36: GDBus.Error:net.openvpn.v3.sessions.error: Failed communicating with VPN backend: Failed calling D-Bus method Connect: GDBus.Error:net.openvpn.v3.backend.error.standard: Failed executing D-Bus call 'Connect': Failed preparing proxy: Error calling StartServiceByName for net.openvpn.v3.netcfg: Invalid configuration (missing or empty ?)

Roll back to 13_beta works fine.

Previously reported and closed as addressed in v15, however it does not.
#57

[dsommers]

Please provide more details what is not working.

1. Check that all services are running the expected version:

    [user@host:~]$ openvpn3-admin version --services
   

2. Increase the default logging before connecting:

    [root@host:~]# openvpn3-admin log-service --log-level 6
   

3. Retrieve system logs

    [root@host:~]# journalctl --since -30m SYSLOG_IDENTIFIER=net.openvpn.v3.log + SYSLOG_IDENTIFIER=openvpn3-service-logger + SYSLOG_IDENTIFIER=dbus + _SYSTEMD_UNIT=dbus.service + UNIT=dbus.service
   

[intiluha]

Have the same issue. Was working fine until upgrade from v13, works fine after degrade. Output of your script from #25

When this is done, hit [ENTER] in this terminal ... 

Starting VPN session ...
Traceback (most recent call last):
  File "ovpn3-debug.py", line 55, in <module>
    session.Connect()
  File "/usr/lib/python3/dist-packages/openvpn3/SessionManager.py", line 138, in __delete_checker
    return func(self, *args, **kwargs)
  File "/usr/lib/python3/dist-packages/openvpn3/SessionManager.py", line 188, in Connect
    self.__session_intf.Connect()
  File "/usr/lib/python3/dist-packages/dbus/proxies.py", line 141, in __call__
    return self._connection.call_blocking(self._named_service,
  File "/usr/lib/python3/dist-packages/dbus/connection.py", line 652, in call_blocking
    reply_message = self.send_message_with_reply_and_block(
dbus.exceptions.DBusException: org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code36: GDBus.Error:net.openvpn.v3.sessions.error: Failed communicating with VPN backend: Failed calling D-Bus method Connect: GDBus.Error:net.openvpn.v3.backend.error.standard: Failed executing D-Bus call 'Connect': Failed preparing proxy: Error calling StartServiceByName for net.openvpn.v3.netcfg: Invalid configuration (missing or empty <user>?)

Output of version command

$ openvpn3-admin version --services
OpenVPN 3 D-Bus services:

  - Client backend starter service
     openvpn3-service-backendstart: v15_beta

  - Configuration Service
     openvpn3-service-configmgr:    v15_beta

  - Log Service
     openvpn3-service-logger:       v15_beta

** ERROR ** Failed preparing proxy: Error calling StartServiceByName for net.openvpn.v3.netcfg: Invalid configuration (missing or empty <user>?)

Log from journalctl after running above commands attached
log.txt

[dsommers]

In the attached log file I see this line:

 [...] net.openvpn.v3.netcfg[11028]: FATAL ERROR: Failed preparing proxy: Error calling StartServiceByName for org.freedesktop.resolve1: Unit dbus-org.freedesktop.resolve1.service not found.

Do you have systemd-resolved configured and running? check with systemctl status systemd-resolved. As of v14_beta, this is expected to be used by default. And this is highly recommended over the previous approach, which was to modify /etc/resolv.conf.

The workaround, to revert back to using /etc/resolv.conf is to modify the Exec= line in /usr/share/dbus-1/system-services/net.openvpn.v3.netcfg.service from:

Exec=/usr/libexec/openvpn3-linux/openvpn3-service-netcfg --systemd-resolved --state-dir "/var/lib/openvpn3"

to:

Exec=/usr/libexec/openvpn3-linux/openvpn3-service-netcfg --resolv-conf /etc/resolv.conf --state-dir "/var/lib/openvpn3"

[dsommers]

Closing as no feedback has been provided in about 1 month. Most likely looks like a configuration issue related to systemd-resolved not being available while OpenVPN 3 Linux is configured to use it.

In the coming v16_beta it will also be easier to switch back to using /etc/resolv.conf for those who uses distributions where systemd-resolved is expected to be running but has explicitly disabled it.

[Bjohnson131]

Hello, I'm getting this error

brice@faraday-00:~/Documents/vpn$ openvpn3 version
OpenVPN 3/Linux v18_beta (openvpn3)
OpenVPN core 3.git:HEAD:c4fa5a69 linux x86_64 64-bit
Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.

Systemd resolved is running:

$ systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2022-08-08 21:38:56 PDT; 1 day 22h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 5476 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 309335)
     Memory: 4.7M
        CPU: 2.015s
     CGroup: /system.slice/systemd-resolved.service
             └─5476 /lib/systemd/systemd-resolved

trying to start a session:

$ openvpn3 session-start --config us_seattle.ovpn
Using configuration profile from file: us_seattle.ovpn
Session path: /net/openvpn/v3/sessions/8bb73c54s4f0cs454csab67sf8f753d209ea
session-start: ** ERROR ** Failed to start new session: Failed calling D-Bus method Ready: GDBus.Error:net.openvpn.v3.sessions.error: Backend VPN process has died.  Session is no longer valid.

Log output:
[attached]
start.log

[dsommers]

In your log file, I see this line:

 Aug 10 19:27:54 faraday-00 net.openvpn.v3.netcfg[868343]: FATAL ERROR: Failed preparing proxy: Error calling StartServiceByName for org.freedesktop.resolve1: Failed to activate service 'org.freedesktop.resolve1': timed out (service_start_timeout=25000ms)

This indicates that you are on a distribution expected to have the systemd-resolved service running. If your system is not configured to use this resolver service, you need to disable it in openvpn3-linux. Instructions to do so can be found in this post.

[TheXDS]

I can confirm that this is indeed the case for me (and probably @ds20prefecture as well)
I'm running OpenVPN3 on Ubuntu Server -a distro notorious for not having a good DNS- which is acting as my DNS server using PiHole (and therefore, replacing systemd-resolved completely).

The workaround of editing the service file (#63 (comment)) works good enough for me... It might be a good idea to switch over to use the old behavior if there's a problem trying to reach resolved as a backup for v19 I think...

[dsommers]

Ubuntu and DNS configurations is clearly a mess. And unfortunately it gets even messier as VPS providers also tends to deviate from the base image from the Canonical Ubuntu images. So there seems to be no "standard DNS configuration" in several Ubuntu releases.

Currently the DNS resolver implementation to use is decided at build and packaging time, based on what the upstream (Canonical) Ubuntu images is expected to use. No matter what backend we default to, it will break the experience for some users - as there are to many deviations from the base upstream image. After this change, several users were happy as DNS started working better. And then a noticeable amount of users started reporting regressions.

The only way seems to have resolv.conf as a fallback at runtime, if resolved is not available. I'm not able to squeeze that into v19_beta, that release is already getting large enough. But I'll put that into consideration for v20_beta.