Bug 503535

Summary: OpenConnect VPN connection fails in KDE network applet due to missing SNI in TLS handshake

STEPS TO REPRODUCE:
1. Configure an OpenConnect VPN connection in NetworkManager with KDE Plasma
2. Attempt to connect to the VPN using the KDE network applet (by clicking on the connection in the system tray)
3. Enter login credentials when prompted
4. Observe the connection fails

OBSERVED RESULT:
The connection fails after entering credentials. Analysis of network traffic shows that after credential submission, a second TLS Client Hello message is sent without the SNI (Server Name Indication) extension. The server rejects this connection attempt due to the missing SNI field.

EXPECTED RESULT:
All TLS Client Hello messages should include the SNI extension with the VPN server's hostname, allowing the connection to be established successfully, as occurs when using the identical connection via the command line with "nmcli con up".

ADDITIONAL INFORMATION:
- Using Fedora with KDE Plasma
- The same connection works perfectly when activated through terminal with "nmcli con up [connection-name]"
- Adding "servername" parameter to the connection configuration in /etc/NetworkManager/system-connections/ does not resolve the issue
- This appears to be a specific issue with how the KDE network applet handles the OpenConnect protocol's TLS negotiation


SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 42
KDE Plasma Version: 6.3.4
KDE Frameworks Version: 6.13.0
Qt Version: 6.9.0
Kernel Version: 6.14.3-300.fc42.x86_64 (64-bit)
Graphics Platform: Wayland