OpenConnect Login Lands on the Wrong Page? Check Path First

You paste the address from the onboarding mail, the client reaches the gateway, and the login form that appears is the general portal rather than the partner one the operator described. Nothing errors, which is what makes it confusing: the tunnel may even come up, just behind the wrong entry point. The path in that URL was doing work, and whatever replaced it dropped the work.

Separate two things that arrive as one string in a ticket: the address that reaches the service, and the input that decides where authentication starts. Repairing the first while ignoring the second is how a correct hostname still produces the wrong login.

What the client sends before you see a form

With an address like https://vpn.example.net/partners, the client's first act is an HTTPS request to that path rather than to the bare host. What comes back is usually a redirect to the sign-in endpoint, or the form itself. A client given only vpn.example.net starts at whatever the default landing page happens to be, which may be another portal, another group list, or a page expecting a different protocol altogether. The difference is visible in the response headers long before any credential is typed.

That is why a working browser tab and a failing client profile can name the same gateway and still disagree. The browser followed the path; the profile never had it.

Two inputs that look interchangeable and are not

OpenConnect exposes the initial HTTPS path as --usergroup, and the manual page treats a full URL carrying that path as the same request written differently. --authgroup is a separate option: it selects an entry from the list the gateway presents inside the login form. Some protocols label that entry a group, others a domain or a gateway, and that is exactly where the two flags get confused.

A service can legitimately need both. The path may land you on the right portal while the form still asks you to choose among groups inside it. Supplying the portal name as the group name, or the reverse, produces a login that looks accepted and then fails to authorize, because the value was syntactically valid and semantically wrong.

Ask the operator for each value on its own line: entry path, form selection, and whether both are required. Do not derive one from the other because the labels sound similar.

Why trimming the path changes the outcome

Clients that accept only a host and port will often still connect, so the symptom is rarely a hard failure. Instead you get the wrong login page, an empty group list, a certificate name that no longer matches what the operator published, or a tunnel that comes up without a route to the service you wanted. Each of those sits at a different layer, and none of them is repaired by pasting a longer string into a field documented as a hostname. Two of them are also indistinguishable from the outside, since both arrive as a login form that simply does not continue.

Replacing the hostname with an IP address is a separate mistake that often travels with this one. Name-based service selection and certificate validation both depend on the name, so a numeric address can convert a path-format problem into a TLS error.

Browser addresses carry more than paths as well. Session identifiers, redirect targets, language prefixes and temporary sign-in parameters all show up in the address bar, and none of them belong in a saved client profile.

Confirm the entry point before editing anything else

Read the headers for the path you were given. A request such as curl -sS -o /dev/null -D - https://vpn.example.net/partners prints the status line and any Location header without following the redirect. A 302 pointing at a named sign-in endpoint confirms the path exists and shows where it goes; a 404 means the operator's address is stale.

Then reproduce the same entry point in the approved client, for example openconnect --usergroup=partners vpn.example.net, and watch which form appears. If the form is correct and the tunnel still fails, the path was never the problem and the next stop is policy or routing.

Record hostname, port, protocol, entry path and form selection as five separate fields in the ticket. That list is what lets the next engineer distinguish an unreachable server from a TLS rejection, a refused selection, and a tunnel that came up without the routes it needed.