| Solution |
The cause may vary depending on the percentage the negotiation stops at:
- 10%.
- The error may be 'Unable to establish the VPN connection. The VPN server may be unreachable.
- The issue is usually due to a network connection.
- Check whether the PC can access the internet and reach the VPN server on the necessary port.
- Make sure to be able to telnet the SSL VPN server IP on the SSL VPN port on the remote system.
- Check whether the correct remote Gateway and port are configured in FortiClient settings.
- Confirm whether the server certificate has been selected in FortiGate SSL VPN settings.
- Check the firewall policy to make sure there is at least one policy with an Incoming Interface as an SSL VPN tunnel interface (ssl.root).
- Check if any VIP is configured for the SSL VPN port. (Or) No VIP should be configured for the WAN IP used for VPN without port forwarding enabled.
- Check restrictions based on Geolocation in SSL VPN settings or a local-in-policy that could prevent the endpoint from connecting.
- Try to reach the VPN URL from the browser to confirm connectivity.
- Make sure the setting 'Restrict access' is set to 'Allow access from any host'. If it is set to 'Limit access to specific host', make sure the client's public IP is allowed.
- Sometimes, if a source address is defined in the SSL VPN settings and the Source negate option is enabled in the VPN setting on the CLI, then the process will also fail at 10%. Disabling source-address-negate will make it pass this 10% fail error.
config vpn ssl setting
set source-address-negate disable
end
- Make sure that the SSL VPN is enabled.
- Check the router/modem's port-forwarding settings if there is another routing/internet-facing device before the firewall (SSL VPN behind NAT - Fortinet Community).
- If the virtual interface (for example, ssl.root when SSL VPN is configured on the root VDOM) is down, users will experience connectivity failures. Ensure that the virtual interface status is set to 'up'. This setting is visible in the CLI, and by default, the status is 'up'.
config system interface
edit "ssl.root"
set vdom "root"
set status down
set type tunnel
set alias "SSL VPN interface"
set snmp-index 14
next
end
- Running the sniffer will show if the traffic is coming on the FortiGate over the SSL VPN port and if the FortiGate is responding to it.
diagnose sniffer packet any ' host <source public IP address> and port <SSL VPN port> ' 4 0 l
If FortiGate responds, when the TCP 3-way handshake does not complete or the client resets the connection after TCP 3-way handshake completes, the connection will terminate, and FortiClient will display it stopped at 10%.
If the traffic is coming but FortiGate is not responding, debug commands will show if it is matching any deny policy or getting denied by a no policy match
diagnose debug disable
diagnose debug reset
diagnose debug flow show iprope en
diagnose debug flow show func en
diagnose debug flow filter addr <source public ip addr>
diagnose debug flow filter port <SSL VPN port>
diagnose debug flow trace start 300
diagnose debug enable
- 31%.
Negotiation stops at this percentage with error -5029. If this message appears, there is a mismatch in the TLS version. Check if the TLS version that is in use by the FortiGate is enabled on the client. Technical Tip: How to limit the SSL and TLS versions of connections initiated by FortiClient explains how to check the TLS version.
- 40%.
- This may occur when FortiClient generates a new pop-up window verifying whether the user wishes to proceed with a non-trusted TLS/SSL certificate.
- It may mean a TLS version mismatch, which will also show as error -5029. If this message appears, there is a mismatch in the TLS version. Check if the TLS version that’s in use by the FortiGate is enabled on the client. Technical Note: How to limit the SSL and TLS versions of connections initiated by FortiClient explains how to check the TLS version.
- An application or the FortiGate may cause this error. Check the local machine and network setup. If the VPN server is unreachable with a (-5) error, see .
- Wrong Port Forwarding using VIPs. If seeing inappropriate DNAT taking place in the Debug flow, check the VIP configuration; they might have services-ALL enabled, switch it to ALL_TCP.
- This can happen because the FortiGate custom server certificate has expired. Select the 'Fortinet_Factory' certificate as a workaround.
- If SAML authentication is used, check the certificate and make sure that the correct certificate is downloaded from the IDP and imported into the SP (FortiGate).
- 42 or 43%.
- Negotiation stops at this percentage if there is any issue with authentication (sslvpn_login_permission_denied)
For local users, the issue could be just the username/password being incorrect. Ensure that the username is entered with proper case, exactly as it was created. For the remote users, the issue is still related to authentication. The following error can be seen in sslvpn -1 and fnbamd -1 debugs: 'find_matched_usr_grps-Failed group matching'. The following debugs can be used to verify if the user belongs to the LDAP user group. If not, adding the user to the correct group can resolve this issue.
diagnose debug disable
diagnose debug reset
diagnose debug application sslvpn -1
diagnose debug application fnbamd -1
diagnose debug enable
- 45%.
- Negotiation stops at this percentage if there is any authentication issue.
For local users, the issue could be just the username/password being incorrect.
- For the remote users, the issue is still related to authentication, but the root causes can be different. A few possible reasons: FortiGate is unable to reach the remote server, the remote server is sending an authentication failure, or the secure connection is failing for LDAPS.
Example: If negotiation stops at this percentage with the error 'ldap connection timeout', adjust the timeout settings:
config system global
set ldapconntimeout 300000
end
Looking for the SAML reference at the end.
- 48%.
- Negotiation stops at this percentage if there is an issue with two-factor authentication.
- If negotiation stops at this percentage with the error 'Credential or SSL VPN configuration is wrong (-7200)', recheck the credentials.
- To resolve the 'Credential or SSL VPN configuration is wrong (-7200)' error, follow the steps in this article: Troubleshooting Tip: When logging in with SSL VPN, the error 'Credential or SSL VPN configuration is....
- Failure to connect via SSL VPN with 'Credential or SSL VPN configuration is wrong. (-7200)' message with 'sslvpn_login_cert_checked_error': Troubleshooting Tip: Failure to connect via SSL VPN with 'Credential or SSLVPN configuration is wron....
- 'Permission denied. (-455)' error. Check if the user is included in the user group that is configured in SSL VPN Authentication/Portal Mapping settings.
- With SAML authentication, check if the login prompt is presented. If it is, try increasing the remote auth timeout under global settings. If two-factor authentication is expiring, it will generate a failure at 48%. If it is 5 seconds, it can be increased to 120 or 180 seconds as per the following CLI commands.
Those are the seconds that the FortiGate waits for a response from remote authentication. In the case of multifactor authentication, if the timer is less than, the session will expire and FortiGate will close the connection, leading it to fail at 48%.
The SSL VPN waits for 10x remote timeout +30 (s) for a valid token code to be provided before closing down the connection, even if the token code is valid for longer.
Example: If 240s is set for two-factor-email-expiry, the remote timeout must be greater than or equal to 21.
240 = 10x remote timeout + 30 <=> remote timeout = 21.
Note: For SSL VPN authentication with Azure SAML, the remoteauthtimeout is doubled. For example, when set to 30 seconds, those will become 60 seconds when the user waits for the password.
config system global
set remoteauthtimeout 120 <----- The seconds that the FortiGate waits for a response from the remote authentication server.
end
- Host check requirement error (-455). If there is no host check enabled on VPN portals and users are still getting this error, check if the firewall has 'sslvpnd' daemon crashes. To check crash logs on FortiGate, execute this command:
diagnose debug crashlog read
Looking for the SAML reference at the end.
- 80%.
- Ensure tunnel mode is enabled on the SSL VPN portal.
- It may feature an error such as 'Unable to log on to the server. The username or password may not be configured properly for this connection'.
- Negotiation stops at this stage due to issues with user privileges.
- If negotiation stops at this stage, check whether the username and password were entered correctly.
- Check the user and user group. This issue often occurs if the user is not in the correct user group with VPN access.
- The -14 error of around 80% could be because of a user/group mismatch between the SSL VPN authentication rules and the Firewall policy for SSL VPN. (Related article: Technical Tip: VPN Server may be unreachable (-14) ).
- It is possible to have a user and a group configured, but it must be exactly the same in SSL VPN authentication rules and Firewall policy.
- If a user has a configured user group in the SSL VPN settings, always configure the user group in the firewall policy (follow this article: Technical Tip: FortiClient drops at 70-80% with no error message).
- Verify that the user is also matching the correct portal.
- Make sure the portal has tunnel mode enabled if trying to log in to VPN using FortiClient.
- This issue may occur if a corresponding policy for the users has not been configured.
- Additionally, check whether the correct Realm is being used and if any are configured.
- If a user tries to log in from the local/guest user, make sure the 'Restrict to Specific OS Versions' is disabled.
- Look for the host check/MAC address check/AV check to be enabled.
- Firmware Downgrade or Rollback of FortiGate may change the original SSL-VPN portal settings, so double-check if tunnel-mode or web-mode is enabled from the past configuration.
- 89%.
- At this stage, FortiTray.exe will try to write to 'fortisslvpn_xml.txt', which is located on '%localappdata%\FortiClient'.
- If %localappdata%\FortiClient is inaccessible, an error code -5052 will appear.
- If %localappdata%\FortiClient is accessible but fortisslvpn_xml.txt can not be modified, error -5053 will appear instead.
- Running this command in CMD can provide a hint on why fortitray.exe can not modify fortisslvpn_xml.txt:
notepad %localappdata%\FortiClient\fortisslvpn_xml.txt
- 98%.
- Issues at this stage indicate an inability to establish a tunnel after authentication is already completed.
- Can be caused by network issues - for example, IPv6 to IPv4 connections (not supported), high network latency, blocked traffic, or traffic inspection between FortiClient and FortiGate (see Troubleshooting Tip: SSL VPN fails at 98%).
- This may be related to a corrupted FortiClient installation (see Troubleshooting Tip: SSL VPN fails at 98%).
- Unable to establish the VPN connection. The VPN server may be unreachable. (0).
- Make sure the respective user/usergroup is configured on SSL VPN authentication rules.
- Make sure the respective user/usergroup is configured on the firewall policy.
Note:
Starting with FortiClient 7.4.4, IKEv1 is no longer supported on the client. Therefore, plan accordingly when choosing the IKE version. Use IKEv2 if planning on deploying FortiClient 7.4.4 and later.
Starting v7.6.3, the SSL VPN tunnel mode will no longer be supported, and SSL VPN web mode will be called 'Agentless VPN':
SSL VPN tunnel mode replaced with IPsec VPN
Agentless VPN
SAML reference: Items 6 and 5 happen together, the percentage stops at 45%, but the solution is to increase the remoteauthtimeout, which is the change suggested for cases on item 6.
Migrate SSL VPN to IPsec VPN:
SSL VPN to IPsec VPN
SSL VPN full tunnel for remote user
Related document:
Troubleshooting Tip: SSL VPN Troubleshooting
|
