Technical Tip: Cannot Access Internal Network Resources Using FortiClient after a Network Disruption
| Description | This article describes an issue where VPN users are unable to access internal resources after a network disruption, even when tunnel reconnection without requiring reauthentication is enabled. |
| Scope | FortiGate v7.2.7. |
| Solution | After a network disruption, VPN users are unable to access internal resources even though the 'tunnel-connect-without-reauth' option is enabled in the SSL VPN settings. config vpn ssl setting set tunnel-connect-without-reauth enable end The following logs may be seen in the SSL VPN debugs indicating that the failed IP association after the network connectivity is restored. [366:VPN:10ba81]Destroy sconn 0x7f4a1111e000, connSize=109. (VPN) -----> Old SSL connection got destroyed.. [362:VPN:10bace]allocSSLConn:310 sconn 0x7f4a11109000 (1:VPN) ---> New SSL connection formed. [362:VPN:10bace]send ip pool client is xxxxxx@xxxxxx.com-X.X.X.X-56767 linkaddr is 10.121.32.1 [362:VPN:10bace]fsv_ip_pool_client_offer:344 dhcp request ip get offer 10.121.37.71 for xxxxxx@xxxxxx.com-X.X.X.X-56767 [362:VPN:10bace]tun dev (ssl.VPN) opened (271) [362:VPN:10bace]fsv_lease_add_timer:1176 sconn: 0x7f4a11109000 lease time 1828945551 43200. [362:VPN:10bace]fsv_associate_fd_to_ipaddr:2282 mux_associate_ip_to_fd(10.121.37.71) failed: File exists --> [362:VPN:10bace]sconn: 0x7f4a11109000 Kick tunnel Wait time. [362:VPN:10bace]fsv_associate_fd_to_ipaddr:2324 associate 10.121.37.71 to tun (ssl.VPN:271) [362:VPN:10bace]proxy arp: scanning 16 interfaces for IP 10.121.37.71 [362:VPN:10bace]no ethernet address for proxy ARP [362:VPN:10bace]sslvpn_user_match:1170 add user xxxxxx@xxxxxx.com in group SSL-SAML [362:VPN:10bace]Will add auth policy for policy 1 [362:VPN:10bace]Add auth logon for user xxxxxx@xxxxxx.com:SSL-SAML, matched group number 1 diag firewall auth list 10.121.37.71, xxxxxx@xxxxxx.com type: fw, id: 0, duration: 245, idled: 245 expire: 42413, allow-idle: 42658 flag(80): sslvpn server: azure packets: in 0 out 0, bytes: in 0 out 0 --------> No packets. group_id: 4 group_name: SSL-SAML No firewall sessions in the session list output and 'reverse path check fail, drop' can be observed in the debug flow outputs. id=65308 trace_id=401 func=print_pkt_detail line=5795 msg="vd-VPN:0 received a packet(proto=1, 10.121.37.71:1->10.10.10.10:2048) tun_id=0.0.0.0 from ssl.VPN. type=8, code=0, id=1, seq=2925." id=65308 trace_id=401 func=init_ip_session_common line=5980 msg="allocate a new session-1cb003d5, tun_id=0.0.0.0" id=65308 trace_id=401 func=iprope_dnat_check line=5297 msg="in-[ssl.VPN], out-[]" id=65308 trace_id=401 func=iprope_dnat_tree_check line=834 msg="len=0" id=65308 trace_id=401 func=iprope_dnat_check line=5309 msg="result: skb_flags-02000000, vid-0, ret-no-match, act-accept, flag-00000000" id=65308 trace_id=401 func=ip_route_input_slow line=2267 msg="reverse path check fail, drop" id=65308 trace_id=401 func=ip_session_handle_no_dst line=6066 msg="trace" diag sys session filter src 10.121.37.71 diag sys session list total session 0 This issue has been resolved in FortiOS version 7.6.1. Workaround: Manually disconnect the VPN connection and reconnect it. |