Question - BUG - DPI appears to be on by default

It works like a firewall rule - it is a top-down prioritized list and a given traffic only "hits" one rule.

Lets say you have:
Rule 1: Exclusion by website (URL groups Local/Managed TLS exclusion list)
Rule 2: Exclusion by application
Rule 3: source is your tv, do not decrypt
Rule 4: source is your computer, decrypt

So first your computer goes to adobe.com. That is in the managed TLS exclusion list which means Do not decrypt.
Then your computer goes to mylocalstore.com. That misses Rule 1,2,3 and hits Rule 4. It is decrypted.
Now your phone goes to mylocalstore.com. That misses Rule 1,2,3, and 4. It missed every rule. It is not decrypted.
Then your samsung TV goes to samsungtvapps.com, it hits rule 3 which is Do not decrypt.

Hi Michael,

thank you. I misunderstood the two default rules that only apply to URLs and applications in their exclusion lists.

With that better understanding in mind I will have another go at using the SSL/TLS rules.

Ian

Michael Dunn said:

So, if you are asking "how do I make sure that nothing is looking at the HTTP traffic" then what you want to do is disable web-in-snort or DPI mode. To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled).

If you are asking "how do I make sure that nothing is interfering with TLS connection" then what you want to do is not decrypt traffic. Make sure the traffic is hitting a SSL/TLS Inspection Rule for Do not Decrypt with Maximum Compatibility.

Michael Dunn, can you explain the point "To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled)."

regards

Michael Dunn said:

So, if you are asking "how do I make sure that nothing is looking at the HTTP traffic" then what you want to do is disable web-in-snort or DPI mode. To do that make sure that the traffic is hitting a firewall rule that does not has web policy None and no malware scanning (eg the "use proxy" button is disabled).

Typo. Sorry. See the "does not has" I think I wrote it one way then edited the sentence to phrase it differently and it ended up jumbled. And since I wrote that I have learned more.
It should say:
To do that make sure that the traffic is hitting a firewall rule that has web policy None and has no malware scanning (eg the "use proxy" button is disabled).

In other words - create a new firewall rule. See how the "Web filtering" section is not expanded. If you expand the Web policy is none, the Scan HTTP and decrypted HTTPS is not checked, and Use Web proxy instead of DPI engine is disabled. Traffic matching that firewall rule will have nothing looking at the HTTP traffic. Except... If the firewall rule has "identify and control applications (App control)" then it may still look at the HTTP traffic, and if you have the global setting ATP (Advanced Threat Protection) then it will still look at HTTP traffic.

There is a known issue with ATP... Turning it on intentionally turns on HTTP scanning for all traffic regardless of rules. It is working as intended but having unintended consequences. I do not know if/when/how we will resolve.

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.