[Sonicwall Vpn Client Download Mac
Oludare Padilla
Although the management site and everything I've clicked on does come up now, there seems to be a major communications issue between the clients and the management servers. I have numerous systems which are currently online (including my desktop and laptop), yet the Capture Client icon shows Offline. If I open the client app on those systems, Device Status shows as Connecting...
Worse, I'm still trying to complete our rollout of SWCC, and I can't get it installed due to the new installation not registering with the server and completing installation of the Sentinel One client.
Hello @mangonacre, I'm sorry to hear about this inconvenience. Can you PM your case number to me so that I can escalate? BTW I have removed the duplicate post that you are referring to. No problem at all.
I never did get a case number. The call connection broke when I was trying to get the case started. I called again and waited on hold for another long while. During that time, the client I was trying to get installed finally registered with the server and I was able to complete the installation. So I hung up.
At this time, the site seems to be responding for the most part, and some of the client systems that were showing CC was offline are now showing online. But there remain several of them that are currently up and running (for instance, my laptop) and still showing last contact from the client was hours ago. This is not the first time I've seen this, either. I'm not going to try any other installations until I see proper communication from all clients, so I hope it clears up soon.
I've pretty much lost all confidence in this product, and regret the purchase. It may be an "inconvenience" today, but the fact that this seems to repeatedly happen with their systems raises serious questions as to how we would be able to manage or remediate an active threat, especially one that affected a server.
My experience was similar to ASchultz's above, where the next morning, all affected clients were finally communicating properly with the servers and downloading SentinelOne updates. I haven't had a problem since Dec 16. What you're experiencing now might be due to a regional issue that's not hitting me (yet).
That said, I did open a case for it on Dec 15 which has not been addressed at all by SonicWall support. Combine that with the fact that when you go to the Support section in MySonicWall, you can only create an email-based case, and it is automatically assigned a severity of 3 with no way for you to change that. You can still find the support number through Google, but back on Dec 15, I spent a half hour on hold before someone picked up, and then was suddenly disconnected before the case could be created. I tried calling back, but was again stuck on hold for over 30 mints. And of course, nothing posted here by any SonicWall representative even acknowledging a problem occurred.
Not sure why the client upgraded for you even though you have the policy set to a lower version. I've not had that issue. But I do want to make sure you're aware that 3.6.30 consumes a good bit of CPU cycles when the Content Filter is active: "High CPU due to system process swcfdrv64.sys+0x998c after update to CC 3.6.30." I rolled back to the "General Release" of 3.6.24 until they get that bug worked out. Supposedly it was resolved in 3.6.31, but it's back to listed under Known Issues for 3.6.33. (And there isn't even a Release Notes updates for 3.6.34... )
All the site to site connections work. the one hold out GVC install (Me) works just fine. Prior to the changeover the SSL clients worked just fine however "tunnel all" mode isn't wanted because it prevents zoom, teams and Outlook o365 connections from working on the remote host. We also don't want them streaming music through our WAN. Users are currently working off the old firewall till I get this solved.
This is not a usual behavior, may I request you to please check the client routes again and make sure that the dummy network is added to it. and also under VPN access for the SSL VPN service group, We have a KB addressing a similar error: -base/error-connection-failure-no-routes-found-in-netextender-for-sslvpn-connection/170503292558209/.
So, we have an annoying problem that when NetConnector VPN connections are made, client web browsing becomes sluggish. It doesn't die, it just introduces a pause of about 5 seconds before any url can be reached.
Google-fu reveals something called split-tunneling which, as far as I can tell, allows you to specify what type of traffic goes through the VPN client. However this is enabled and tracert suggests web traffic is indeed travelling through my local IP and not the assigned 10.1.1.x address the VPN gives me.
Also the user that you are testing with, should only have internal networks in VPN access section. You should also check that it is not inheriting some bad access due to user groups that it is part of. It shows inherited if it is getting something from another group.
You would need to check if there are any unnecessary SSLVPN client routes or VPN access added to the client you are testing with? Also is this SSLVPN connection made to a firewall or a SMA appliance? And what firmware are you running on the appliance you are connecting to?
(ive also tried connecting this users sonic gvc to another system client sonicwall i have (a different company/different ip address), and after the initial asking me for username/password, also got stuck on connecting.
Can also do a full uninstall of the client, reboot, and install the latest. Make sure you get the Windows firewall prompts checked off for network access, and run through the setup, checking the destination IP is correct and your shared secret is put in during first connection attempt.
Make sure there is no IP address overlap between home and VPN ranges. I have seen this behavior and it was due to overlap. The user had to ask their ISP to change their LAN range and everything worked after that.
I had two workstations in the field that did this. Complete reinstall of client, settings, etc. with no success. I ended up installing the SSL client for these two. The one thing I might have tried, which would either require on-site visit or have them return WFH kit, was to possibly reset the network stack on the PC. Since the Sonicwall comes with a few free SSL licenses, this was the easier route for us.
We have a TZ400 and I try t set up SSL VPN for smartphone users to access our Exchange server. Installed Sonicwall Mobile Connect on an Android phone. Configured SSL VPN on the TZ400. Now when I try to access the Exchange server, I can do so by entering the Exchange server's IP-address. But NOT when I use the Exchange server FQDN. If I use a browser to connect with the FQDN, it shows "dns_probe_finished_bad_config". So it's a DNS problem. Question is: how to resolve this?
As said, when I use the smartphone to browse to it shows the login page for OWA. But when I use it shows the dns_probe_finished_bad_config. When I use that URL on my Windows pc, I get to the OWA login page. So it seems the local DNS works fine.
Are you tunneling all traffic with SSLVPN? Does your SSLVPN client config allow access to the entire subnet, or at least to the DNS servers as well? Does the user account you are logging in as have access to the same subnet / servers?
@TKWITS : thanks! You had it nailed with the DNS servers. I had the VPN connection locked down to only allow HTTPS and only connect to the Exchange server. Added another rule to allow access to a local DNS server and now things work as they should.
I am having an issue where WiFi client on the main SSID can't not communicate with each other if they are wireless. The CAN communicate with LAN resources. Just not Wifi client to Wifi client. I know some router calls this AP Isolation. But I can't find anything like that on the Sonicwall TZ-200.
On SonicWALLS, in version 5.x (and 6 too, I imagine) this is known as "Interface Trust". To adjust this setting, go to Network -> Zones and check the box to "Allow Interface Trust" to resolve this issue.
I will caution you however that if you are using the WLAN zone which has interface trust disabled by default, and you are using a SonicPoint with version 5.x you are doing it wrong. The wireless configuration of SonicPoints is extremely arduous and I cannot disrecommend this product enough. If you can return these, do. They are a major headache. I love their firewall, but hate their SonicPoints.
To properly configure them, the SonicPoints should be the only thing in the WLAN zone which should be on an untagged VLAN. You should then create another zone (with interface trust enabled). You then need to go to Network -> Interfaces and click "Add Interface" and create an interface with a VLAN tag other than 1 with a parent interface of whatever the SonicPoint is plugged into and you need to select your newly created zone.
Next, navigate to SonicPoint -> Virtual Access Point and create a Virtual Access Point Group (VAP group) and then create a Virtual Access point. The Virtual Access Point (VAP) needs to be set to the same VLAN tag you used earlier. Then you need to edit the VAP Group and add the VAP to it. Finally, you are ready to go to SonicPoint -> SonicPoints and edit the SonicPoint in the middle section. You then can assign the VAP group to the WAP.
You will also need to ensure that the WAP is either plugged directly into the SonicWALL or that you have a switch that supports VLAN tagging. If you go the switch route, you need to have the untagged VLAN assigned to the port you connect the WAP(s) to and tag or trunk each of the VLANs on the port on the switch using the same VLAN tag/number you used on the SonicWALL - otherwise you will run into issues. If you need to connect more than one WAP directly to the SonicWALL, you can use PortShield groups to have 2 ports on the same WLAN zone.
If you do not do this, you will find weird issues like being unable to talk to the other computers on the network, but getting internet access or getting spotty internet access which will work great for awhile and then drop out all of the sudden inexplicably.
795a8134c1