pop-os/cosmic-settings#1988, #1756, #1857, pop-os/cosmic-applets#1367
VpnType recognizes openconnect/l2tp/pptp/strongswan and connect_vpn_by_uuid activates them. the secret agent supports VPN hints and vpn_secrets(map). but there is no mechanism to drive a VPN plugin auth-dialog binary (e.g. nm-openconnect-auth-dialog) or handle the cookie/gateway/gwcert tuple that openconnect expects.
in practice this means openconnect connections activated from COSMIC fail with "No valid secrets" because the secret agent only hands back a single password where NM expects a multi-field response. users with openconnect, AnyConnect, or fortinet VPNs fall back to nm-applet or nmcli --ask.
builders currently exist only for openvpn and wireguard. at minimum nmrs needs a way to:
- detect that the VPN plugin requires an external auth-dialog
- either invoke it or surface enough info for the consumer to drive the flow
- respond with the full secret map the plugin expects
pop-os/cosmic-settings#1988, #1756, #1857, pop-os/cosmic-applets#1367
VpnTyperecognizes openconnect/l2tp/pptp/strongswan andconnect_vpn_by_uuidactivates them. the secret agent supports VPN hints andvpn_secrets(map). but there is no mechanism to drive a VPN plugin auth-dialog binary (e.g.nm-openconnect-auth-dialog) or handle the cookie/gateway/gwcert tuple that openconnect expects.in practice this means openconnect connections activated from COSMIC fail with "No valid secrets" because the secret agent only hands back a single password where NM expects a multi-field response. users with openconnect, AnyConnect, or fortinet VPNs fall back to
nm-appletornmcli --ask.builders currently exist only for openvpn and wireguard. at minimum nmrs needs a way to: