|
Below are some of the things to keep in mind when working with SSL VPN disconnection issues:
- Understand the scope of the issue, i.e. whether all users or some users are having the SSL VPN disconnection issue.
- See if any applications on the user's computer could conflict with FortiClient (For example Cisco's Anyconnect).
Use a test computer in the client's network with no other 3rd party applications if possible.
- Check the configuration on FortiGate for any traffic shapers applied on the WAN interface, DoS policies, and local-in policies created. Adjust it as per the requirement or disable it while testing.
- For higher-end units, there could be IPv4 access control lists, which could be checked and disabled for testing.
- Test with DTLS or TLS connections. Below is an article on how to enable DTLS for SSL VPN connections.
Try disabling it, if it is already enabled.
Technical Tip: Using DTLS to improve SSL VPN performance
- Look into the crashlogs on the FortiGate. i.e. 'diag debug crashlog read'.
- Perform basic configuration checks on the FortiGate of SSL VPN.
- See if the end-user is connected using a Wired or Wireless connection on their network. Use a wired connection if possible in the user's network.
- The issue might occur if there are multiple interfaces connected to the Internet, for example, SD-WAN.
This can cause the session to become 'dirty'.
To allow multiple interfaces to connect, use the following CLI commands.
If v6.0.1 or later is used:
config system interface
edit <name>
set preserve-session-route enable
next
end
Refer to the following document for more information:
Technical Tip: Enabling the preserve-session-route
- If an SSL VPN tunnel connection is terminated with the log message 'Deleted to make way for another session', then apply the below commands:
config vpn ssl web portal
edit <portal_name>
set limit-user-logins disable
next
end
Refer to the following document for more information:
Technical Tip: SSL VPN is disconnected with 'Deleted to make way for another session' log
- Authentication Timeout and idle timeout settings could also be checked on the FortiGate: By default, an SSL VPN connection logouts after 8 hours due to auth-timeout.
config vpn ssl setting
set idle-timeout 300
set auth-timeout 28800
end
The idle-timeout is the time in seconds that the SSL VPN will wait before timing out.
The default value is 300 seconds (5 minutes). Range: <0> to <259200>.
The auth-timeout is the time in seconds that the SSL VPN will wait before re-authentication is enforced.
The default value is 28800 seconds (8 hours). Range: <0> to <259200>.
A value of 0 indicates no timeout.
Refer to the below document for more information:
Technical Tip: SSL VPN connection logout after 8 hours
- If the issue is limited to a particular user or a few users, then ask the user or users to use another network (for example mobile hotspot) and see if the issue is reproduced.
- Some logs/errors in the SSL VPN logs could be seen with the Reason 'DH lib' and Action 'ssl-exit-error' after the user's connection disconnects and tries to connect again to the SSL VPN.
Sleep Settings on PC/Device:
An important area to review is the sleep settings on the machine. When machines go into sleep mode this may cause some connections to disconnect and the following errors may be visible within the FortiClient's logs.
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] AppDelegate.swift:366 System is going to sleep
20240806 21:14:07 TZ=+0530 [FortiTray:INFO] VpnManager.swift:1791 Check VPN Connect without Reauth
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] VpnManager.swift:1821 VPN Connection without reauthentication disabled.
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] VpnManager.swift:1565 Stop current VPN
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] VpnManager.swift:1567 Current VPN vpn.example.com
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] sslvpn_bridge.mm:599 VPN session stop
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] vpnconnection.mm:1013 VPN Process is not running.
20240806 21:14:07 TZ=+0530 [FortiTray:DEBG] VpnManager.swift:988 On VPN status change: TunnelRunning -> Disconnecting
20240806 21:14:07 TZ=+0530 [FortiTray:INFO] VpnManager.swift:1148 VPN disconnecting
If this is occurring, consider adjusting the sleep settings.
The tunnel disconnection could be caused due to ISP issues, client-side issues or packets not reaching FortiGate's SSL VPN process.
The error does not necessarily indicate a problem with FortiGate if only 1 user or certain users are having issues.
So, a good action plan is useful in determining whether the issue lies on FortiGate or not.
Below are the steps that could be performed, before opening up a ticket with technical support as that would speed up the troubleshooting process and help in finding out the root cause of the issue:
Note.
All debug/sniffers/traffic tests need to be run concurrently and need to have timestamps.
Enable logging of the putty session by following the below document:
Technical Tip: How to create a log file of a session using PuTTY
- Enable Debugs on the FortiClient > Settings
- Clear logs.
- Logging -> Enable logging for these features: VPN.
- Log Level: Debug.
- Go to the folder %appdata%\forticlient\logs\trace, and get the file like 'sslvpndaemon_x.log' (Collect the file before and after the disconnection).
- Debugs on FortiGate in an SSH session:
diag deb reset
diag deb console time en
diag deb app sslvpn -1
diag vpn ssl debug-filter src-addr4 x.x.x.x <----- Public IP of <user>.
diag deb duration 0
diag deb en
diag sniffer packet any 'host 1.2.3.4 and icmp' 4 0 l <- Leave it as it is. It just keeps the session open.
After collecting logs, disable debug:
di deb reset
di deb disable
- Sniffer1 on FortiGate in an SSH session:
diag sniffer packet <WAN interface name> 'host <Public IP of the user>' 4 0 l
- Sniffer2 on FortiGate in an SSH session:
diag sniffer packet <WAN interface name> 'host <Public IP of the user>' 6 0 l
- From FortiClient machine ping test to FortiGate external interface (timestamp).
ping -t x.x.x.x|cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!date! !time! !data!)&ping -n 2 x.x.x.x>nul"
- From FortiClient machine ping test to external IP like the Fortigate's Default Gateway (timestamp).
ping -t z.z.z.z|cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!date! !time! !data!)&ping -n z.z.z.z>nul"
- From FortiClient machine ping test to internal unit through the tunnel like a server (timestamp).
ping -t a.a.a.a|cmd /q /v /c "(pause&pause)>nul & for /l %a in () do (set /p "data=" && echo(!date! !time! !data!)&ping -n 2 a.a.a.a>nul"
- Start a Wireshark packet capture on the user with the filter of FortiGate's public IP address on the wireless or ethernet interface.
- Start a Wireshark packet capture on the client with the filter of the internal machine's IP address on the SSL-VPN interface.
- Sniff the ICMP packets on FortiGate for the internal machine's IP address that was started in step 8.
diag sniffer packet any 'host <internal machine ip> and icmp' 4 0 l
- Go to C:\ProgramFiles\Fortinet\FortiClient\logs\trace and collect the file like 'sslvpndaemon_x.log'
- Once the connection drop occurs, then collect & attach the debug/sniffers, SSL VPN logs & System Event Logs from FortiGate, and ask the user to note downtime if the issue occurs.
The above steps will help to identify the issues related to SSL VPN tunnel disconnections.
|
