The SSLVPN and Global VPN have a handshake between the two. The keep-alive you are referring to is not something the SSLVPN has. Does anyone know how I can either A) Change the timeout so its a little more, or b) Set it so these keep-alive packets get highest priority so they dont get dropped when the client attempts to reply?Ħ.5.X covers a huge range. However, for SSL-VPN / NetExtender in the SonicWall, i do NOT see any specific keep alive packet settings, other than User-Session keep alive (Based on mouse/keyboard/etc movement for Windows clients). I can see for regular VPN connection, there's settings for Keep Alive. These packets aren't getting dropped due to my connection clearly not being saturated.

On clients with faster upload speeds (I am luck enough to give 1gig symmetrical fiber at home), this is not an issue, as SMB traffic and uploads cap out at around 30-40mbit for me for SMB, and 100mbit or so for HTTPS (We have 500mbit symmetrical lines for the SonicWall). When the SonicWall fails to get replies, it drops the client. Because the users connection is saturated, and these are probably given no priority and being dropped by the client itself, or the clients modem/router/ISP as it's trying to cram data into a saturated pipe. What I assume is happening, is the SonicWall keeps some sort of Keep Alive packet to the client every so often, if not Ping something close to it.

After doing this for anywhere from 30-60 seconds, their VPN session gets dropped. If I monitor a ping to their PC over the VPN while they transfer, or a Ping to their External IP, as soon as they transfer, it will start dropping Ping, or I get responses in the 100's of ms. (Varies by user, some with 1-2mbit upload, some with 10mbit or so). What I notice, is the upload will saturate the users home connection utilizing all available bandwidth. When transferring large files, mostly over SMB although its done it on HTTPS uploads too, users after a little bit will get disconnected with the message 'NetExtender has been disconnected for one of the following reasons: There was a break in the network connection - The connection was idle for longer than the configured idle timeout.'.

It also happens on the Linux client that I tested. Client versions does not matter (8.x through the latest 10.2.315), and OS version does not matter (Thoughrally tested with Windows 7, W10 1507-21H1, and W11). I've had a problem with the NetExtender client for remote users for quite some time, including myself.

I have several SonicWalls (TZ500, 2 x 4600, and a 4650).

Sonicwall netextender s