The usergroup cannot be specified for OpenConnect VPNs. For example, my company provides a "default" connection, which routes specific domains through the VPN, and a "tunnel-all" connection, which routes all traffic.
Typically the usergroup would be specified by the URL. For example, https://vpn.mycompany.com/tunnel-all. When using the openconnect command-line, you can use the "--usergroup=tunnel-all" command-line option.
Attempting to pass the usergroup to the gateway address (e.g. vpn.mycompany.com/tunnel-all) fails, since it expects it to only be a hostname. Ideally, either the usergroup would be parsed from the gateway address or a separate field would be available to specify it.
Linux/KDE Plasma: Arch Linux
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.80.0
Qt Version: 5.15.2
After looking through the code, it looks like it *is* trying to parse the group from the gateway. However, attempting to do this fails to connect. No error is reported in the UI, it simply closes the dialog and isn't connected to the VPN. When viewing the log from journalctl, openconnect reported the error "Pulse authentication cookie not accepted". Using the exact same URL (copy/pasted to avoid typos) works with the openconnect command in a terminal.
I additionally found that you can set an "xmlconfig" element in vpn-secrets section with a base64 XML configuration. When attempting to set the <UserGroup> tag, I get the following error in the UI: "Pulse password request with unknown code 0x00. Please report."
After some more experimentation, the behavior of whether the dialog disappears and openconnect writes the cookie error to the journal, or whether it has the "unknown code" error in the dialog, appears to be inconsistent. In other words, relying on parsing the group from the gateway and using the xmlconfig gives the same results.
This behavior was using the "Pulse Connect Secure" protocol. When using the "Juniper Network Connect" protocol any connection over the VPN times out when providing the usergroup. (even ones that give a forbidden error when not connected to the VPN at all)
Created attachment 137574 [details]
I went through the code and I believe the main problem is that only the host + port is passed to the NetworkManager-openconnect plugin that establishes the "real" connection to the VPN. I have attached a patch (usergroup.patch) that appends the urlpath (which is parsed as the usergroup) to the NM_OPENCONNECT_KEY_GATEWAY secrets parameter when it's provided.
This allows the connection to be established with the pulse protocol (since it was using the incorrect URL for the cookie). However, similar to my previous results with the "Juniper Network Connect" protocol all network activity that's routed through the VPN times out. My guess is there's some additional issues in NetworkManager-openconnect that's preventing it from working properly.
Further investigation confirms that the patch I posted should fix the issue on the plasma-nm side of not forwarding the usergroup, while separate issues in NetworkManager-openconnect (related to the split routing) are the cause of the timeout issue.
Hi, can you submit your patch to review?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-nm/-/merge_requests/57
I have submitted an MR here: https://invent.kde.org/plasma/plasma-nm/-/merge_requests/57
Git commit aa872eca0575af615ca918acbb1c8e743d1074d5 by Jan Grulich, on behalf of Aaron Barany.
Committed on 15/04/2021 at 07:55.
Pushed by grulich into branch 'Plasma/5.21'.
Forward opeconnect usergroup
Forward the usergroup for openconnect (provided by the URL path) to the
NetworkManager service by incorporating it in NM_OPENCONNECT_KEY_GATEWAY.
This ensures that the VPN session in the NetworkManager service uses the
same usergroup as provided with the gateway when the initial connection
was made through the UI.
M +7 -1 vpn/openconnect/openconnectauth.cpp