Juniper or Pulse gateway: which OpenConnect protocol to use

Picking a protocol for OpenConnect is a matching exercise, not a brand lookup. A gateway that says Juniper on the login page may expose Network Connect, Pulse, or both, and the client's default is neither of them. Guessing costs a failed login and, worse, a support thread that blames credentials for a protocol mismatch. Confirm the service before you type a hostname into a profile.

OpenConnect names the older protocol nc and the newer one pulse, and both live in the same binary. The flag you choose changes the login exchange, not the routing that follows a successful connect.

The two protocol names share a product history

Juniper's Network Connect and the later Pulse Secure client are different protocols that one appliance family has exposed over time. OpenConnect grew an nc handler for the first and a pulse handler for the second. They are separate code paths with separate request formats, so support in one tells you nothing about the other.

The difference shows up immediately in the login conversation: endpoints, form fields, and the way the client reports a rejected second factor all vary between the two handlers.

Choosing on the command line is a one-word change: openconnect --protocol=nc vpn.example.com for Network Connect, or openconnect --protocol=pulse vpn.example.com for Pulse. Both attempts are real connection attempts that can reconfigure routes and DNS, so run them deliberately. Never place a password on the command line or disable certificate checks to get past a protocol error, since that hides the mismatch instead of fixing it. If you need to see what the client sends, --dump-http-traffic prints the exchange, which usually identifies the handler the gateway expects.

Match the protocol to what the gateway exposes

The appliance answers only the protocol it is configured to serve. A Pulse-only service rejects an nc login even with valid credentials, and an old Network Connect service has no pulse endpoint to answer. Ask the administrator which one is enabled, and ask which client they support. A renamed appliance, a stale wiki page, and a familiar web portal are all weak evidence.

Once you know the protocol, confirm the surrounding requirements: certificate or token authentication, an auth group selection, and any endpoint compliance check. Those decide whether a command-line client can finish the login at all.

Authentication can settle the question before protocol does

A deployment may demand a client certificate, a SAML round trip through a browser, or a host checker that inspects the machine before granting access. OpenConnect's Pulse handler documents compatibility limits for some of these flows, and the nc handler has gaps of its own. A password that works in the browser proves the account is valid; it does not prove that an arbitrary CLI or desktop plugin can complete the same sequence. When a host checker is in play, the client needs a wrapper script supplied by the administrator. Without it, the login stalls after the first response and looks like a protocol failure when it is really a missing compliance step.

Auth group selection is the other common trip point, because a gateway with several groups expects the client to name one.

On the command line, --authgroup="Employees" supplies that choice, and omitting it can land the session in a default group that rejects the account. With certificates, --certificate points at the client certificate and key, and the gateway may still require a token afterwards. Test the full sequence once with verbose output before you automate anything around it.

When the desktop frontend cannot express the choice

Graphical frontends carry their own feature sets, and an older plugin may predate the protocol you need. NetworkManager's OpenConnect integration stores the choice in its connection data, so nmcli connection modify "Office VPN" vpn.data "protocol=pulse" can set what the editor does not show. Check that the installed plugin version supports the key before assuming the edit took effect.

If a menu offers only PPTP or L2TP, choosing one does not convert a Pulse service into that protocol. Install the approved integration instead of switching to whatever the menu happens to list.

What to record when the login still fails

Record four things: the protocol you selected, the client and plugin versions, the authentication flow that was expected, and the first error that came back with a status code rather than a timeout. That set separates a wrong handler from a missing certificate, a rejected auth group, or a blocked compliance check. Verbose output is worth keeping for the same reason, because it shows the request that failed instead of only the symptom.

Keep the working command or profile next to the gateway name once it succeeds. The next person to connect will otherwise repeat the same brand-versus-protocol guess.