Juniper SSL VPN / Pulse Connect Secure
Support for Juniper's Network Connect protocol was added to OpenConnect in early 2015, for the 7.05 release. It is an extremely convoluted and quirky protocol, but OpenConnect's support for it is believed to be nearly complete. The most glaring problem with the Pulse protocol is that it does not support IPv6 at all.
Following Juniper's 2015 announcement, the Juniper protocol has been largely deprecated and replaced with the Junos/Ivanti Pulse protocol. However, as of 2023 Junos/Ivanti servers continue to support the Juniper Network Connect protocol alongside the Pulse protocol, unless explicitly disabled by administrators.
Juniper mode is requested by adding --protocol=nc to the command line:
openconnect --protocol=nc vpn.example.com
Network Connect works very similarly to AnyConnect — initial authentication is made over HTTP, resulting in an HTTP cookie which is used to make the actual VPN connection. That connection is also made over HTTP, and the IP address and routing information are provided by the VPN server. The client then attempts to bring up a UDP transport, which in the case of Juniper is ESP.
Authentication
The authentication stage with Juniper is what is expected to cause most problems. Unlike AnyConnect which has a relatively simple XML schema for interacting with the user, the Juniper VPN expects a full web browser environment and uses HTML forms with JavaScript and even full-blown Java support.
The common case is relatively simple, and OpenConnect supports the common forms defined by the Juniper-provided templates. However, administrators have the facility to put arbitrary HTML pages into the login sequence and full compatibility may require actually using a web browser to log in — ironically, since much of the reason users have been asking for OpenConnect to support Juniper is because they didn't want to have to use a web browser.
For NetworkManager we may end up putting a full HTML renderer into the GUI authentication dialog, while the command line client continues to parse the common login forms and make a best attempt at handling anything non-standard.
External authentication
There are a number of perl and python scripts which handle authentication to Juniper servers to bypass the web browser. One such script has been ported to invoke OpenConnect instead of Juniper's own ncsvc client and can be found here.
Any of these scripts which authenticate and obtain a DSID cookie representing a VPN session can be used with OpenConnect. Just pass the cookie to OpenConnect with its -C option, for example:
openconnect --protocol=nc -C "DSID=foobar12345" vpn.example.com
Host Checker (tncc.jar)
Many sites require a Java applet to run certain tests as a precondition of authentication (similar to CSD for AnyConnect VPNs and HIP for GlobalProtect VPNs). See the Host Checker / TNCC page for how to configure OpenConnect to wrap and run this applet.
Connectivity
Once authentication is complete, the VPN connection can be established. At the time of writing much of the configuration for Legacy IP addressing and routes is understood and implemented. IPv6 is not yet implemented, and test reports from someone with an IPv6-capable server would be greatly appreciated.
The data transport is functional both over the HTTPS session and also over ESP. Servers with compression enabled should also be supported, as LZO decompression is working and although we lack compression support it appears acceptable to simply send packets uncompressed.
At the time of writing, keepalive for the ESP connection has been implemented and extremely lightly tested, while it isn't yet known if the VPN supports keepalive on the HTTPS connection. Reconnection of both the HTTPS and ESP links is implemented. The current implementation is basically usable and is definitely ready for some more widespread testing.