GNOME Bugzilla – Bug 746664
Juniper SSLVPN support
Last modified: 2019-08-20 08:02:08 UTC
Openconnect now supports Juniper SSL VPN. However it seems that the NetworkManager plugin is not yet adapted to it. Would it be possible to update the plugin to enable this? From commandline, my SSL VPN connection works perfect
The Juniper Network Connect support is experimental, and has bizarre requirements for the authentication phase. We may end up having to feed HTML pages up to the auth-dialog to be rendered with something like WebKit, rather than just the simple form structure that we can currently handle. For the moment, OpenConnect manually parses the "standard" HTML forms that the Juniper server offers, but we fall over on a lot of the custom authentication pages that people can deploy. Until the dust settles, I'm not stunningly keen on starting to make it available. As a quick hack, you can build your version of libopenconnect to default to Juniper mode instead of Cisco, by changing the call to openconnect_set_protocol(vpninfo, "anyconnect") at about line 97 of library.c to openconnect_set_protocol(vpninfo, "nc") instead.
Hi David, We have some authentication pages deployed and they all seem to post the same type of data to 'login.cgi': tz_offset:"60" username:"%username%" password:"%password%" realm:"%realm%" btnSubmit:"Sign+In" tz_offset seems to be 60 for all our deployments. For username, password, realm, it would already be great to have a simple form input. I believe the layout of the page doesn't really matter. As long as you post the requested variables, the login process should proceed. BTW: it seems that openconnect cli already parses this data. Can't this be used?
This is being worked on. See thread at http://lists.infradead.org/pipermail/openconnect-devel/2016-May/003652.html
See also https://bugzilla.gnome.org/show_bug.cgi?id=765732 where Thomas is going through all the VPN plugins and separating out the GUI parts into separately-loadable "plugins", so that the basic functionality can ship without a GTK+ dependency. As noted in the thread linked from comment 3 above, we *don't* want users to have to select "Cisco AnyConnect compatible VPN (openconnect)", and then tweak an option to say "oh actually, I don't want AnyConnect at all; I want Juniper". Even though this will use the *same* underlying nm-openconnect pieces, it should be exposed as a completely separate plugin at the top level. With a completely separate /usr/lib/NetworkManager/VPN/nm-juniper-service.name file. I think most of the pieces can be re-used; only libnm-vpn-plugin-openconnect.so would need to be provided in a separate version. And with Thomas's work to make that actually load the *GUI* part via dlopen(), that's only a small piece which is now being duplicated.
Ok... basic support (barely tested) is added in https://git.gnome.org/browse/network-manager-openconnect/commit/?id=c69a180f1 and https://git.gnome.org/browse/network-manager-openconnect/commit/?id=34051bb91 In order to have nm-applet actually spawn the auth-dialog for a Juniper connection, you'll need to have NM 1.3.x or the fix from bug 765329 backported. For gnome-shell, the same problem is addressed by https://bugzilla.gnome.org/658484#c59 You have to configure it manually by hacking the text files or with nmcli. Fixing up the GUI to let you do it is discussed in bug 767197
I believe this is all now working.