DPI Engine Bypass

The firewall "sees" all traffic flowing through the XG.  DPI (Deep Packet Inspection) is implemented using snort and it "sees" almost all traffic.

Snort does many things:
- detect TLS traffic on any port
- decrypt TLS traffic if configured to do TLS/SSL rules
- detect HTTP traffic on any port
- enforce Web policy on any HTTP / HTTPS
- enforce ATP
- enforce IPS
- enforce app control
- enforce bandwidth limiting

If you want the XG to do as little as possible for given traffic, each of these things should be turned off for that traffic. snort will still see the traffic, but it will do less processing. I want to focus on the item that is the most common cause of snort doing more than expected.

ATP - Advanced Threat Protection - is making sure that a virus on an already infected system cannot talk to any command and control systems on any port. Some parts of ATP are enforced by the DNS server, some by snort rules, and some by web destination rules (by snort or web proxy). It is enabled globally because DNS server enforcement cannot be controlled by firewall rules, and because we want to make sure that ATP protections are enforced on every port.

When there is no web filer policy, no app filter policy, no a/v scanning, and no ATP:
There is detection for TLS traffic on all ports, and TLS decryption rules are applied
There is detection of plaintext HTTP on all ports. However there is no categorization or enforcement of the HTTP standard.

However when any of those things change (for example ATP is enabled):
There is detection for TLS traffic on all ports, and TLS decryption rules are applied. The destination SNI is compared against ATP urls.
There is detection of plaintext HTTP on all ports. If there is HTTP then there is categorization. The destination URL is compared against ATP urls. The HTTP specification is enforced.

Because web filer policy, app filter policy, and a/v scanning are all set per firewall rule, it is easy an obvious to turn them off for given traffic.
Because ATP is set globally, it is not obvious how to turn it off for given traffic. You must use an ATP exception which is configured on the Device Console.

support.sophos.com/.../KB-000038900

If your really trust the traffic and want minimal inspection then you must
- set the TLS rule that matches to Do not decrypt
- set the firewall rule to Web Policy None and malware scanning off
- set the firewall rule to App Control policy None and IPS policy None
- set the firewall rule to have an exception for ATP in Device Console

--------------------

> It’s crazy to think I can’t create a firewall rule that has no options, to bypass the DPI. You would think setting all options to none would be the answer. Not in Sophos world.

You set all options in the firewall rule, but the global option for ATP is still in effect.
Try turning off the global ATP to see if that causes a drop in CPU. If it does, then determine whether you want to disable it globally, or enable it and create exceptions for your firewall rules.

> If I have inter-VLAN traffic that is encrypted, say SMB traffic, I don't want the firewall to look at it at all. It uses resources even if you have a policy to "Do Not Decrypt".

You cannot ever have the firewall "not look at it", snort will look at almost all traffic. If you want the XG to do as little as possible you should not use the global setting for ATP, or you should use ATP exceptions.

You may also want to look at fastpath. Please note: I am not an expert in fastpath.
The XG series hardware has a virtual fastpath and the XGS series hardware has a hardware fastpath.
If you are having CPU concerns, please make sure that fastpath is enabled.

My understanding is the term "fastpath" is often confused to mean two different but related things.
- with "fastpath" traffic being inspected by snort is processed more efficiently, resulting in lower CPU
- with "fastpath offload" traffic that snort determines needs no more inspection will have remaining traffic on that connection forwarded without going through snort, resulting in lower CPU

docs.sophos.com/.../Architecture.html

MichaelBolton If you have fastpath enabled and ATP disabled, and you are seeing 60% CPU dropping to 30% by using the "SSL/TLS inspection" switch on the SSL/TLS inspection rules page, please let me know.

Also, I do have fastpath enabled, but honestly, it hasn't done much for us in the past. I'm sure the technology improved in V18, but this was a carryover feature from Cyberoam, and it never really worked right from V15. It made "some" improvements on Cyberoam. It actually didn't work at all in an active-passive HA cluster on SFOS until V18, from my understanding, even though it may have been enabled in the console.

I did test this scenario with and without it enabled and the differences are very marginal. I am sure the XGS would do better with the dedicated NPU.

I moved the traffic back to a layer 3 core switch, so I can't test it anymore and report. I will try to lab up some virtual XG's and servers to simulate the environment and test it again.

At the end of the day though, I just think it would be very helpful to just put in a firewall rule that bypasses everything and get near wire speed throughput that the box is rated for. Just my opinion. This helps simplify some networks by eliminating a layer 3 switch.

Stop thinking in this scenarios from a IT security perspective. The firewall is not a layer 3 switch and will never be one. Sophos is a IT security company and one of the primary focus points is to prevent/detect attacks. If you start to remove certain features, you will go back to the log ages in terms of XDR. If your backup server is compromised, you want to know. Backup servers usual have high ratings to all servers - perfect jump point to access the network and use lateral movement. Most customers do not have anything to prevent lateral movement (in the year 2021). Therefore attacks might get AD creds and search the backup server. Then they spread from there without anything in between. 

What do you get usual? Look at the incidences in the last days. You see always log entries: 192.168.1.1 talks to 192.168.2.1 with port 443. You cannot say, what is going on there. Thats the reason, why customers looking into SSL decryption even in the internal network (for unknown stuff). And to going back to "i want my speed back, so i disable everything" is not the right call, from my perspective. 

Thats the reason for XGS in the first place. Technology to utilize the architecture to get speed on the wire, even with protection enabled. 

Stop thinking in this scenarios from a IT security perspective. The firewall is not a layer 3 switch and will never be one. Sophos is a IT security company and one of the primary focus points is to prevent/detect attacks. If you start to remove certain features, you will go back to the log ages in terms of XDR. If your backup server is compromised, you want to know. Backup servers usual have high ratings to all servers - perfect jump point to access the network and use lateral movement. Most customers do not have anything to prevent lateral movement (in the year 2021). Therefore attacks might get AD creds and search the backup server. Then they spread from there without anything in between. 

What do you get usual? Look at the incidences in the last days. You see always log entries: 192.168.1.1 talks to 192.168.2.1 with port 443. You cannot say, what is going on there. Thats the reason, why customers looking into SSL decryption even in the internal network (for unknown stuff). And to going back to "i want my speed back, so i disable everything" is not the right call, from my perspective. 

Thats the reason for XGS in the first place. Technology to utilize the architecture to get speed on the wire, even with protection enabled.