=net-misc/networkmanager-openconnect-1.2.4 does not work (see the linked bug reports) and was recently stabilized; =net-misc/networkmanager-openconnect-1.2.2 was the last working version and was recently removed from the tree. Please put it back until the problems with =net-misc/networkmanager-openconnect-1.2.4 (or whatever other package is causing problems with it) are resolved. https://bugs.gentoo.org/show_bug.cgi?id=609732 https://bugs.gentoo.org/show_bug.cgi?id=609594 https://bugs.gentoo.org/show_bug.cgi?id=609314
Update: Installing =net-misc/networkmanager-openconnect-1.2.4 from a local overlay with the line --without-libnm-glib \ removed does not fix the problem (even after rebooting). However, for me, everything worked again after installing =net-misc/networkmanager-openconnect-1.2.2 from a local overlay (by copying networkmanager-openconnect-1.2.4.ebuild and renaming it to networkmanager-openconnect-1.2.2.ebuild, removing the --without-libnm-glib line) and then rebooting.
In the systemd journal, the following error message appears when trying to connect to an openconnect VPN: Invalid VPN service type (cannot find authentication binary) Rebooting does not fix the bug for me. Downgrading to 1.2.2 (using a local overlay) does fix it for me.
networkmanager-openconnect-1.2.4-r1 is working fine for me.
Created attachment 470736 [details] openconnect-prompt.png Removing --without-libnm-glib allows the VPN to connect (before, it wouldn't even do this). However, for me, when connecting to a VPN which opens a prompt to ask for more details, it still fails to show the following prompt (attached); the window briefly appears but then immediately closes without allowing for any user input. This is a regression because it does not allow the user to change any options, including the username and password for the connection. I have 1.2.2 in a local overlay* and I fix the bug by downgrading (i.e. the window shows when attempting to connect to the VPN), and then re-enable the bug by upgrading to 1.2.4-r1 in the tree again. * All I did was copy the 1.2.4-r1 ebuild and change the filename to 1.2.2 so it would install that version instead. Here is the terminal output which occurs when I connect using nmcli (which I believe has always worked for me even when openconnect had --without-libnm-glib and failed to even connect): (I have removed / made minor changes to details which identify the VPN hostname) nmcli --ask c u <VPN NAME> POST <VPN HOSTNAME> Connected to <SERVER IP ADDRESS> SSL negotiation with <VPN HOSTNAME> Server certificate verify failed: signer not found Certificate from VPN server "<VPN HOSTNAME>" failed verification. Reason: signer not found Enter 'yes' to accept, 'no' to abort; anything else to view: yes Connected to HTTPS on <VPN HOSTNAME> XML POST enabled Please choose a VPN tunnel type, then enter your username and password to initiate the secured connection. GROUP: [1-Tunnel-<Local>-Traffic-Only|2-Tunnel-All-Traffic|3-Tunnel-WinDomainUsers|4-Tunnel-All-WinDomainUsers]:2 POST <VPN HOSTNAME> XML POST enabled Please choose a VPN tunnel type, then enter your username and password to initiate the secured connection. Username:<USERNAME> Password: POST <VPN HOSTNAME> VPN connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/7) Regarding GROUP, because of this bug, it is not possible for a user connecting to this VPN server to use the GUI dialog to switch between (2) tunneling all of their traffic and (1) tunneling only traffic to the same subnet as the server.
