Arkwright Community Legend ✭✭✭✭✭
Reactions
Comments
-
"DPI" should be anything that isn't the basic properties of the packet, ie source/dest IP source/dest port. So would include Content Filtering Service, Gateway AV, Intrusion Prevention, Anti-Spyware, etc. Try disabling the security services one by one [or even just all at once, speed up your iteration] and re-test. Is…
-
You haven't said what kind of throughput you're expecting. You can improve throughput by disabling security features. On some models there are interfaces with dedicated connection to CPU rather than going through switch chip. Using those interfaces would [presumably] give the best performance, but I haven't tested this…
-
You can tick "Disable DPI" on an access rule. That should allow you to do a comparative test.
-
My whole question is why Sonicwall must do a lot of filtering and I believe that it may be interfering at some point. This is pretty much 80% of the point of a UTM platform like SonicOS - scanning, filtering and blocking stuff. If you don't need that then you probably don't need a Sonicwall. Having said that, you might…
-
I think you're complaining about network throughput over SSLVPN here - you certainly wouldn't be the first person to question this. If you want to test network throughput, use a specific tool like iperf for this. As tkwits says, large number of small files is pretty much the worst-case performance scenario for copy…
-
I would start by disabling security services to see if the extra load of processing this traffic with the services on is pushing it over the edge. However, in my experience, a firewall nearing its CPU limit doesn't cause everything to fall over, it merely degrades the performance. So I think there might be something else…
-
You aren't going to get the VPN status, you would have to infer that from whether it's present or not :/ I think you can get the firewall to send an SNMP trap on tunnel up/down events. From the CLI you could try parsing the output of 'show vpn tunnels'. The format is not particularly machine-friendly. I tried 'cli format…
-
No drops for a week, hotfix fixed it.
-
If you use a numbered VPN tunnel interface then you can get traffic stats on the interface BUT in some firmware versions it only shows stats for one direction [can't remember if it's TX or RX]. This is more usable than the "normal" VPN tunnels, as the ifIndex is fixed. For other types of VPN the stats do increment but…
-
Yes, security services were on the SSLVPN zone, turned this off. Didn't help. Raised a ticket with support. Suggestion was to connect serial consoles and wait for issue to recur and then we'd get some output. We did this and there wasn't any. Updated firmware to 6.5.4.11, no different. Much uploading of TSRs, tracelogs,…
-
No advice about your specific scenario beyond "it should work", but I would note that is pretty old firmware [March 2019], so whatever this issue is may be fixed by now. EDIT: Looks like 6.5.4.1 was the initial firmware version for TZ350, so sounds like yours has never been updated.
-
Not really much more detail to give, tbh. Monitor value of SNWL-COMMON-MIB::snwlSysSerialNumber.0 If it ever changes, then there was an HA transition. Obviously, would be great if there was an OID you could poll that explicitly says if it's active or standby, but there isn't.
-
Because it's not implemented, unfortunately. An OID for trapping won't necessarily work for polling. We monitor HA state transitions by polling the OID for the serial number of the virtual IP and then raise an alert if it changes since last poll. It's not perfect but it lets us know when something has happened. You can…
-
Interesting using of the words "design" and "friend" there tkwits :D This is a complete and utter hack. What other kinds of UDP traffic are going to be targetted next? Softphones, perhaps? "RTP blocked by design, just forward calls to your mobile instead".