Question - BUG - DPI appears to be on by default

The way it works (confirmed on my box):

If the firewall rule "Use web proxy instead of DPI engine" is checked then PRX is green and the text is "Use proxy".

If the firewall rule "Use web proxy instead of DPI engine" is not checked then PRX is white and the text is "Use DPI engine".

Can you confirm this is what you see?

Hi Michael,

I can confirm what you posted. My issue is that DPI should not be on a LAN to LAN connection unless enabled by adding a web function in the web drop down box. The rule has NONE in that box and has never used proxy in the v17 versions.

Ian

DPI does not care whether it is LAN to LAN or not.

In your screen shot, it shows that Web is enabled with Allow All policy. Which means that the rule as stands will do port-agnostic HTTP traffic detection. Then depending on what SSL/TLS inspection rule matches it may or may not decrypt TLS traffic and then do HTTP traffic detection on that data. It will apply the Allow All web policy to any HTTP traffic.

Now if you did not have a Web policy, AV scanning, or App control (all three are white in the summary) it will not do port-agnostic HTTP detection, and you could argue the it should not say "Use DPI engine". It does say it. Of course it will still apply SSL/TLS inspection rules and if there is TLS may decrypt the traffic.

So there might be a case for setting it to "--" in some instances, but for your scenario Use DPI engine is correct.

But to be clear, there is nothing that cares what the source and destination zone are when it comes to either web or dpi mode.

DPI does not care whether it is LAN to LAN or not.

In your screen shot, it shows that Web is enabled with Allow All policy. Which means that the rule as stands will do port-agnostic HTTP traffic detection. Then depending on what SSL/TLS inspection rule matches it may or may not decrypt TLS traffic and then do HTTP traffic detection on that data. It will apply the Allow All web policy to any HTTP traffic.

Now if you did not have a Web policy, AV scanning, or App control (all three are white in the summary) it will not do port-agnostic HTTP detection, and you could argue the it should not say "Use DPI engine". It does say it. Of course it will still apply SSL/TLS inspection rules and if there is TLS may decrypt the traffic.

So there might be a case for setting it to "--" in some instances, but for your scenario Use DPI engine is correct.

But to be clear, there is nothing that cares what the source and destination zone are when it comes to either web or dpi mode.

Hi Michael,

the first screenshot is using the DPI with web as you point that is correct. I posted that as a reference to the DPI box colour. The second screenshot is not using the DPI or any web settings it does have application and IPS but that should not be triggering DPI from my understanding.

I will remove the allow all from the second rule which is a hangover from a previous since fixed bug.

Ian

Update - I have removed all web, application and IPS settings and still the rule shows DPI.

rfcat_vk said:

Update - I have removed all web, application and IPS settings and still the rule shows DPI.

This is a checkbox.  Logically a checkbox has two states, checked and unchecked.  So what we coded was if the box is checked, display the summary one way "Use proxy" and if it is unchecked display the summary a different way "Use DPI engine".  The problem is that this checkbox is actually tri-state.  The third state is disabled (and unchecked).

The checkbox is disabled if there is no web policy or malware scanning (you can see this when you edit the rule).  In this case we summarize as "Use DPI engine" because it is actually unchecked, when we should summarize as "--" because it is disabled.