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.

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.

Thanks for your input on this.

We're not going to change the way this is displayed in the product for now. I appreciate that the meaning of this can easily be misunderstood, but sometimes it's hard to be completely unambiguous when you're also trying to pack a lot of information into a small space. The text represents the state of the option, rather than a specific statement about what will happen to matching traffic. It simply means that if there is any web scanning or policy to be enforced on port 80/443, it will be done by the DPI engine rather than the proxy.

We'll certainly look again at a broad cross-section of UI/UX feedback once v18 is released and consider any changes that may be necessary in future versions.

Regards

Rich

Thanks for your input on this.

We're not going to change the way this is displayed in the product for now. I appreciate that the meaning of this can easily be misunderstood, but sometimes it's hard to be completely unambiguous when you're also trying to pack a lot of information into a small space. The text represents the state of the option, rather than a specific statement about what will happen to matching traffic. It simply means that if there is any web scanning or policy to be enforced on port 80/443, it will be done by the DPI engine rather than the proxy.

We'll certainly look again at a broad cross-section of UI/UX feedback once v18 is released and consider any changes that may be necessary in future versions.

Regards

Rich

Thank you to Michael and Rich for the many detailed answers to the question, but none explain how I turn of inspection on Lan to LAN rules.

In v 17 you did so by not using the proxy, but in V18 when not using the proxy you use DPI.

Now, I have spent a week working with a hardware support company to get a security camera working, eventually I came the conclusion that the application did not like DPI even with exceptions, no  log entries, all logs showing connections. 

I turned on the proxy and put some of my standard functions in place and now I have a stable security camera connection to the cloud server, all very good.

I am supposed to be able to connect to the camera using various applications on my none IoT network, again the logviewer shows the connections but the application does not connect.

I could try to use a WAF rule, but that wouldn't work because I have the DNS of the firewall setup the use the internal network address for access to overcome the continual certificate warnings when using the IP address to access the XG GUI.

So how do I turn off inspection of internal rules only?

Ian

Hi Ian,

Our intent is for it not to be necessary to turn this off, so that the DPI Engine has no impact on traffic if there are no scanning or inspection policies applicable to it, but so that we can still include information about it in our overall accounting of traffic.

There are still a couple of outstanding situations that we've come across in the EAP that we are aiming to fix before the GA release of v18, including a few relating to our handling of traffic that is not recognized as TLS or HTTP on port 443. One of the major impacts of this right now is OpenVPN SSL VPN connections, which send a few packets of custom handshake protocol before beginning a TLS handshake. We've had reports of a few IoT devices that use OpenVPN to tunnel traffic to the cloud - is it possible that's what's going on with your camera?

Regards

Rich

Hi Rich,

thank you for taking the time to investigate.

I don't think so, the camera does use 443, 80, UDP 9999 and UDP 57850. The 443 and the 80 are both handled by the proxy. The camera support team assure me that all is secure between the camera and their cloud servers using https for password handshaking etc.

I do see about 100MB of SSL over non SSL ports though but do not see any traffic in the daily reports about OPENVPN.

Ian

Update:- forgot to add I have had ATP disabled for a couple of days.

And I have this enabled.

RichBaldry said:

Hi Ian,

Our intent is for it not to be necessary to turn this off, so that the DPI Engine has no impact on traffic if there are no scanning or inspection policies applicable to it, but so that we can still include information about it in our overall accounting of traffic.

There are still a couple of outstanding situations that we've come across in the EAP that we are aiming to fix before the GA release of v18, including a few relating to our handling of traffic that is not recognized as TLS or HTTP on port 443. One of the major impacts of this right now is OpenVPN SSL VPN connections, which send a few packets of custom handshake protocol before beginning a TLS handshake. We've had reports of a few IoT devices that use OpenVPN to tunnel traffic to the cloud - is it possible that's what's going on with your camera?

Regards

Rich

 

Would this apply to SSL encrypted Newsgroup traffic potentially as well?  I am unable to connect to Astraweb over SSL.  Take XG out of the mix and it works.  I've got a firewall rule in place to do nothing, don't decrypt, don't touch it, don't scan it, don't categorize, none for everything, but clearly XG is doing something regardless.