Why openfortivpn login fails when you paste the portal URL

The failure looks like a credential problem: openfortivpn asks for the password, sends it, and the gateway answers with a rejection or a redirect back to the login page. Users then retype the password, try the domain-qualified account name, and eventually paste the browser portal URL into the host field. That last move is the one that turns a small configuration mistake into a confusing one.

A Fortinet portal address such as https://vpn.example.com/ext carries several pieces of information at once, and only some of them belong to the VPN client.

The endpoint and the realm are separate inputs

openfortivpn expects an endpoint in host or host:port form, plus an account and, where the deployment uses one, a realm value. The realm tells the gateway which authentication policy to apply before it evaluates the account. It is a separate field, not a suffix the client parses out of a URL.

For a deployment whose operator confirms the realm is ext, a non-secret invocation looks like openfortivpn vpn.example.com:443 --username=alice --realm=ext. The same values belong in the configuration file as host, port, username and realm entries. Leave the password out of both forms and let the client prompt, so it does not land in shell history or a world-readable file. A second attempt while the first client still holds the tunnel will fail for a reason that has nothing to do with the realm.

The openfortivpn manual lists both options, so the exact spelling is easy to confirm before a support call. It cannot tell you, though, which realm your gateway has configured.

A path segment is not automatically a realm

Portal URLs collect all sorts of things after the hostname: a login application, a language selector, a redirect target, a session identifier. Stripping the last path segment and calling it a realm works often enough to be dangerous. Ask the operator for the configured value, or read it from the profile your organization distributes.

A realm also is not the same thing as a domain suffix on the username or the region the gateway sits in. Some deployments want alice, others want alice@corp, and the realm decides which of those the gateway will accept. Changing the account format to compensate for a wrong realm usually produces a second, less informative rejection.

Do not fix a realm error by changing the host

Swapping the hostname for an IP address feels like removing a layer, and it breaks more than it fixes. TLS name validation compares the certificate against the name the client used, and an IP address rarely appears in a certificate's subject alternative names. Server name indication changes with the address, so a gateway hosting several portals on one address may answer with the wrong one. Keep the hostname and the trust configuration intact while you correct the authentication parameter.

If the certificate is untrusted in your environment, fix the trust store or pin the expected certificate deliberately. Disabling verification to get past a realm error trades a login problem for a silent interception risk.

Separate a rejected login from a failed tunnel

Authentication failures and tunnel failures arrive at different moments, and the messages differ. A name resolution error happens before any TLS handshake. A TLS rejection happens before credentials are sent. A realm or account rejection comes back as an HTTP-level answer from the portal. Only after those stages does PPP negotiation start, and only then do routing and DNS problems appear.

A correct realm does not create a missing route, and it does not make an unsupported sign-in method work. If the portal insists on a browser-based flow, use the client's supported path for that flow rather than replaying a password exchange and hoping the session matches.

Keep the values where the next launch will find them

Once a connection succeeds, write the gateway, port, account and realm into the managed profile instead of a shell alias. Profiles kept in a repository or a configuration management system stop the next launch from silently picking up another profile's realm.

Retest one connection end to end and confirm both the policy that was applied and access to a resource you actually need. Authentication succeeding is the start of that check, not the end of it.