Question - BUG - DPI appears to be on by default

Hi folks,

while working on a thread in the XG forum I checked some of firewall settings and found I think that the DPI is on by default.The screenshots below do not show the DPI as highlighted, on the rules where it is selected and not selected.

Ian

 

The first screenshot uses the DPI and where as the second screenshot is of an internal connection.

Am I interpreting the screenshots wrong or is there a bug?

  • 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

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • 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.

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Hi Michael,

    As far I understood from your explanation regardless of Zone configuration(LAN-LAN, LAN-WAN) DPI engine will be enable by default. I've tested this scenario as you mentioned in which I have configured LAN-WAN rule with NONE Web Policy and applied SSL/TLS policy with (ANY Source and destination )which in result showed me HTTPS scanning getting applied to that HTTPS website.

    Now my question here is, Earlier in v17 if we set NONE policy then it means that webproxy will not be applied but now with v18 lets say if I want to do some troubleshooting without Legacy/DPI based webproxy then how is it possible to check?

    I tried disabling SSL/TLS inspection option in advance settings in SSL/TLS inspection global option which in result showed me website without any proxy ( DPI/legacy ) getting involved but that is not a solution because let's say if I want to test for a specific machine without any policy(Legacy/DPI) like we try to check with v17 i.e. as NONE web policy how can I verify it?

  • rfcat_vk said:

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

     
    There is a minor bug in the UI, which will be fixed post-GA.  There is no problem in the backend.

     

     

    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.

  • James Panther said:

    As far I understood from your explanation regardless of Zone configuration(LAN-LAN, LAN-WAN) DPI engine will be enable by default. I've tested this scenario as you mentioned in which I have configured LAN-WAN rule with NONE Web Policy and applied SSL/TLS policy with (ANY Source and destination )which in result showed me HTTPS scanning getting applied to that HTTPS website.

    Now my question here is, Earlier in v17 if we set NONE policy then it means that webproxy will not be applied but now with v18 lets say if I want to do some troubleshooting without Legacy/DPI based webproxy then how is it possible to check?

    I tried disabling SSL/TLS inspection option in advance settings in SSL/TLS inspection global option which in result showed me website without any proxy ( DPI/legacy ) getting involved but that is not a solution because let's say if I want to test for a specific machine without any policy(Legacy/DPI) like we try to check with v17 i.e. as NONE web policy how can I verify it? 

    Hi James,

    There are two different systems involved. I'll have to use some internal names.

    The first is sslx. This is the new way of decrypting TLS traffic, and it is configured using the SSL/TLS Inspection Rules. For your purposes, you can say it is implemented in snort.

    The second is web-in-snort, which in the UI is called DPI mode. Web in snort works on HTTP traffic, as well HTTP traffic that comes from sslx (ie HTTPS). It is configured in the Firewall Rules. It is also implemented in snort.

    To go further, IPS (intrusion prevention system) is also in snort. And Application policy is also in snort. And traffic shaping is in snort. And Advanced Threat Protection is in snort.

    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.

    The confusion/complication is the HTTPS traffic is both TLS (sslx) and HTTP (web-in-snort). But in v18 just because you are doing TLS decryption does not mean you are doing web-in-snort (DPI mode) and vice versa. I know it may not make sense but you can have decrypted HTTPS traffic and be using the Certificate Authority from the XG and still not be using DPI mode.

    If you don't want HTTPS to be looked at all, you need to make sure that the firewall rule does not have any web policy or malware scanning, and that the TLS rule is do not decrypt.  But be aware that even then, snort will be looking at the traffic in order to enforce all the other things that snort enforces (App control, IPS, ATP, traffic shaping).

     

    The decoupling of TLS inspection (sslx) from HTTP filtering (web-in-snort / DPI mode) allows everything to be port and protocol agnostic. The TLS decryption rules also apply to SSH sessions, smtps, and other TLS encrypted communication.  The HTTP filtering is port agnostic.

    Think, if you you will, about WebAdmin which is HTTPS going to port 4444.  In 17.5 traffic like this this would not be caught by the transparent mode web proxy.  In 18.0 DPI mode it is.

  • Hi Michael,

    in summary what you are saying is we should build our own SSL/TLS inspection rule for each device/device group/users and disable the default rules?

    I would like to suggest that the default rules be unlocked so they can be the default at the bottom instead of at the top. You cannot move your own rules above the default XG rues.

    Ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Ian, That is not what I am saying at all.

    The two rules that are in there at the top are for global exclusions for SSL inspections. Unless you were specifically trying to have one of those decrypted, there is no reason to not have them at the top. It is just like Web Exceptions.

    Why are you trying to do that would make you want a higher priority rule?

  • Hi Michael,

    All traffic appears to pass through the top rule and there does not appear to be away of passing traffic through the second rule. The second rule (application) never shows traffic. I do have a third rule which has specific devices which does show traffic.

    Ian

    XG115W - v20.0.2 MR-2 - Home

    XG on VM 8 - v21 GA

    If a post solves your question please use the 'Verify Answer' button.