There's two approaches to applying access policies when there more than one engine: in parallel and in series.
I'm forgetting which way it used to be on certain firewalls but it used to be important to know at which point onward routing, NAT, and firewall rules were applied and if any changes where applied at previous steps (e.g. has NAT happened to the packet yet). With multi-core CPUs (and multi-CPU servers) it possible to run the tests concurrently and determine whether to allow the traffic or not based on the returned status of each test.
I was just wondering whether firewall rules are applied before threat prevention. It would seem probable that they are as TP is likely to be more processor intensive so best to remove known-unwanted traffic first. But I think I see some traffic in TP alert/deny logs that are from countries I've totally blocked in the FW policy (at the very top). It's hard to test on an active setup.
Anyone noticed similar or not?
I'm forgetting which way it used to be on certain firewalls but it used to be important to know at which point onward routing, NAT, and firewall rules were applied and if any changes where applied at previous steps (e.g. has NAT happened to the packet yet). With multi-core CPUs (and multi-CPU servers) it possible to run the tests concurrently and determine whether to allow the traffic or not based on the returned status of each test.
I was just wondering whether firewall rules are applied before threat prevention. It would seem probable that they are as TP is likely to be more processor intensive so best to remove known-unwanted traffic first. But I think I see some traffic in TP alert/deny logs that are from countries I've totally blocked in the FW policy (at the very top). It's hard to test on an active setup.
Anyone noticed similar or not?
