Note: The description in the article is based on FortiGate FG-300E with FortiOS version 6.2.8. Which is configured as an FGCP cluster and uses VDOM.
Note: For a long time, I struggled with problems where VPN connections were slow and unreliable. With slightly worse signal, the VPN often disconnected. However, I must mention that in recent months, the situation has drastically improved. The connection is fast and problems don't occur. Currently, I have versions FortiOS 7.2.8 and FortiClient 7.2.4. I haven't tried turning DTLS back on.
FortiClient SSL VPN Connection Establishment
When a VPN tunnel is being established, various steps take place. Connecting to the remote server, user authentication, tunnel creation, address configuration, routing, etc. Each step should correspond to a part of the connection process (percentage), unfortunately I haven't found any overview of what happens when.
If a common problem occurs, error information is displayed. So at least we know something is happening. But when the problem described below occurs, the connection gets stuck and nothing happens.
For example, around 10%, the following warning may appear. This happens when network connectivity is not available on FortiGate (for example, internet connection is not working). The same error is displayed for later problems, but here there's no error number at the end.
Unable to establish the VPN connection. The VPN server may be unreachable.
Around 40%, there might be a problem if we're using a computer certificate for authentication. Even though the certificate is selected, the connection fails. The problem is that the use of computer certificates allow_standard_user_use_system_cert is not enabled in the configuration, more in FortiGate certificate authentication to SSL VPN.
The server you want to connect to requests identification, please choose a certificate and try again. (-5)
Around 48%, it might be the information below. The error is quite clear, an incorrect username or password was entered.
Credential or SSLVPN configuration is wrong. (-7200)
I have saved a slightly different error that also appeared with an incorrect password (maybe in an older version of FortiClient).
Unable to logon to the server. Your user name or password may not be configured properly for this connection. (-12)
Perhaps the most common error message contains very little information and appears with various problems. It occurs around 95% (but can be at other times) and looks like this.
Unable to establish the VPN connection. The VPN server may be unreachable. (-14)
The important part is the number at the end in parentheses, which probably specifies what kind of error it is. But I couldn't find any information about what the numbers mean. I found a few articles from Fortinet, but they don't help much.
- Technical Tip: Unable to establish the VPN connection. The VPN server may be unreachable (-30).
- Technical Tip: Error 'The VPN server may be unreachable (-14)' for FortiClient
- Technical Tip: Unable to establish the vpn connection. The vpn server is unreachable (-14)
- Technical Tip: Unable to establish the SSL VPN connection on Windows server
I've encountered errors -8, -14 and -20199. In all cases, it was some temporary problem, probably on the internet line, on the client, and when the connection was repeated after a while, the connection was successful.
I found out that error -8 is displayed if our connection (IP address) is temporarily blocked. It's a protection against attacks when login fails several times (most often due to an incorrect password). If we connect to the web interface, we get a clearer error.
Too many bad login attempts. Please try again in a few minutes.
On newer versions of macOS (maybe along with newer FortiClient), a problem may occur where the connection stops before it starts showing percentages. It displays
Status: Connecting
For VPN to work, after installing FortiClient, it's necessary to explicitly allow network extensions. More is described in FortiClient 7.0.1 - (macOS) Release Notes.
- open System Preferences > Security & Privacy
- on the General tab, in the lower part, there's information that system software of certain application was blocked, there's an option to Allow
It seems that the application name can be displayed differently FortiTray, FortiClientNetwork, maybe even differently. When listing systemextensionsctl list, there should be vpnprovider and FortiClientPacketFilter.
FortiClient connection stops at 98%
Perhaps the problem most often described in discussions is when (occasionally) the connection to SSL VPN on FortiGate fails and gets stuck at 98%. In practice, we experienced this problem with a significant percentage of users. For some very often, for others a few times a week. We tried various versions of FortiClient 6.0.x, 6.2.x, 6.4.x and gradual upgrades of FortiOS in the 6.2.x series.
The process is that the VPN connection starts to establish, the percentage in the client gradually increases, but when it reaches 98%, it stops here. In some cases, after a certain time (maybe a minute), the login dialog becomes accessible again (the password is cleared and we can enter it again). More often, it remains stuck and nothing happens even after several minutes. So we have to terminate with the Disconnect button. The user must make several login attempts until one goes through. Usually, it's necessary to close FortiClient or restart the computer between attempts.
There's also a related problem. If the connection stops at 98 percent and the user terminates it by clicking the Disconnect button. It very often happens that although the login dialog becomes accessible, when we try to log in again, the login doesn't proceed at all (it returns to the login dialog after a short time). You have to completely shut down FortiClient, on the application icon in the main panel (next to the clock) choose Shutdown FortiClient, and start it again.
Solution by disabling DTLS protocol
After a long time, and many attempts and debugging, it turned out that the problem in our environment is caused by using DTLS instead of TLS. By default, DTLS is not enabled in FortiClient, but Fortinet recommends its use in many places.
Disabling DTLS in FortiClient settings
- unlock the settings - click on the lock in the upper right corner
- switch to settings (gear icon)
- in the VPN Options section, uncheck the Preferred DTLS Tunnel option
Disabling DTLS on FortiGate
If we disable DTLS in the FortiClient settings, some users may connect using TLS and others using DTLS. The second option is to disable DTLS in the FortiGate configuration (enabled by default), then everyone will connect using TLS (regardless of FortiClient settings).
config vpn ssl settings
set dtls-tunnel disable
end
Note: Changing the setting doesn't terminate established VPN tunnels. It causes newly established connections to use TLS.
Datagram Transport Layer Security (DTLS)
The Datagram Transport Layer Security (DTLS) protocol is based on the TLS (Transport Layer Security) protocol (provides the same security), but uses UDP (User Datagram Protocol) in the transport layer. This makes it more efficient, performant, and faster. But applications must handle reliability, i.e., packet loss, duplication, out-of-order delivery, or large data.
Fortinet recommends (like many other manufacturers) using DTLS for greater throughput, and because it doesn't have problems with retransmission (TCP meltdown problem). For example in Technical Note: Using DTLS to improve SSL VPN performance
By default, SSL VPN uses TLS (Transport Layer Security), which runs over TCP (Transmission Control Protocol). Inside the tunnel, TCP usually runs as well, so it's referred to as TCP-in-TCP. The TCP protocol uses connections (connection / session) and guarantees reliable delivery.
According to tests, users have no problems connecting when using TLS. When using DTLS, some users have problems with establishing the tunnel (and also terminating it, as seen during debugging). If the tunnel is established, everything seems to work well.
Problems with DTLS probably occur when some datagrams are lost or poorly delivered. This can happen on lower quality internet lines, noisy WiFi networks, or (according to certain attempts) there might be a problem with the network card driver. The problems should be handled by the application, and since everything works with an established DTLS tunnel, it probably does handle them. Apparently, only the establishment and termination of the tunnel are not well handled.
It should be noted that users who had problems connecting using FortiClient connected without problems to the old VPN on Cisco ASA using Cisco AnyConnect Secure Mobility Client, which also uses DTLS.
Other attempted solutions
The problem of FortiClient connection getting stuck at 98% is widely discussed on the internet. Generally, it was common in old versions and was supposed to be fixed in FortiClient 5.6.0 thanks to a new driver (SSL VPN driver). On older versions, driver repair was often solved, for example using the Wan miniport repair tool.
The FortiOS 6.2.4 Release Notes state that the problem Bug ID 596757 with the description SSL VPN connection stuck at 95% or 98% was fixed.
Fortinet mentions in various places, as a solution to the problem of getting stuck at 98%, to increase the login timeout. This didn't help me at all. Troubleshooting Tip: Common SSL VPN
It seemed that for some people, it helped when IPv6 was disabled on the network adapter (through which the client is connected to the network). But it certainly didn't help everyone. At the moment when the affected users turned off DTLS, they could turn on IPv6 and everything worked. Disabling IPv6 is also mentioned in many discussions.
Over time, it appeared that the situation changed for people after upgrading FortiClient or FortiGate. But for some, the problem returned again. Also, some people were helped when they connected via cable instead of home WiFi.
One of the discussion threads that contains many possible solutions is VPN stuck at status 98%. For example, it states that for someone, the problem was solved by enabling DTLS.
If a user's connection stops at 98%, in the FortiGate GUI (Monitor) it's seen as correctly established and with an assigned address. For people where the connection is misbehaving, disconnection also doesn't work. When they use Disconnect in FortiClient, it says that the disconnection was successful. But on FortiGate, the client session is still visible. The session disappears only after some timeout, apparently 100 seconds.
Debug SSL VPN connection
Debug on FortiGate
- SSL VPN troubleshooting
- Troubleshooting Tip: SSL VPN Troubleshooting
- Technical Tip: SSL VPN connectivity issue with Iphone
If we also want to see the authentication process, we can enable debug mode for Remote user authentication (fnbamd is Fortinet non-blocking authentication daemon). This displays messages from all remote authentication methods. It will add many messages to the output (so I would use it only if necessary).
diagnose debug application fnbamd -1
Enabling debug mode for SSL VPN including time display for individual records.
diagnose debug application sslvpn -1 diagnose debug console timestamp enable diagnose debug enable
To disable debug mode we can use
diagnose debug disable diagnose debug reset
There are really a lot of events that get logged with each user login or logout to SSL VPN. Apparently, various connections are tried (various encryption establishment parameters) and then a large number of checks are performed to determine groups and authentication methods. Conditions whether certificate authentication, two-factor verification, etc. are required. Finally, when an IP address from the VPN range is already assigned, it looks like a new connection is established, which is then completed. In the case of DTLS, it appears that a TLS connection is established first and then DTLS.
I compared a number of logs where DTLS was used, and in some cases the connection went through correctly and in others it got stuck at 98%. The entire process is identical and differs only at the very end.
Correct progress
[23236:FW:1265]sslvpn_send_ctrl_msg:903 0x7fc8e9192600 message: svrhello ok 193.1.1.10 [23236:FW:0]RCV: LCP Configure_Request id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number 453A022A] [23236:FW:0]SND: LCP Configure_Request id(1) len(10) [Magic_Number 01084CD8] [23236:FW:0]lcp_reqci: returning CONFACK. [23236:FW:0]SND: LCP Configure_Ack id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number 453A022A] [23236:FW:0]RCV: LCP Configure_Ack id(1) len(10) [Magic_Number 01084CD8] [23236:FW:0]lcp_up: with mtu 1354 [23236:FW:0]SND: IPCP Configure_Request id(1) [IP_Address 192.168.0.1] [23236:FW:0]RCV: IPCP Configure_Request id(0) [IP_Address 0.0.0.0] [Primary_DNS_IP_Address 0.0.0.0] [Secondary_DNS_IP_Address 0.0.0.0] [23236:FW:0]ipcp: returning Configure-NAK [23236:FW:0]SND: IPCP Configure_Nak id(0) [IP_Address 10.254.0.10] [Primary_DNS_IP_Address 10.0.0.50] [Secondary_DNS_IP_Address 10.0.0.40] [23236:FW:0]RCV: IPCP Configure_Ack id(1) [IP_Address 192.168.0.1] [23236:FW:0]RCV: IPCP Configure_Request id(1) [IP_Address 10.254.0.10] [Primary_DNS_IP_Address 10.0.0.50] [Secondary_DNS_IP_Address 10.0.0.40] [23236:FW:0]ipcp: returning Configure-ACK [23236:FW:0]SND: IPCP Configure_Ack id(1) [IP_Address 10.254.0.10] [Primary_DNS_IP_Address 10.0.0.50] [Secondary_DNS_IP_Address 10.0.0.40] [23236:FW:0]ipcp: up ppp:0x7fc8e715c000 caller:0x7fc8e9192600 tun:44 [23236:FW:0]Cannot determine ethernet address for proxy ARP [23236:FW:0]local IP address 192.168.0.1 [23236:FW:0]remote IP address 10.254.0.10 [23236:FW:1265]sslvpn_ppp_associate_fd_to_ipaddr:281 associate 10.254.0.10 to tun (ssl.FW:44)
Stuck at 98%
[265:FW:3fa5]sslvpn_send_ctrl_msg:903 0x7fc8e6defc00 message: svrhello ok 193.1.1.10 [265:FW:0]RCV: LCP Configure_Request id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number 3C4CC01B] [265:FW:0]SND: LCP Configure_Request id(1) len(10) [Magic_Number 53DCFE56] [265:FW:0]lcp_reqci: returning CONFACK. [265:FW:0]SND: LCP Configure_Ack id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number 3C4CC01B] [265:FW:0]sslvpn_ppp_receive: Received non-LCP packet when LCP not open. [265:FW:0]RCV: LCP Configure_Ack id(1) len(10) [Magic_Number 53DCFE56] [265:FW:0]lcp_up: with mtu 1354 [265:FW:0]SND: IPCP Configure_Request id(1) [IP_Address 192.168.0.1] [265:FW:0]RCV: IPCP Configure_Ack id(1) [IP_Address 192.168.0.1]
For people who have connection issues, very often disconnection doesn't work. Proper communication apparently doesn't reach FortiGate and the session terminates due to timeout.
[265:FW:3b8d]sslvpn_dtls_timeout_check:326 no heartbeat received for 100 seconds. [265:FW:0]ipcp: down ppp:0x7fc8e70e5000 caller:0x7fc8e6df2600 tun:86 [265:FW:3b8d]sslvpn_ppp_deassociate_fd_to_ipaddr:318 deassociate 10.254.0.10 to tun (ssl.FW:86) [265:FW:3b8d]session removed s: 0x7fc8e6df2600 (FW) [265:FW:3b8d]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN Consultant],authserver=[PDC], portal=[VPN-Consultant],host=[193.1.1.10],realm=[company],idx=103,auth=2,sid=71fdf9c9,login=1623321538,access=1623321538, saml_logout_url=no [265:FW:0]sslvpn_internal_remove_one_web_session:2882 web session (FW:bouska:G VPN Consultant:193.1.1.10 1) removed for Lost the connection [265:FW:0]sslvpn_internal_remove_apsession_by_idx:2560 free app session, idx[103] [265:FW:3b8d]Destroy sconn 0x7fc8e6df2600, connSize=38. (FW)
Logs (debug) in FortiClient
In FortiClient settings (gear icon), we can export logs to a file. We can also increase the Log Level from the default Information to the highest Debug (we must first unlock the settings). But in the currently addressed problem, no new messages appear in the log.
The log contains only one piece of information that a timeout occurred, meaning the client didn't receive a message from FortiGate.
6/9/2021 8:41:52 AM info sslvpn FortiSslvpn: 2016: fortissl_connect: device=ftvnic 6/9/2021 8:41:52 AM info sslvpn FortiSslvpn: 17444: PreferDtlsTunnel=1 6/9/2021 8:41:57 AM error sslvpn FortiSslvpn: 17444: error: SslBlockingRead() timeout. (tm=5000, n=-1) 6/9/2021 8:41:57 AM error sslvpn FortiSslvpn: 17444: error: ssl_connect:1 6/9/2021 8:41:57 AM error sslvpn FortiSslvpn: 17444: tunnel_to_fgt error 6/9/2021 8:42:00 AM error sslvpn FortiSslvpn: 21264: error: ras_loop(), waitResult=1.
Example of debug output for a complete SSL VPN connection to FortiGate
Connection from public IP address X.X.X.X user bouska, gets assigned an address from the VPN range Y.Y.Y.Y. The connection is via TLS (DTLS is disabled in FortiClient).
[263:FW:3f08]allocSSLConn:295 sconn 0x7fc8e6c46200 (3:FW)
[263:FW:3f08]SSL state:before SSL initialization (X.X.X.X)
[263:FW:3f08]SSL state:before SSL initialization (X.X.X.X)
[263:FW:3f08]got SNI server name: vpn.firma.cz realm noncompany
[263:FW:3f08]client cert requirement: no
[263:FW:3f08]SSL state:SSLv3/TLS read client hello (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS write server hello (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS write change cipher spec (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS write finished (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS write finished:system lib(X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS write finished (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS read change cipher spec (X.X.X.X)
[263:FW:3f08]SSL state:SSLv3/TLS read finished (X.X.X.X)
[263:FW:3f08]SSL state:SSL negotiation finished successfully (X.X.X.X)
[263:FW:3f08]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
[263:FW:3f08]req: /remote/info
[263:FW:3f08]req: /remote/login
[263:FW:3f08]rmt_web_auth_info_parser_common:452 no session id in auth info
[263:FW:3f08]rmt_web_get_access_cache:787 invalid cache, ret=4103
[263:FW:3f08]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[263:FW:3f08]get_cust_page:125 saml_info 0
[263:FW:3f08]req: /remote/logincheck
[263:FW:3f08]rmt_web_auth_info_parser_common:452 no session id in auth info
[263:FW:3f08]rmt_web_access_check:706 access failed, uri=[/remote/logincheck],ret=4103,
[263:FW:3f08]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[263:FW:3f08]sslvpn_auth_check_usrgroup:2179 forming user/group list from policy.
[263:FW:3f08]sslvpn_auth_check_usrgroup:2267 got user (0) group (10:0).
[263:FW:3f08]sslvpn_validate_user_group_list:1693 validating with SSL VPN authentication rules (11), realm (noncompany).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 1 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 1 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 1 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1804 checking rule 1 vd source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 1 done, got user (0:0) group (1:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 2 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 2 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 2 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 2 done, got user (0:0) group (2:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 3 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 3 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 4 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 4 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 4 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 4 done, got user (0:0) group (3:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 5 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 5 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 6 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 6 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 6 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 6 done, got user (0:0) group (4:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 7 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 7 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 8 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 8 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 9 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 9 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 9 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 9 done, got user (0:0) group (5:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 10 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 10 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 10 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 10 done, got user (0:0) group (6:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:1746 checking rule 11 cipher.
[263:FW:3f08]sslvpn_validate_user_group_list:1754 checking rule 11 realm.
[263:FW:3f08]sslvpn_validate_user_group_list:1765 checking rule 11 source intf.
[263:FW:3f08]sslvpn_validate_user_group_list:1920 rule 11 done, got user (0:0) group (7:0) peer group (0).
[263:FW:3f08]sslvpn_validate_user_group_list:2079 got user (0:0), group (7:0) peer group (0).
[263:FW:3f08]two factor check for bouska: off
[263:FW:3f08]sslvpn_authenticate_user:174 authenticate user: [bouska]
[263:FW:3f08]sslvpn_authenticate_user:181 create fam state
[263:FW:3f08][fam_auth_send_req_internal:425] Groups sent to FNBAM:
[263:FW:3f08]group_desc[0].grpname = G VPN 7
[263:FW:3f08]group_desc[1].grpname = G VPN 6
[263:FW:3f08]group_desc[2].grpname = G VPN 5
[263:FW:3f08]group_desc[3].grpname = G VPN 4
[263:FW:3f08]group_desc[4].grpname = G VPN 3
[263:FW:3f08]group_desc[5].grpname = G VPN 2
[263:FW:3f08]group_desc[6].grpname = G VPN 1
[263:FW:3f08][fam_auth_send_req_internal:436] FNBAM opt = 0X421
[263:FW:3f08]fam_auth_send_req_internal:502 fnbam_auth return: 4
[263:FW:3f08]fam_auth_send_req:923 task finished with 4
[263:FW:3f08]fam_auth_proc_resp:1229 fnbam_auth_update_result return: 0
[263:FW:3f08][fam_auth_proc_resp:1305] Authenticated groups (1) by FNBAM:
[263:FW:3f08]Received: auth_rsp_data.grp_list[0] = 3
[263:FW:3f08]Validated: auth_rsp_data.grp_list[0] = G VPN 1
[263:FW:3f08]Auth successful for user bouska in group G VPN 1
[263:FW:3f08]fam_do_cb:657 fnbamd return auth success.
[263:FW:3f08]SSL VPN login matched rule (1).
[263:FW:3f08]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[263:FW:3f08]rmt_web_session_create:829 create web session, idx[8]
[263:FW:3f08]login_succeeded:526 redirect to hostcheck
[263:FW:3f08]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1]
,host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[263:FW:3f08]req: /remote/fortisslvpn
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=yes
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[263:FW:3f08]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[263:FW:3f08]req: /remote/fortisslvpn_xml
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=yes
[263:FW:3f08]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1],
host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[263:FW:3f08]sslvpn_reserve_dynip:1156 tunnel vd[FW] ip[Y.Y.Y.Y] app session idx[8]
[23236:FW:12d6]allocSSLConn:295 sconn 0x7fc8e70e7500 (3:FW)
[23236:FW:12d6]SSL state:before SSL initialization (X.X.X.X)
[23236:FW:12d6]SSL state:before SSL initialization (X.X.X.X)
[23236:FW:12d6]got SNI server name: vpn.firma.cz realm noncompany
[23236:FW:12d6]client cert requirement: no
[23236:FW:12d6]SSL state:SSLv3/TLS read client hello (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write server hello (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write change cipher spec (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data:system lib(X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data (X.X.X.X)
[23236:FW:12d6]got SNI server name: vpn.firma.cz realm noncompany
[23236:FW:12d6]client cert requirement: no
[23236:FW:12d6]SSL state:SSLv3/TLS read client hello (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write server hello (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 write encrypted extensions (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write certificate (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 write server certificate verify (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write finished (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data (X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data:system lib(X.X.X.X)
[23236:FW:12d6]SSL state:TLSv1.3 early data (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS read finished (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write session ticket (X.X.X.X)
[23236:FW:12d6]SSL state:SSLv3/TLS write session ticket (X.X.X.X)
[23236:FW:12d6]SSL established: TLSv1.3 TLS_AES_256_GCM_SHA384
[23236:FW:12d6]req: /remote/fortisslvpn_xml
[23236:FW:12d6]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1]
,host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=yes
[23236:FW:12d6]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1]
,host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=no
[23236:FW:12d6]req: /remote/sslvpn-tunnel?dns0=192.168.200.1
[23236:FW:12d6]sslvpn_tunnel_handler,52, Calling rmt_conn_access_ex.
[23236:FW:12d6]deconstruct_session_id:426 decode session id ok, user=[bouska],group=[G VPN 1],authserver=[PDC],portal=[VPN-1]
,host=[X.X.X.X],realm=[noncompany],idx=8,auth=16,sid=711de55e,login=1623602144,access=1623602144,saml_logout_url=yes
[23236:FW:12d6]sslvpn_tunnel_handler,148, Calling tunnel.
[23236:FW:12d6]tunnelEnter:432 0x7fc8e70e7500:0x7fc8e91fc000 sslvpn user[bouska],type 16,logintime 0 vd 3
[23236:FW:12d6]sconn 0x7fc8e70e7500 (3:FW) vfid=3 local=[192.168.0.1] remote=[X.X.X.X] dynamicip=[Y.Y.Y.Y]
[23236:FW:12d6]Prepare to launch ppp service...
[23236:FW:12d6]tun: ppp 0x7fc8e909b000 dev (ssl.FW) opened fd 48
[23236:FW:12d6]Will add auth policy for policy 24 for user bouska:G VPN 1
[23236:FW:12d6]Will add auth policy for policy 25 for user bouska:G VPN 1
[23236:FW:12d6]Will add auth policy for policy 29 for user bouska:G VPN 1
[23236:FW:12d6]Add auth logon for user bouska:G VPN 1, matched group number 1
[23236:FW:0]RCV: LCP Configure_Request id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number A778451F]
[23236:FW:0]SND: LCP Configure_Request id(1) len(10) [Magic_Number D72C524A]
[23236:FW:0]lcp_reqci: returning CONFACK.
[23236:FW:0]SND: LCP Configure_Ack id(1) len(14) [Maximum_Received_Unit 1354] [Magic_Number A778451F]
[23236:FW:0]RCV: LCP Configure_Ack id(1) len(10) [Magic_Number D72C524A]
[23236:FW:0]lcp_up: with mtu 1354
[23236:FW:0]SND: IPCP Configure_Request id(1) [IP_Address 192.168.0.1]
[23236:FW:0]RCV: IPCP Configure_Request id(0) [IP_Address 0.0.0.0] [Primary_DNS_IP_Address 0.0.0.0]
[Secondary_DNS_IP_Address 0.0.0.0]
[23236:FW:0]ipcp: returning Configure-NAK
[23236:FW:0]SND: IPCP Configure_Nak id(0) [IP_Address Y.Y.Y.Y] [Primary_DNS_IP_Address 10.0.0.50]
[Secondary_DNS_IP_Address 10.0.0.40]
[23236:FW:0]RCV: IPCP Configure_Ack id(1) [IP_Address 192.168.0.1]
[23236:FW:0]RCV: IPCP Configure_Request id(1) [IP_Address Y.Y.Y.Y] [Primary_DNS_IP_Address 10.0.0.50]
[Secondary_DNS_IP_Address 10.0.0.40]
[23236:FW:0]ipcp: returning Configure-ACK
[23236:FW:0]SND: IPCP Configure_Ack id(1) [IP_Address Y.Y.Y.Y] [Primary_DNS_IP_Address 10.0.0.50]
[Secondary_DNS_IP_Address 10.0.0.40]
[23236:FW:0]ipcp: up ppp:0x7fc8e909b000 caller:0x7fc8e70e7500 tun:48
[23236:FW:0]Cannot determine ethernet address for proxy ARP
[23236:FW:0]local IP address 192.168.0.1
[23236:FW:0]remote IP address Y.Y.Y.Y
[23236:FW:12d6]sslvpn_ppp_associate_fd_to_ipaddr:281 associate Y.Y.Y.Y to tun (ssl.FW:48)
Při dvoufázovém ověřování (heslo z mobilní aplikace FortiToken), mi to hlásilo několik různých chyb a občas se povedlo připojit, asi 1 z 20-ti pokusů. Problém zmizel, když jsem z mobilní aplikace FortiToken, odebral licenční token a poté vložil ten samý zpět.