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

Thank you Michael Dunn for the very detailed explanation. It’s a lot more helpful than the back and forth.

Disabling ATP did help. It was about 10% of the CPU load. I will work on exceptions.

While I understand the firewall has to look at everything, I truly think a firewall rule to bypass all inspection would be helpful, for this exact scenario. It’s not very clear in the documentation what process do what and what they require. I just think it would be easier.

One thing I did notice with SSL/TLS enabled, is it makes the Postgres process spike up a lot for CPU usage when looking at the TOP output. Not sure why. Maybe this is normal, but it’s almost as much usage as snort.

Hi Michael Dunn , I stopped posting on the forums for awhile after the post from the other Sophos employee, that didn't have an open mind. I decided I would return in hopes it would help others. So, I got 2 XGS 2300's to test with. I will say the NPU definitely helps. It dropped the CPU usage. I does not help with applications that open new connections constantly though, which I can understand because it can't learn what it is. I still have our production traffic using a layer 3 switch since the firewall can't move traffic to it's stated rate unless features are disabled, and that is ok. My main point of this was to help simplify deployments that are using Sophos firewalls. It is a lot easier to use a firewall to do everything and have the benefit of it being able to inspect the traffic we want it to. It's clear that is not a use case for us or the few customers I help out. Maybe in the future.

LuCar Toni I appreciate you being on here to help others, but please have an open mind. You are constantly attacking other's post because their setup doesn't conform to the "Sophos" standard. Sophos has a very small percentage of the market for deployed firewalls. Just because Sophos can't do it, doesn't mean it's not the right way. I didn't respond months ago because you are not looking at the bigger picture, which is what the competition is doing.

"Stop thinking in this scenarios from a IT security perspective. The firewall is not a layer 3 switch and will never be one."

There are plenty of other vendors that can meet their rated performance with all features enabled for inter-vlan routing. So a firewall can be a layer 3 device in most SMB deployments. That is not he case with Sophos. That is ok, but don't say a a firewall cannot be a layer 3 device and will never be one, that's wrong. It's just Sophos can't do it. I have a Fortinet device and a Checkpoint device I mange that exceed their rated throughput even when inspecting traffic between vlans.

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

Great point and I don't disagree. My post started with encrypted SMB traffic. I don't need XG even looking at it if it slows it down. Give us the option is all I'm saying. Plenty of people use XG as a router. Take it as a feature request and not "you're doing it wrong". Give us the option of what to look at is all I was saying.

I'm not on here to start a back and forth with you either, but that seems to be what always happens when someone picks out an XG shortcoming. We are all just here to try and make XG better. Not reason to jump on someone just because XG can't do something. That doesn't mean their setup is wrong either. Try to understand their setup and what they are coming from before posting.

Hi Michael Dunn , I stopped posting on the forums for awhile after the post from the other Sophos employee, that didn't have an open mind. I decided I would return in hopes it would help others. So, I got 2 XGS 2300's to test with. I will say the NPU definitely helps. It dropped the CPU usage. I does not help with applications that open new connections constantly though, which I can understand because it can't learn what it is. I still have our production traffic using a layer 3 switch since the firewall can't move traffic to it's stated rate unless features are disabled, and that is ok. My main point of this was to help simplify deployments that are using Sophos firewalls. It is a lot easier to use a firewall to do everything and have the benefit of it being able to inspect the traffic we want it to. It's clear that is not a use case for us or the few customers I help out. Maybe in the future.

LuCar Toni I appreciate you being on here to help others, but please have an open mind. You are constantly attacking other's post because their setup doesn't conform to the "Sophos" standard. Sophos has a very small percentage of the market for deployed firewalls. Just because Sophos can't do it, doesn't mean it's not the right way. I didn't respond months ago because you are not looking at the bigger picture, which is what the competition is doing.

"Stop thinking in this scenarios from a IT security perspective. The firewall is not a layer 3 switch and will never be one."

There are plenty of other vendors that can meet their rated performance with all features enabled for inter-vlan routing. So a firewall can be a layer 3 device in most SMB deployments. That is not he case with Sophos. That is ok, but don't say a a firewall cannot be a layer 3 device and will never be one, that's wrong. It's just Sophos can't do it. I have a Fortinet device and a Checkpoint device I mange that exceed their rated throughput even when inspecting traffic between vlans.

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

Great point and I don't disagree. My post started with encrypted SMB traffic. I don't need XG even looking at it if it slows it down. Give us the option is all I'm saying. Plenty of people use XG as a router. Take it as a feature request and not "you're doing it wrong". Give us the option of what to look at is all I was saying.

I'm not on here to start a back and forth with you either, but that seems to be what always happens when someone picks out an XG shortcoming. We are all just here to try and make XG better. Not reason to jump on someone just because XG can't do something. That doesn't mean their setup is wrong either. Try to understand their setup and what they are coming from before posting.