Closed languede closed 8 months ago
What happens when you try to start the session manually?
$ openvpn3 session-start --config XXXX
Also try to enable debug logging and catch the log outputs:
$ sudo openvpn3-admin log-service --log-level 6
$ openvpn3 config-manage --config XXXX --log-level 6
And in a different terminal, before running openvpn3 session-start
, run this command first:
$ openvpn3 log --config XXXX
Then you can do the openvpn3 session-start
in a separate terminal.
What happens when you try to start the session manually?
$ openvpn3 session-start --config XXXX
Also try to enable debug logging and catch the log outputs:
$ sudo openvpn3-admin log-service --log-level 6 $ openvpn3 config-manage --config XXXX --log-level 6
And in a different terminal, before running
openvpn3 session-start
, run this command first:$ openvpn3 log --config XXXX
Then you can do the
openvpn3 session-start
in a separate terminal.
Run
$ openvpn3 session-start --config XXXX
Result: ERROR ** Failed to disconnect tunnel (object does not exist)
see: https://github.com/NixOS/nixpkgs/issues/235986
Then I switch back to Debian 11.4, it runs well without any problem. openvpn3 might not compatible with Debain 12.4/12
Can you please share the log output after a connection attempt with log-level
increased to 6
? The NixOS issue is not related to this at all; that's related to a newer glib2 library (v2.76); Debian 12 ships with glib2 v2.74, which should work fine.
I've just re-tested Debian 12 with OpenVPN 3 Linux v21, connecting to an OpenVPN Access Server with 2FA (which is known to cause issues with glib2-2.76), and that connected just fine.
Since your configuration works with Debian 11, my hunch is that this is related to the OpenSSL versions. Debian 12 ships with OpenSSL 3.0.11 which has much stricter defaults and many (weak!) ciphers and algorithms are not available without explicitly enabling them. Debian 11 ships with OpenSSL 1.1.1w.
Can you please share the log output after a connection attempt with
log-level
increased to6
? The NixOS issue is not related to this at all; that's related to a newer glib2 library (v2.76); Debian 12 ships with glib2 v2.74, which should work fine.I've just re-tested Debian 12 with OpenVPN 3 Linux v21, connecting to an OpenVPN Access Server with 2FA (which is known to cause issues with glib2-2.76), and that connected just fine.
Since your configuration works with Debian 11, my hunch is that this is related to the OpenSSL versions. Debian 12 ships with OpenSSL 3.0.11 which has much stricter defaults and many (weak!) ciphers and algorithms are not available without explicitly enabling them. Debian 11 ships with OpenSSL 1.1.1w.
Unfortunately I delete the Debian 12 instance once I made the openvpn3 work in a fresh Debian 11.4 environment, so I can't reproduce the error, sorry for that.
I also create an new Debian 12.4 instance to test it with same .ovpn file, it has no error shows after the session start, so it should be my set up issue I assume.
Previously, the Debian 12 was running as a Lightsail instance on AWS which it has installed some other tools like WireGuard, NetworkManager, I was using nmcli connection import
to import wireguard config and nmcli connection up \ down\ delete
to manage connections, could it be a reason that NetworkManager prevent openvpn3 to modify network settings? I also have wireguard server running on same system in docker container wg-easy.
Your issue has nothing to do with NetworkManager. NetworkManager and OpenVPN 3 Linux will not interfere with each other. If you can't reproduce it, then it was something related to your host setup.
Closing this issue and will convert it to a discussion, as this is not related to a bug in OpenVPN 3 Linux.
By follow the step by step instructions in the official document, successfully installed openvpn3 on Debian 12
When trying to start the openvpn client with the command:
sudo systemctl enable --now openvpn3-session@XXXX.service
the openvpn3-session failed to startERROR message: Got notification message from PID xxxxxx, but reception only permitted for main PID yyyyyy
is it a bug?