Bug 472472 - VPN connection fails with Certificate Validation Failure because attempt to reach wrong gateway
Summary: VPN connection fails with Certificate Validation Failure because attempt to r...
Status: RESOLVED UPSTREAM
Alias: None
Product: systemsettings
Classification: Applications
Component: kcm_networkmanagement (show other bugs)
Version: unspecified
Platform: openSUSE Linux
: NOR normal
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-21 16:59 UTC by Andrea Ippolito
Modified: 2024-12-23 18:27 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
First part of the log (103.09 KB, image/png)
2023-07-21 17:01 UTC, Andrea Ippolito
Details
Relevant part of the log (102.21 KB, image/png)
2023-07-21 17:03 UTC, Andrea Ippolito
Details
Connection configuration in System settings (167.22 KB, image/png)
2023-07-21 17:15 UTC, Andrea Ippolito
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrea Ippolito 2023-07-21 16:59:36 UTC
SUMMARY
My work VPN uses cisco. The gateway is something like vpn.mycompany.com/employee.
My connection attempts works for a while. Eventually, when I am trying to connect, I would get a message saying "Certificate Validation Failure".
Upon closer inspection (enabling the "View Log" checkbox) I can see that the daemon is trying to reach vpn.mycompany.com, WITHOUT the /employee suffix. Which of course is wrong.

Eventually, this line would show up in the log:
Server requested SSL client certificate; none was configured

See screenshots.

Although this VPN connection does not require any client certificate (well, at least if targeting the /employee gateway).

SOFTWARE/OS VERSIONS
Operating System: openSUSE Tumbleweed 20230718
KDE Plasma Version: 5.27.6
KDE Frameworks Version: 5.108.0
Qt Version: 5.15.10
Kernel Version: 6.4.3-1-default (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 15.3 GiB of RAM
Graphics Processor: Mesa Intel® Xe Graphics
Manufacturer: Dell Inc.
Product Name: XPS 13 9305

ADDITIONAL INFORMATION
Comment 1 Andrea Ippolito 2023-07-21 17:01:18 UTC
Created attachment 160428 [details]
First part of the log
Comment 2 Andrea Ippolito 2023-07-21 17:03:50 UTC
Created attachment 160429 [details]
Relevant part of the log
Comment 3 Andrea Ippolito 2023-07-21 17:15:35 UTC
Created attachment 160430 [details]
Connection configuration in System settings

As you can see here, the /employee part is still present.

I have also checked the NetworkManager file for this connection, to check if the /employee part gets dropped somewhere there, and indeed it seems that while [vpn].gateway keeps the original value, [vpn-secrets].lasthost holds the gateway without the /employee suffix. I suspect that this could be the root cause. But I don't know if it's KDE Daemon's fault or NM's.

sudo cat "/etc/NetworkManager/system-connections/New vpn connection.nmconnection"



[connection]
id=My VPN
uuid=095e444c-f674-47c4-a642-292e70f6af8b
type=vpn

[vpn]
cookie-flags=2
enable_csd_trojan=no
gateway=mycompany.com/employee
gateway-flags=2
gwcert-flags=2
pem_passphrase_fsid=no
prevent_invalid_cert=no
protocol=anyconnect
reported_os=linux-64
stoken_source=disabled
stoken_string-flags=0
service-type=org.freedesktop.NetworkManager.openconnect

[vpn-secrets]
autoconnect=no
form:main:username=myUserName
lasthost=mycompany.com
save_passwords=no
stoken_string=
xmlconfig=<edited>

[ipv4]
method=auto

[ipv6]
addr-gen-mode=default
method=auto

[proxy]
Comment 4 Andrea Ippolito 2023-07-21 17:22:21 UTC
Ok I have just confirmed that this happens after the first time you enter your credentials.
Before that, the network manager connection file looks pretty empty.

Once you enter your credentials and connect, the file gets updated with lasthost, among many other parts. And I suspect that this lasthost value is taking the gateway value and dropping anything that comes after "/", resulting in a wrong value that gets used at the next connection attempt (which will fail).

I think this might not even need reproducing on your side, just check if there's some logic in the code that stops at the first occurrence of "/".
Comment 5 Andrea Ippolito 2023-07-21 17:33:56 UTC
I tried to search through the code but C++ is really not my cup of tea :D

I have found some places where the config is written back to the nm file:

https://github.com/KDE/networkmanagement/blob/7968c8101f5b561c59de6dec0f0e0aacf06ca1bf/vpnplugins/openconnect/openconnectauth.cpp#L275

https://github.com/KDE/plasma-nm/blob/6b4c1f1d780d99fa48b776a4b70a58bc4b8ef734/vpn/openconnect/openconnectauth.cpp#L448
Comment 6 Andrea Ippolito 2023-07-21 17:39:39 UTC
What is also weird and potentially cause of trouble, is that the UI is showing as VPN Host the gateway without the /employee part.
This can be seen in this attachment:
https://bugs.kde.org/attachment.cgi?id=160429
Comment 7 Andrea Ippolito 2023-07-25 09:11:58 UTC
I was able to reproduce this in a gnome session too (Fedora 38, gnome wayland).
I struggle to understand which project is in charge of this. Whether it's NetworkManager, or something on top, e.g. some openconnect plugin.
The UI for authenticating to the VPN looks the same between gnome and KDE, except for the obvious UI toolkit differences.
Comment 8 Andrea Ippolito 2023-07-29 12:00:29 UTC
(In reply to andrea.ippo from comment #7)
> I was able to reproduce this in a gnome session too (Fedora 38, gnome
> wayland).
> I struggle to understand which project is in charge of this. Whether it's
> NetworkManager, or something on top, e.g. some openconnect plugin.
> The UI for authenticating to the VPN looks the same between gnome and KDE,
> except for the obvious UI toolkit differences.

Reported upstream here:

https://gitlab.gnome.org/GNOME/NetworkManager-openconnect/-/issues/105

I think this can be closed.