FortiClient stuck at 98%: disable IPv6 on that adapter

The bar reaches 98%, the client sits there, and retyping the password changes nothing. That is the useful clue: the client already accepted the gateway certificate, sent credentials and received a tunnel configuration. What remains is bringing up the virtual adapter and confirming the tunnel carries traffic. When that last step never completes, the fault is local, and no amount of credential retyping reaches it.

Four steps, and the first one is reading the log rather than the bar.

What the 98% counter is actually reporting

The percentage is the client's own stage counter, not a measure of throughput. A stall at the same number on every attempt means the client reaches a specific step and waits, which is why a slow connection and a stuck client look different in the log. A credential problem would print a credential error instead of a silent pause.

Fortinet documented this symptom against one client-side cause: IPv6 enabled on the adapter the client uses. That makes the adapter setting the first thing to test, not a universal explanation for every SSL-VPN stall.

Step 1: read the log before the bar

Before changing anything, capture the lines immediately before the stall. You are looking for whether the tunnel adapter was created, whether an address was assigned, and whether the client gave up waiting on a family of address. A stall at a different percentage is a different stage with its own diagnosis, and a certificate warning or a wrong gateway address produces its own message rather than a silent wait. Write the timestamp down, because the next attempt appends another block to the same file.

If the log shows a completed login followed by nothing, you are in local setup and the adapter is a legitimate suspect.

Step 2: scope the IPv6 change to one adapter

The change belongs on the adapter, not on the machine. In Windows adapter properties that means clearing Internet Protocol Version 6 (TCP/IPv6) on the specific interface, and from a shell it is Disable-NetAdapterBinding -Name "Ethernet 2" -ComponentID ms_tcpip6. Confirm the state with Get-NetAdapterBinding -ComponentID ms_tcpip6 before reconnecting. Then reconnect and watch whether the bar passes 98% instead of stopping at it.

Scope first, then test. Disabling IPv6 globally is a larger change than the question requires and it affects services you did not intend to touch.

Step 3: verify what the stall was hiding

A tunnel that connects is not a tunnel that works. Check the address the client assigned, the routes the profile installed, and name resolution for one internal host: Resolve-DnsName files.corp.example. A client that connects and resolves nothing has a DNS problem, and that is easy to misread as the same fault returning.

Test one internal resource by name and one public destination, so a broken split tunnel is not mistaken for a fixed client.

Step 4: make the fix repeatable

If the setting has to reach a fleet, put it in the deployment package or the adapter configuration rather than in a manual step repeated on each laptop. Record in the ticket that the 98% stall was tied to IPv6 on the network interface, and note what else on the host depended on IPv6 before somebody re-enables it to fix something unrelated.

A fix that exists only in one engineer memory is a fix that returns next quarter.

If the bar still stops at 98% with IPv6 off, the vendor note no longer explains it and the log is your next evidence. Stop treating the symptom and go back to the stage counter.