Best Of
Re: SonicWall TZ 570
@KevinLynch there is no rule of thumb for that, it all depends how active your deployment is.
You might select the longest time frame to show the logs and scroll down, this should give you an estimate how long the log lasts for your appliance.
—Michael@BWC
Re: SonicWall TZ 570
@KevinLynch I don't do much log automation via email, but my guess is that the log ring buffer gets filled up every few minutes and this causes the TZ to send out a new mail.
—Michael@BWC
Re: Chromium-based browsers (Edge, Chrome, etc) on Canary channel (v125) bypass content filtering/DPI
KB released:
Chromium-based browsers (Edge, Chrome, etc) on Canary channel (v125) bypass content filtering/DPI
I've discovered Chromium browsers based on v125 and newer are able to bypass SonicWall's content filtering. I've tested this with SonicOS version 6.5 and 7.1.1.
This is an issue with Google Chrome Canary and Microsoft Edge Canary (v125), but not Dev (v124) so I believe this is a new problem specific to all Chromium browsers based on v125+.
On the firewall running 7.1.1, I also blocked QUIC using Application Control, which made no difference. To further verify this is not related to QUIC, I disabled QUIC in the browser settings, and blocked UDP on port 443.
In the case of the 6.5 firewall, DPI is disabled, but it is enabled with a certificate installed on my test machine on the 7.1.1 firewall.
HTTPS filtering is enabled on the filtering policy, and I'm not logged in as admin so that's not related either.
Filtering works correctly with Google Chrome Stabe and Beta, and Edge Stable and Beta, and the website certificates show that they are signed by SonicWall, which confirms the traffic is being decrypted. However, in Dev/Canary (v125), the certificates are the original website certs.
For my testing, I blocked the "Shopping" category, and tried browsing to Target.com. I've linked the cert info below.
Does anyone have any ideas? I've never seen this before, but it seems to be a recent development since I can only replicate it on v125.
Re: GAV - use exclusion list but still scan data
I believe you have to submit feature requests through your local rep, but maybe @fmadia can elaborate.
Re: TZ450 1000's of failed logon attempts
Turns out there are multiple threads in this forum and on Reddit about this. There is a message on the support number about this. There is a hotfix that Sonicwall built for this. But there's no sticky thread from Sonicwall in here and we haven't had an email about it? Come on!!!
Re: Advice for NSa3700 drops/ignores OSFP IPv4 routing
OSPF to Dell S5224-ON switches.
OSPF to Cisco ISR Routers.
- I stabilized the OSPF IPv4 relationship between NSa3700 and Cisco ISR4431 and ISR4331 routers by dropping "ip ospf mtu-ignore" in the SonicWall and in the Cisco ISR router.
OSPF to Dell S5224F-ON Routers.
- I stabilized the OSPF IPv4 relationship between NSa3700 and a pair of Dell S5224F-ON switches (L3 switch) by
- * dropping "ip ospf mtu-ignore" in the SonicWall
- * keeping "ip ospf mtu-ignore" in the Dell S5224F-ON switches.
- When I dropped "ip ospf mtu-ignore" in the 3700 and the switches, the switches were stuck in an EXSTART/DR and EXSTART/BDR state. Adding "ip ospf mtu-ignore" to the Dell switches (not the NSa3700) resulted in an immediate change to FULL/DR and FULL/BDR.
Re: Convince me I'm not making a mistake going to Capture Client and the new MDR service
In the six weeks since I originally posted, I learned my MSSP will be offering Heimdal's MXDR solution for one dollar more than SentinelOne. This product contains a dozen additional features that match over vendor offerings. The primary distinction is the ability to use one pane of glass (sound familiar?) to manage DNS filtering, Application Control, UAC management, and lots more. I will not consider using Capture Client.
Re: NetExtender SSL VPN Very High Latency
Sorry for the delay, I forgot to post back. I found the issue, it was my anti-virus. As soon as I started pushing traffic over the tunnel, the ESET service cause immense latency but the CPU usage was not affected, only the VPN traffic. Not sure what caused it but it was something in the system updates. I wish ESET would put more effort into Linux, they have a good product for Windows but their Linux features/support is not great.
systemctl stop esets.service and the latency went back down to < 35 ms from 2-3K ms !!!
Removed ESET and now just running CLAMAV