Hey everyone! Been tinkering with our SonicWall TZ series in a new test lab setup and finally got around to measuring something I've been curious about: the actual processing delay added by firewall rules.
We all know every rule adds a tiny bit of overhead, but I wanted to see the concrete difference between traffic hitting a simple "allow any" rule at the top versus traffic that has to be processed through a longer list of specific application and user-based rules further down.
Here's the gist of my lab setup:
* Two isolated VLANs with a SonicWall TZ 370 as the gateway.
* Used iPerf to generate consistent UDP and TCP traffic streams.
* Measured latency and throughput with a baseline "allow any" policy.
* Then added a stack of 15 granular rules (mixing app control, user objects, and scheduled elements) before that same traffic match, and measured again.
The initial numbers are pretty interesting! For our specific traffic profile, the average latency increase was about 0.8ms, and I saw a small but noticeable dip in throughput when the packet had to be evaluated against the longer rule set.
I'm planning to run more tests with Deep Packet Inspection and Gateway AV enabled next. Has anyone else done similar benchmarking in their environment? I'd love to compare notes, especially on:
* Your methodology for testing rule processing impact.
* Whether you've found a "tipping point" in the number of rules where performance starts to degrade more noticeably.
* Any best practices you use for organizing rule order to minimize delay for critical traffic.
Sharing real numbers helps us all design more efficient policies!
Keep it simple.
Nice little test! That 0.8ms delay is actually a great real world number. Reminds me of cloud security groups - each rule is a check, and a bloated NACL or security group list can have a similar cumulative effect on instance latency.
Your planned next step with DPI/AV is where you'll likely see a bigger jump. The move from simple rule matching to full content inspection is a much heavier lift for the hardware.
Ever think about testing the impact of rule *order* within that stack? Like, putting the most common traffic matches higher in the list, even within your granular 15? Inefficient ordering can sometimes add more overhead than the raw number of rules themselves.
security by default
Your methodology is sound. That 0.8ms delta is a valuable data point for justifying rule-set cleanup meetings. While the throughput dip is small, it becomes significant when multiplied across thousands of concurrent sessions, which is often overlooked in smaller-scale testing.
I'm particularly interested in your use of mixed rule types (app control, user objects, schedules). In my own tests on other platforms, I've found that introducing even a single rule referencing a dynamic user object or group adds more processing overhead than ten sequential static IP-based rules, because it forces an extra lookup to an external directory or internal state table. Did you notice any specific spike when you introduced those elements, or was the 0.8ms increase fairly linear as you built the stack?
Your planned next step with DPI/AV will be the real test. The hardware acceleration paths for simple rule matching versus full proxy-based inspection are completely different. I'd recommend running that test not just with the traffic allowed, but also with a policy that blocks it after inspection, to see if the penalty differs between a 'pass' and a 'drop' decision post-content scan.