SSLVPN Connection Issues

VPN
1

Hello -

​

We have recently run into an issue that we are having problems troubleshooting. We are looking to see if anyone else is running into the same problem.

I work for an MSP, and recently we have multiple clients that are having issues with their SSLVPN’s staying connected. Whether they are using Mobile Connect or NetExtender, the users are all just being dropped. The user will then have to attempt to reconnect, which sometimes takes hours to let them reconnect. We reached out to SonicWALL support, and they recommended that we update the firmware on the TZ500 and TZ300 that are having the issues. This was completed and they are updated to:

Firmware Version: SonicOS Enhanced 6.5.4.14-109n

The issue went away for a few days and has come back this morning. These are 2 different clients, in 2 different cities, on 2 different models of SonicWall. The only common attribute is that both sites are connected to the Spectrum network.

The only debug error from the NetExtender logs is below:

04/18/2024 00:08:50, Error, 0x06000308, Engine, 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.

-Your user account was logged out of the SSL VPN portal.,

We have disabled the idle timeout, and we have continual pings running the entire time the SSLVPN is connected, so this is not an idle timeout issue.

There are minimal logs in the SonicWall, and nothing that explains the reason for the break in the connection.

We are looking to see if anyone else is having this problem, and if they are on the Spectrum backbone.

Thanks.

2

You might want to check this. https://www.sonicwall.com/support/knowledge-base/ssl-vpn-ip-pool-exhaustion-issue-on-sonicwall-gen6-firewalls/230619103039980/

3

There’s been ongoing SSLVPN attacks throughout the USA. Search this sub reddit for sslvpn and you’ll find a ton of information on what to do to see if you are a victim.

4

Disabling Virtual Office on non-lan interfaces resolved the issue for us.

5

Also call sonicwall and ask them to provide hot fix

6

Sounds like exactly what we had a few weeks ago, and I suspect it may be related to this: Large-scale brute-force activity targeting VPNs, SSH services with commonly used login credentials. If you go to the firewalls connection monitor and filter DST IP to your WAN interface address, and port number to the port your VPN service is listening on (guessing 443), do you see a lot of connections from IP addresses that don’t match SSL client sessions and / or appear to be from random hosting services. We fixed the issue by upgrading to the latest firmware and using the option to disable virtual portal on WAN.

7

Would the users happen to be connected to their Internet connection via WiFi? If so, see if they can hardwire their connection, then see if it gets better or stays the same.

I always recommend to people that they hardwire their Internet connection when needing to connect to their SSLVPN connection. Even when connecting myself (for work), I do not like to be connected via WiFi if I need to connect to my VPN.

Of course this typically isn’t possible when using SonicWALL Mobile Connect, but for NetExtender this should be possible.

I’d also recommend running a pcap on the SonicWALL side, create a [temporary] SSLVPN User Account for yourself (if you haven’t done so already), then run a pcap on your connection to see if you can identify anything from the SonicWALL side of things. Also, assuming you have a SYSLOG server set up, maybe something in there might help you out.

Good luck bud!

8

Not just the USA, the world !!!

It doesn’t drop existing connections, it uses up licences so users struggle to connect in the first place

9

Don’t call. Open a web ticket. It will be faster than waiting in the queue sometimes. If the symptoms match they will just give you the HF with no troubleshooting no questions asked.

10

With the Virtual Portal disabled, how are you enrolling users in 2FA? Using an emailed TOTP or turning the portal back on when someone is on-boarded in order to enroll an Auth Application?

11

It’s only disabled on WAN zone, and we generally enrol staff when they start from within the network.