It is a rule that allows connection (source) from Microsoft Outlook worldwide among other services to our Mail servers (destination) with services and application = smtp
Even though it's not documented anywhere, I suspect it's the object in the Destination field (Logical Server) that is causing traffic to not be templated.
I have an idea of how to work around this, but it involves creating an inline layer (change action from Accept to an Inline Layer, create a new one with just Firewall blade active).
The top level rule involves a regular host object (ls_smtp_ip) that is the same IP as ls_smtp (the Logical Server object).
The UI will give you a warning when you create an object with the same IP (which is expected).
The inline layer will only be evaluated if the top level rule matches, which is why the rules in the inline layer aren't specific.
When it's all said and done, it should look something like this:
What should happen (assuming installing policy isn't blocked with this configuration) is that the traffic matched by rules below this should now template.
That would mean the percentage of Accelerated Connections should dramatically increase.
Only Firewall is chosen in the inline layer settings!
Attempting to move the rule down fails due to the presence of multiple inline layers:
So, what other options do we have?
This topic is fully covered in my Gateway Performance Optimization Course. fwaccel stat showing Accept Templates are "enabled" yet the templating rate (Accelerated conns) is zero or very close to zero can be investigated with a new command line switch introduced in R81.20 GA: fwaccel templates -R
Generally "Prevented by Policy Rules" means one or both of the following is occurring:
1) In Access Control you have a blade other than "Firewall" enabled in your first/top policy layer in the case of Ordered Layers, or you have a blade other than "Firewall" enabled in the top/parent layer of a unified/inline policy implementation. In either case the firewall policy has been made capable of matching connections using applications/categories/data types instead of just straight port numbers, which SecureXL templating cannot handle and the Accelerated conns rate goes to zero.
2) You have enabled the "Protocol Signature" option on a service object that is used in your policy. This option is never set by default. Doing this requires streaming inspection to be invoked for a full rulebase match for protocol verification, which once again is incompatible with SecureXL templating.
Please note that the situations above DO NOT impact SecureXL Throughput Acceleration at all, in other words these conditions do not force traffic into a less efficient path such as F2F/slowpath, they only affect templating.
| User | Count |
|---|---|
| 9 | |
| 8 | |
| 8 | |
| 7 | |
| 6 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 |
Tue 22 Oct 2024 @ 05:00 PM (CEST)
Under the Hood: Securing Ingress Traffic with Azure Virtual WAN and CloudGuard Network SecurityFri 25 Oct 2024 @ 03:00 PM (CEST)
From Compliance to Competitiveness: Mastering DORA for Cyber ResilienceTue 29 Oct 2024 @ 02:30 PM (CET)
The Future of Hybrid Security: Triple Threat Protection (EMEA)Tue 29 Oct 2024 @ 02:00 PM (EDT)
The Future of Hybrid Security: Triple Threat Protection (Americas)Tue 22 Oct 2024 @ 05:00 PM (CEST)
Under the Hood: Securing Ingress Traffic with Azure Virtual WAN and CloudGuard Network SecurityFri 25 Oct 2024 @ 03:00 PM (CEST)
From Compliance to Competitiveness: Mastering DORA for Cyber ResilienceTue 29 Oct 2024 @ 02:30 PM (CET)
The Future of Hybrid Security: Triple Threat Protection (EMEA)Tue 29 Oct 2024 @ 02:00 PM (EDT)
The Future of Hybrid Security: Triple Threat Protection (Americas)
