To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".
The screenshot attached states that the Geo Enforcement or Geo-IP for visualization is not enabled. Please click on the link and enable it.
Also, If the issue persists can you please confirm if the appliance is able to resolve "utmgbdata.global.sonicwall.com".
To test the connectivity, Please navigate to Investigate|system Diagnostics| Diagnostics Tools and then select DNS Name lookup from the list and then test it.
Please let us know if you have any queries.
Please refer to this KB article below.
So, when you connect a NetExtender client directly to the firewall, even then the RDP and Citrix are failing? Also is the Citrix present on X6 subnet? Can you please let me know the network ID where the Citrix server resides?
This looks like a SSLVPN configuration issue on the firewall side. Could you please look at this KB below to check for the settings on the firewall.
As of now we can either group together the WAN interfaces or the VPN tunnel interfaces (both numbered and unnumbered together).
So, to achieve this you could create a VPN across the MPLS to achieve the SD WAN using the VPN tunnel interfaces SD WAN group.
We have RFE filed (RFE# 2571) to achieve the capability of having the VPN interfaces and WAN interfaces in the same SD WAN group.
I hope that helps!
The specific item you are referencing is being caught by Vade.
You can disable the Vade AV plugin on the diag page under server settings.
The best way to resolve this is to open a support case and have a sample that is caught and the original attachment as well and support can submit it to the effectiveness team to resolve.
This is netbios traffic. default behavior is to drop this traffic. If it is not causing issues you can do nothing or you can following this kb which shows you how to enabled it.
The local accounts will work in combination with others being LDAP, you probably dont have the local users in the correct SSLVPNservices group. The domain for the login is just a visual thing, doesnt actually matter or relate to your AD, so its the same for local users as the AD user. Use the web based portal to check your logins are working.
For leveraging the Azure AD directly, I havent see this noted as supported by sonicwall and I would not be sending LDAP traffic out the internet (even if you have TLS enabled) unless its in an ipsec vpn tunnel.
I'd go with local accounts for now and make sure you set OTP requirement on those accounts on the sonicwall.
Welcome to SonicWall community.
Usually that destination IP is used for NetBIOS traffic. You can probably set up a packet capture and check if there are drops for TCP/UDP 137 and 138.
Worth taking a look at the Core 0 process monitor, it'll show you if a specific task is responsible.