FortiClient - Reconnect without reauth broken?

[msundman]

I'm trying to get FortiClient to re-connect without re-authenticating after short network outages as described in this article:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configuring-SSL-VPN-to-allow-tunnel-reconn...

I've tried various versions of FortiClient 7.0.x on Windows but they all enter loop where they tries to re-connect but fails every time. MacOS FCT 7.0.x clients doesn't even seem to care about the tunnel-connect-without-reauth option.

I've tried all these combinations without success:

Win10 FCT v7.0.5 ZTNA -> FortiOS 6.4.10 SAML: Reconnect / Disconncect loop
Win10 FCT v7.0.5 ZTNA -> FortiOS 7.0.8 SAML: Reconnect / Disconncect loop
Win2019 FCT v7.0.7 ZTNA -> FortiOS 6.4.10 SAML: Reconnect / Disconncect loop
Win2019 FCT v7.0.7 ZTNA -> FortiOS 7.0.8 SAML: Reconnect / Disconncect loop
Win2019 FCT v7.0.7 ZTNA -> FortiOS 7.2.2 SAML: Reconnect / Disconncect loop
Win2019 FCT v7.0.7 ZTNA -> FortiOS 7.2.2 Local FW User: Reconnect / Disconncect loop
MacOS 12.3.1 FCT v7.0.6 ZTNA -> FortiOS 6.4.10 SAML: No reconnect
MacOS 12.3.1 FCT v7.0.6 ZTNA -> FortiOS 7.0.8 SAML: No reconnect

I just got hold of a pre-release version of FortiClient 7.2.0 for MacOS that actually works!

With the "broken" Windows FortiClient 7.0.x connecting to FortiOS 7.2.2 shows the following debug logs when attempting to reconnect:

[199:root:6b]allocSSLConn:306 sconn 0x7f45720e5600 (0:root)
[199:root:6b]SSL state:before SSL initialization (185.40.184.19)
[199:root:6b]got SNI server name: rmsit-vpn.it-total.se realm (null)
<cut>
[199:root:6b]req: /remote/sslvpn-tunnel2?dns0=100.100.16.1
[199:root:6b]sslvpn_tunnel2_handler,59, Calling rmt_conn_access_ex.
[199:root:6b]deconstruct_session_id:716 decode session id ok, user=[msntest@rmsit.se], group=[rmsit-vpn],authserver=[azure-rmsit],portal=[full-access],host[185.40.184.19],realm=[],csrf_token=[9D175BC042172724028322A292D9CAF],idx=0,auth=256,sid=423b56a6,login=1668114751,access=1668114751,saml_logout_url=yes,pip=no,grp_info=[SeTjih],rmt_grp_info=[XdLLRf]
[199:root:6b]normal tunnel2 request received.
[199:root:6b]sslvpn_tunnel2_handler,166, fct_uuid = 0DAE0661B838411A8B8294957F45C7B7
[199:root:6b]sslvpn_tunnel2_handler,173, Calling tunnel2.
[199:root:6b]tunnel2_enter:1155 0x7f45720e5600:0x7f4571483000 sslvpn user[msntest@rmsit.se],type 256,logintime 0 vd 0 vrf 0
[199:root:6b]tunnel2_enter:1171 no more IP address available.
[199:root:6b]enter() returned task error.
[199:root:6b]Destroy sconn 0x7f45720e5600, connSize=1. (root)
[199:root:6b]fsv_tunnel2_state_cleanup:1676 0x7f45720e5600::0x7f4571483000
[199:root:6b]fsv_disassociate_fd_to_ipaddr:1961 deassociate 0.0.0.0 from tun (ssl.root:-1)
[199:root:6b]SSL state:warning close notify (185.40.184.19)

With the working 7.2.0 FortiClient the debug log shows:

[199:root:33f]allocSSLConn:306 sconn 0x7f45720e6b00 (0:root)
[199:root:33f]SSL state:before SSL initialization (155.4.221.225)
[199:root:33f]got SNI server name: rmsit-vpn.it-total.se realm (null)
<cut>
[199:root:33f]req: /remote/sslvpn-tunnel2?uuid=19BAD313AEC1
[199:root:33f]sslvpn_tunnel2_handler,59, Calling rmt_conn_access_ex.
[199:root:33f]deconstruct_session_id:716 decode session id ok, user=[test], group=[],authserver=[],portal=[full-access],host[155.4.221.225],realm=[test],csrf_token=[7C111855E54DAE58ABFFB1B2C1FCE3],idx=1,auth=1,sid=4ec2f098,login=1668184814,access=1668184814,saml_logout_url=no,pip=155.4.221.225,grp_info=[68AKth],rmt_grp_info=[]
[199:root:33f]normal tunnel2 request received.
[199:root:33f]sslvpn_tunnel2_handler,166, fct_uuid = 19BAD313AEC156F59DD19B60B59705C1
[199:root:33f]sslvpn_tunnel2_handler,173, Calling tunnel2.
[199:root:33f]tunnel2_enter:1155 0x7f45720e6b00:0x7f4571447000 sslvpn user[test],type 1,logintime 0 vd 0 vrf 0
[199:root:33f]tun dev (ssl.root) opened (34)
[199:root:33f]Will add auth policy for policy 7 for user test:
[199:root:33f]Add auth logon for user test:, matched group number 1
[199:root:33f]fsv_associate_fd_to_ipaddr:1930 associate 10.212.134.100 to tun (ssl.root:34)
[199:root:33f]proxy arp: scanning 9 interfaces for IP 10.212.134.100
[199:root:33f]Cannot determine ethernet address for proxy ARP
[199:root:33c]rmt_check_conn_apsession:1794 delete connection 0x7f45720e7900 w/ app session 1
[199:root:33c]Destroy sconn 0x7f45720e7900, connSize=1. (root)
[199:root:33c]fsv_tunnel2_state_cleanup:1676 0x7f45720e7900::0x7f4571427000
[199:root:33c]fsv_disassociate_fd_to_ipaddr:1961 deassociate 10.212.134.101 from tun (ssl.root:23)
[199:root:33c]SSL state:warning close notify (90.129.202.118)

