This is a REALLY strange one…
TZ 670 that was fairly recently installed (a few weeks back), but issues not not start until about a week ago.
Select users will take laptops home and use Global VPN client to work from home and after anywhere from 5-20 mins the communication w/ the network on the other end of the VPN will cease, the VPN shows they’re still connected (both on SW side and the Global VPN client site) but cannot ping across the VPN or access any resources.
Disconnecting/reconnecting from the VPN will allow it to work for another 5-20 mins or so, but then the same issue will recur.
The real strange issue here is that this is only happening for SOME users and not all. I’ve setup my laptop with the same VPN connection and have no drops, other users have been working just fine w/out issues.
All users are setup the same, we use RADIUS to authenticate w/ AD and have it protected with Duo.
Any insight that could help us track this down and resolve this would be greatly appreciated.
Holy shit I thought I was the only one, exact same issue here:
Global VPN latest version, started about a few weeks ago (these are 2+ yr old firewalls tho), shows as online, RADIUS auth, nothing in the error log on User device or Firewall. Investigation of the incident itself looks like all routing gets dropped by the user device.
So far we only have 3 users with this issue but I can’t for the life of me determine a cause. The 3 staff are from 2 different clients, one of whom is still using SonicOS 6 with a TZ350, the other is on SonicOS 7.1 (not 7.1.2) with a TZ670. Different ISPs.
Quick shot in the dark - The computers you’re having issues with, are they Lenovos with an Intel AX 201 wifi cards? Seems to be the only common factor between them that I can see. Different models between the 3 Lenovo laptops as well.
To recap where I’m at…
6+ devices, three appliances - NSA 2600, NSA 2700, TZ 370.
Gen7 devices were having the issue with 7.1.1-7058 but I upgraded them both to 7.1.2-7019 upon supports request - same problem.
We are seeing the issue with Win10 and Win11 machines, both wired and wireless.
All started on Wed/Thursday 9/26.
I now have 3 cases open with SWALL about it - they excused themselves out of investigating the 2600 - case 44636752. NSA 2700 - 44647117 (opened today), TZ 370 (and where most the notes are) - 44641651.
They’ve had me lower the AES levels on WanGroup VPN and disable IP Sec anti-replay on the WanGroup with no change.
We were using GVC 4.10.5 on some machines and seeing the issue, updated to GVC 4.10.8 with no change.
I am following this thread now as we are running into the same issue. We are a small environment, but more and more people seem to be experiencing this issue. I did the RSC and MTU change with no success. So far the only workaround has been changing their WiFi device to run on 2.4ghz (I don’t want to mess with their routers). I am suspicious that ISP’s are updating\modifying the way their routers handle handoffs between 5GHz and 2.4GHz or if it’s some kind of packet inspection.
Same problem and ongoing case with SWALL that isn’t going anywhere fast.
We are seeing the same behavior to a NSA 2600 and to a TZ370, with the newer but also 4.10.5.
Connectivity via the VPN drops, but nothing in GVC log. Give it 5, 10, sometimes 20 minutes and it’ll come back on its own. One client will drop and others will continue working or vice versa.
That would point to the device then. It’s confounding. I’m going to hop on a call with SonicWall in the morning and press them.
Is there anything different between the user accounts having issues and those not having issues?
There aren’t duplicate user accounts in the Sonicwall are there?
Also, did you update the firmware before this started?
Just wondering why use Global VPN over SSLVPN client?
Check what is primary network connection and reset the network driver.
Ive seen this happen with certain modem types before. Maybe thats the commonality in all of these cases?
We’re experiencing this issue also. There are little to no commonalities which is obv frustrating. A handful of users seeing the behavior. I had a user hop on their Hot Spot which fixed the issue. That tells me that it’s an issue at the router. But I’ve had other users take the laptop to another wifi and have the same thing happen there which is most likely a coincidence. The two routers, bands or isp’s must be similar in some way and causing the break.
For anyone who has been following this thread, just received an update from SonicWALL Support -
Our Engineering team successfully reproduced the issue in our testing environment and are currently engaged in efforts to implement a resolution at the earliest.
u/Square_Seat9930 u/Pocho_EC u/AcademicOnion5095,
Just wanted to give you all an update since we’ve moved to a group chat that most of started discussing this via… (PM me if you want to be just added to the convo)
We currently are in a holding pattern - we have a debug version from SonicWall that none of us have been able to reproduce the issue with. SonicWall says that no changes were made to it other than to increase logability and is waiting on us to provide logs of problem clients - the problem is we can’t when we can’t reproduce the problem with this debug version.
Are the three of you still experiencing the issue with your users?
Try disabling RSC. Haven’t had this, but I’ve had issues with RSC and GlobalVPN so now I always disable it for clients using GlobalVPN.
Get-NetAdapter
Get-NetAdapterRsc
Disable-NetAdapterRsc -Name Wi-Fi
Okay I’ve got a problem computer on my hands finally. Findings from today:
-
User who’s broken computer I grabbed is still unable to connect from home (or coffee shops, hotspot, etc) on their temp computer.
-
VPN drops within 20 minutes after connection when on wifi, also drop VPN connection to any of their satellite offices.
-
Using a different AD user account on the problem computer ran for 1 hour without VPN dropping.
-
Returned to original account. Computer ran for 1 hour on Ethernet without VPN dropping.
-
Set Wi-fi adaptor MTU to 1400, computer has run on VPN without dropping for 1 hour. Returning to 1500 MTU (and a reboot) and now I can’t reproduce the error anymore… Wtf, there was more I wanted to check…
I applied the MTU change to the user’s temp PC, and got them a second user account to try. They’re going to see if the MTU change fixes it for them and try the new temp account if that doesn’t. They’re in office today but will test tonight, will pass on what I hear.
Considering the other findings above though… What the fuck is going on lol. How on earth is the problem following her account around - we’re not using roaming profiles or anything!
MTU change:
netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface "YOUR_WIRELESS_CONNECTION_NAME" mtu=1400 store=persistent
EDIT: PS, can you please run a netstat -r while connected to the VPN both before and after a drop and compare the IPv4 tables? I wanted to test my theory that it was dropping the VPN routing table but I can’t reproduce anymore on this machine.
Issues still persist - has anyone attempted to disable split tunneling to see if that helps anything at all?
This seems quite similar https://community.intel.com/t5/Wireless/AX201-Dell-Cisco-Meraki-VPN-not-passing-traffic-due-to/m-p/1421204/highlight/true?profile.language=pt
Recommendation to upgrade drivers to 23.80.1 downloaded from https://www.intel.com/content/www/us/en/download/19351/intel-wireless-wi-fi-drivers-for-windows-10-and-windows-11.html
Maybe worth the trial for everyone having this issue and see if that makes a difference, that thread in intel also has the link for their diagnostics tool, which probably would be useful to pull more information as to what may be happening
are there any updates on this? we have a user who has been using this VPN and is getting the connection dropped every so often, usually a few times a day. we put her on the newest version but that doesnt seem to help
I ended disabling ipv6 wifi interface and sonicwall interface on the client machines. Seems to work right now.
We’re on SonicOS 7.1.x here – latest release. Brand new firewall installed a few weeks ago and issues started popping up as of Thrusday last week according to them.
They are NOT Lenovo’s though.
Dell Latitude 3520 w/ Intel AX211
Dell Latitude 3520 w/ Intel AX 201
Surface Laptop 3 w/ Intel AX201
The 211 could also be similar enough.
Going to check some other users who are NOT having issues and their wifi cards.
Fourth appliance - another NSA 2700… creating another case…