lowVPN (IPsec / SSL)

Troubleshooting FortiGate SSL VPN with sslvpn daemon debug

Confirmed 7/30/2026

Problem

Use the FortiGate SSL VPN daemon debug to investigate tunnel establishment, TLS negotiation, user authentication, authentication-rule and portal selection, IP assignment, and firewall-policy matching.

Environment

FortiGate using SSL VPN for remote access.

Solution

Identify the SSL VPN client's public IPv4 address. Replace <x.x.x.x> in the filter below with that address so the output is limited to the affected client.
Reset existing debug settings, enable console timestamps, apply the source-address filter, enable full sslvpn application debugging, and start debugging:

diagnose debug reset
diagnose debug console timestamp enable
diagnose vpn ssl debug-filter src-addr4 <x.x.x.x>
diagnose debug application sslvpn -1
diagnose debug enable

Reproduce the SSL VPN connection problem and collect the resulting output. Review the debug for the following stages and values:
- TLS negotiation. A successful example is:

[751:root:15]SSL state:SSLv3/TLS read client hello (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS write server hello (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS write change cipher spec (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS write finished (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS write finished:system lib(10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS write finished (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS read change cipher spec (10.47.2.32)
[751:root:15]SSL state:SSLv3/TLS read finished (10.47.2.32)
[751:root:15]SSL state:SSL negotiation finished successfully (10.47.2.32)
[751:root:15]SSL established: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384

The SSL established entry identifies the negotiated TLS version and cryptographic suite used by the client and FortiGate during the handshake.

User lookup and SSL VPN rule evaluation. In this example, jclar matches a local user entry, two-factor authentication is off, and SSL VPN authentication rule 1 is evaluated:

[751:root:15]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[751:root:15]rmt_logincheck_cb_handler:1283 user 'jclar' has a matched local entry.
[751:root:15]sslvpn_auth_check_usrgroup:2962 forming user/group list from policy.
[751:root:15]sslvpn_auth_check_usrgroup:3008 got user (1) group (0:0).
[751:root:15]sslvpn_validate_user_group_list:1850 validating with SSL VPN authentication rules (1), realm ().
[751:root:15]sslvpn_validate_user_group_list:1970 checking rule 1 cipher.
[751:root:15]sslvpn_validate_user_group_list:1978 checking rule 1 realm.
[751:root:15]sslvpn_validate_user_group_list:1989 checking rule 1 source intf.
[751:root:15]sslvpn_validate_user_group_list:2028 checking rule 1 vd source intf.
[751:root:15]sslvpn_validate_user_group_list:2570 rule 1 done, got user (1:0) group (0:0) peer group (0).
[751:root:15]sslvpn_validate_user_group_list:2864 got user (1:0), group (0:0) peer group (0).
[751:root:15]sslvpn_update_user_group_list:1792 got user (1:0), group (0:0), peer group (0) after update.
[751:root:15]two factor check for jclar: off

Authentication processing and result. These entries show that FNBAM authenticated jclar and that SSL VPN rule 1 matched:

[751:root:15]sslvpn_authenticate_user:183 authenticate user: [jclar]
[751:root:15]sslvpn_authenticate_user:197 create fam state
[751:root:15]fam_auth_send_req:882 found node jclar:0:, valid:1
[751:root:15][fam_auth_send_req_internal:426] Groups sent to FNBAM:
[751:root:15]group_desc[0].grpname = jclar
[751:root:15][fam_auth_send_req_internal:438] FNBAM opt = 0X201420
[751:root:15]fam_auth_send_req_internal:514 fnbam_auth return: 0
[751:root:15][fam_auth_send_req_internal:539] Authenticated groups (1) by FNBAM with auth_type (1):
[751:root:15]Received: auth_rsp_data.grp_list[0] = 16777218
[751:root:15][fam_auth_send_req_internal:652] The user jclar is authenticated.
[751:root:15]fam_do_cb:665 fnbamd return auth success.
[751:root:15]SSL VPN login matched rule (1).

Session creation and portal selection. The example records public IP 211.25.130.154, successful authentication, and assignment to the full-access portal:

[751:root:15]got public IP address: 211.25.130.154
[751:root:15]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[751:root:15]rmt_web_session_create:1209 create web session, idx[0]
[751:root:15]login_succeeded:536 redirect to hostcheck
[751:root:15]User Agent: FortiSSLVPN (Windows NT; SV1 [SV{v=02.01; f=07;}])
[751:root:15]deconstruct_session_id:709 decode session id ok, user=[jclar], group=[],authserver=[],portal=[full-access],host[10.47.2.32],realm=[],csrf_token=[23154DC8DF6C5BAEB0337AA3EA1DFD6],idx=0,auth=1,sid=73497ade,login=1655001325,access=1655001325,saml_logout_url=no,pip=211.25.130.154,grp_info=[B4LsOZ],rmt_grp_info=[]

Tunnel address and firewall-policy matching. The example assigns 10.212.134.200 to jclar on ssl.root and matches firewall policy ID 2:

[751:root:16]tunnel2_enter:1142 0x7fea06956500:0x7fea05b6dc00 sslvpn user[jclar],type 1,logintime 0 vd 0 vrf 0
[751:root:16]tun dev (ssl.root) opened (37)
[751:root:16]Will add auth policy for policy 2 for user jclar:
[751:root:16]Add auth logon for user jclar:, matched group number 1
[751:root:16]fsv_associate_fd_to_ipaddr:1922 associate 10.212.134.200 to tun (ssl.root:37)
[751:root:16]proxy arp: scanning 6 interfaces for IP 10.212.134.200
[751:root:16]Cannot determine ethernet address for proxy ARP

Correlate timestamped events, especially errors, with the time reported by the user. Timestamps are important when investigating intermittent behavior or establishing an event sequence. Ensure that all SSL VPN nodes have the correct system time, and record the timestamps of relevant messages.
Stop debugging and clear the debug configuration after collecting the data:

diagnose debug disable
diagnose debug reset

If SSL VPN provides remote access, plan migration to IPsec VPN before upgrading to firmware that removes SSL VPN tunnel-mode support.

Verification

Confirm that the debug shows SSL negotiation finished successfully, an SSL established line with the negotiated TLS version and suite, The user <username> is authenticated, fnbamd return auth success, and SSL VPN login matched rule (<rule-id>). Also verify that the expected portal, tunnel IP, and firewall policy appear. In the supplied example, user jclar matches rule 1, receives portal full-access and IP 10.212.134.200, and is allowed by firewall policy ID 2.

Rollback

Disable and reset debugging after the capture:

diagnose debug disable
diagnose debug reset

Community rating

— / 5 (0)

Discussion (0)

No comments yet.