The main difference I can see is the argument used on the req: /remote/sslvpn-tunnel2 request.

Anyone who knows more about this issue? Any working Windows FortiClient versions (non-beta)?

[Jean-Philippe_P]

Hello msundman!

Thank you for posting on the Fortinet Community Forum!

I will look for assistance in order to help you to resolve your issue. I or an engineer will reply back soon directly to this post.

Kindest regards,

[msundman]

I've further investigated this issue during the weekend and have concluded:

FortiClient 6.4.9 on Windows can successfully use the tunnel-connect-without-reauth to re-establish the session. The relevant part of the re-connect shows the following debug messages:

[199:root:9b9]req: /remote/fortisslvpn_xml
[199:root:9b9]deconstruct_session_id:716 decode session id ok, user=[test], group=[rmsit-vpn-local],authserver=[],portal=[full-access],host[185.40.184.19],realm=[],csrf_token=[92B0A33FD8DBDEBC1CA481773F66],idx=0,auth=1,sid=6e726126,login=1668403889,access=1668403889,saml_logout_url=no,pip=185.40.184.19,grp_info=[TlQPJh],rmt_grp_info=[]
[199:root:9b9]sslvpn_reserve_dynip:1470 tunnel vd[root] ip[10.212.134.101] app session idx[1]
[199:root:9b9]req: /remote/sslvpn-tunnel?dns0=100.100.16.10
[199:root:9b9]deconstruct_session_id:716 decode session id ok, user=[test], group=[rmsit-vpn-local],authserver=[],portal=[full-access],host[185.40.184.19],realm=[],csrf_token=[92B0A33FD8DBDEBC1CA481773F66],idx=0,auth=1,sid=6e726126,login=1668403889,access=1668403889,saml_logout_url=no,pip=185.40.184.19,grp_info=[TlQPJh],rmt_grp_info=[]
[199:root:9b9]sslvpn_tunnel_handler,109, fct_uuid = 0DAE0661B838411A8B8294957F45C7B7
[199:root:9b9]sslvpn_ppp_associate_fd_to_ipaddr:281 associate 10.212.134.101 to tun (ssl.root:36)
[199:root:9b8]sslvpn_ppp_deassociate_fd_to_ipaddr:318 deassociate 10.212.134.100 to tun (ssl.root:34)

However, the "broken" 7.0.x FortiClients tries to immediately request /remote/sslvpn-tunnel2 without first requesting /remote/fortisslvpn_xml to get a new IP which causes the reconnect to fail and FortiClient to enter an endless reconnect loop:

[199:root:950]req: /remote/sslvpn-tunnel2?dns0=100.100.16.1
[199:root:950]deconstruct_session_id:716 decode session id ok, user=[test], group=[rmsit-vpn-local],authserver=[],portal=[full-access],host[185.40.184.19],realm=[],csrf_token=[8F71F58A69FE7118475DE6BCBADCF8BC],idx=0,auth=1,sid=5cf064a6,login=1668374995,access=1668374995,saml_logout_url=no,pip=185.40.184.19,grp_info=[z0MdJg],rmt_grp_info=[]
[199:root:950]sslvpn_tunnel2_handler,166, fct_uuid = 0DAE0661B838411A8B8294957F45C7B7
[199:root:950]tunnel2_enter:1171 no more IP address available.

Both the old /remote/sslvpn-tunnel protocol used by FortiClient <= 6.4 and the newer /remote/sslvpn-tunnel2 used by FortiClient 7.0+ seems to support tunnel-connect-without-reauth. The uuid=xxx argument that is passed to the request call is the HW UUID of the client and had nothing todo with the problem.

The debug message showing the call to /remote/sslvpn-tunnel2 by FCT 7.0.x only shows the first argument which was missleading me:

[199:root:950]req: /remote/sslvpn-tunnel2?dns0=100.100.16.1

Using mitmproxy I could confirm also the UUID is sent:

PS: I also have an open ticket with the Fortinet support regarding the FCT 7.0.x issue (Ticket #7728473)

[Jean-Philippe_P]

Hello again!

Great ideas and thanks for the updates! Then the TAC team will help you to solve your specific issue. 

Do not hesitate if you have more questions!

Kindest regards,

[msundman]

Just thought I'd share an update:

Fortinet TAC has confirmed this is a bug in FortiClient 7.0.x for Windows. I've received a 7.0.7-Interim version which fixes the problem that will also be included in 7.0.8 GA when released.

On MacOS, 7.0.x doesn't even support the feature but support is added and working fine in 7.2.0-Interim (GA expected around mid-Dec 22). I haven't had a chance to test 7.2.0 on Windows but hopefully it's working fine there as well.

On Windows, currently 6.4.9 is the latest official version where tunnel-connect-without-reauth works.

[ctanev1]

Hi,

The issue is reported to our developers.

Thanks