I did the test indicated on the Gnome interface, I noticed that once you
install the debug packages and updated the version of
OpenConnect/Libopenconnect5 to 8.10-5 the VPN works and remain active.
For try, I removed debug packages and downgraded the others to version
8.10-4, to return to the problem, but strangely it continued to work
(while before, with the same OpenConnect version installed, it didn't work).
As for Plasma/KDE, the desktop that I use, I opened a bug on Bugzilla
https://bugs.kde.org/show_bug.cgi?id=448153
Il 05/01/22 17:54, Luca Boccassi ha scritto:
On Mon, 2022-01-03 at 20:08 +0100, Antonio wrote:
Dear maintainer,
I tried the updated version of OpenConnect.
---
From GNOME interface:
- When the VPN is active, the form for the insertion of username and
password appears.
- Provide access credentials I receive notification from Microsoft
Authenticator
- confirmed identity via authenticator, the "remain connected" form
appears and I reply "yes"
The page is then shown:
"Cisco AnyConnect Secure Mobility Client"
"You have successfully authenticated. You may now close this browser
tab"
Now the VPN should be active but if I try from terminal or browser I
can't access the VPN network, despite successfully executed all the
steps.
If I close the browser page, as indicated, the network menu indicates
that the VPN is off.
Or rather, I think it's never started.
Journal reports: "Final Secrets Request Failed to Provide Sufficient
Secrets"
Strange - but not unexpected, these VPNs are terrible. I have reports
of users with AnyConnect and other SAML providers working fine with the
latest version.
There also was an unfixed issue with some newer AnyConnect servers that
was fixed with yesterday's upload, try and have a look if that makes a
difference.
If it doesn't, it sounds like you need to debug it to figure out where
it's going wrong - you can run the auth dialog in gdb and walkthrough
the code as such:
- install network-manager-openconnect-dbgsym network-manager-
openconnect-gnome-dbgsym openconnect-dbgsym libopenconnect5
-dbgsym
- create a local script somewhere with something like:
#!/bin/bash
gdbserver localhost:12345 /usr/lib/NetworkManager/nm-openconnect-auth-dialog $@
- edit temporarily /usr/lib/NetworkManager/VPN/nm-openconnect-
service.name and change auth-dialog to point to the script above
Then you'll be able to connect with gdb and debug as usual after
activating the VPN via the Gnome GUI.
---
From KDE interface:
- same configuration
- I can now select correct AUTHGROUP
However, when I click on the "Access" button, the form does not
appear
to insert the credentials.
Unlike the GNOME interface, the log log continues to report the
message
"No SSO Handler".
Thank you,
Antonio
As the message implies, KDE is not supported, nobody has done the work
to make it happen.
Il 31/12/21 01:34, Luca Boccassi ha scritto:
Control: tag -1 pending
Hello,
Bug #1001555 in openconnect reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:
https://salsa.debian.org/debian/openconnect/-/commit/145c237a574d06f348d0147390f33b5993e5b52d
-------------------------------------------------------------------
-----
Update SAML patch
Correctly detect termination on Anyconnect + Google SAML.
Also restore backward compatibility for legacy CLI based workflow.
Closes: #1001555
Gbp-Dch: full
-------------------------------------------------------------------
-----
(this message was generated automatically)
