Architecture for offloading
Sophos Firewall offers firewall, PKI, and IPsec acceleration on SFOS versions and appliances that support the offloads.
Offloading accelerates the traffic flow, freeing up resources on the host CPU for resource-intensive tasks, such as malware detection and antivirus scanning.
Modules and offloading decisions
The architecture contains SlowPath, comprising the firewall stack (kernel), the user space modules (including the Deep Packet Inspection (DPI) engine), and the offload module, which makes the decision to offload trusted flows. The architecture also contains FastPath, to which trusted flows and certain tasks can be offloaded.
Firewall acceleration offloads trusted traffic to FastPath after inspecting the initial packets in a connection. FastPath eliminates the need to apply complete firewall processing to every packet in a connection. With stateful tracking of individual connections, FastPath processes the packets, saving CPU cycles and memory bandwidth. It only acts as directed by the kernel.
The SSL/TLS inspection engine makes the offload decisions for PKI processing. The XFRM stack makes the offload decisions for IPsec encryption and decryption.
See Life of a packet.
Sophos Firewall retains SlowPath processing as a fallback path for functions that can’t be processed in FastPath or if FastPath can't function.
SlowPath continues to process protocols that aren't offloaded, such as IP in IP.
Offloading on appliances
FastPath is software-based, allowing us to maintain a common architecture between Sophos Firewall appliances and the software and virtual deployments. Updates to offloading and other feature enhancements are part of SFOS releases.
XGS Series appliances have a dual-processor architecture, which combines a multi-core x86 CPU with a dedicated Xstream Flow Processor. Xstream Flow Processor is a Network Processing Unit (NPU) specifically designed for offloaded operations.
XGS Series appliances offload processing to the Xstream Flow Processor for firewall, PKI, and IPsec acceleration for the processes that qualify.
After inspecting the initial packets in a connection, the x86 CPU offloads trusted traffic to FastPath, which runs on the Xstream Flow Processor. Re-signing X.509 server certificates for inspected TLS flows, and IPsec encryption and decryption are offloaded to the crypto hardware on the NPU for qualifying flows.
XG Series appliances deliver FastPath offloading with firewall acceleration on SFOS 18.0 and later versions. The acceleration is performed by the host x86 CPU.
|Offloading for versions||19.5||19.0||18.5||18.0|
|PKI acceleration |
(for TLS traffic inspected by the DPI engine)
|The following XGS Series appliances: |
1UL (4300, 4500)
2U (5500, 6500, 7500, 8500)
|IPsec acceleration||XGS Series||XGS Series||No||No|
|Firewall acceleration||XGS and XG Series||XGS and XG Series||XGS and XG Series||XG Series|
Virtual and software deployments
Virtual and software deployments of Sophos Firewall only offer firewall acceleration, using the same x86 CPU for offloaded traffic. They don't offer PKI and IPsec acceleration.
Hypervisor support: FastPath supports the VMware ESXi hypervisor. For other hypervisors, such as KVM, turn off FastPath using the CLI commands for firewall acceleration.
NIC drivers: FastPath supports the NIC drivers i40e, e1000, e1000e, igb, ixgbe, and vmxnet3. It doesn't load on other drivers. Sophos Firewall (including the DPI engine) still functions fully for the unsupported drivers but without the FastPath performance enhancements.
MTU: Currently, FastPath supports up to 3500 MTU on e1000 and e1000e NICs and up to 9000 MTU for the rest.
Offloaded network flow
Firewall, PKI, and IPsec acceleration are turned on by default. These are available based on the appliance series and the SFOS version.
Turning firewall and PKI acceleration on or off restarts the IPS service (DPI engine) every time.
After a TCP handshake is complete or one packet from each direction passes through Sophos Firewall, SlowPath fully classifies the flow and programs a connection cache in FastPath. It offloads kernel processing for subsequent packets in the same connection to FastPath.
DPI engine: The DPI engine inspects traffic from layer 4 and higher through stream processing. It applies SSL/TLS decryption and inspection, IPS policies, application identification and control, web policies (including proxy-less web filtering), and antivirus scanning in a single engine. Antivirus scanning includes Zero-day protection and file reputation analysis.
Offloading decisions are taken at each stage of security processing.
FastPath offloading: SlowPath delivers packets to the DPI engine through the kernel. Packets are sent through the Data Acquisition (DAQ) layer for security decisions if security policies apply. FastPath delivers the offloaded packets directly to the DPI engine through the DAQ layer, eliminating the need to retain copies in kernel memory.
If the DPI engine determines that the traffic can be offloaded, it instructs FastPath to cut off the flow from SlowPath and the DPI engine. The ability to offload some or all processing minimizes the load on the CPU.
Turning firewall acceleration on or off: When you turn off firewall acceleration on the CLI console, or when FastPath doesn’t load, Sophos Firewall continues to function fully but without the performance enhancements of FastPath.
To turn firewall acceleration on or off and see the status, see CLI commands for firewall acceleration.
The following restrictions apply to firewall acceleration:
- Doesn't support offloading for SSL VPN, QoS, DoS, RED, LAG, and PPPoE traffic.
- Supports offloading only for some types of bridge deployments.
- Doesn't support firewall acceleration for Active-active HA. Supports firewall acceleration for Active-passive HA on the primary node.
- Optionally, offloading can remain on when tcpdump is run. You can configure FastPath traffic to be sent to tcpdump.
The firewall re-signs X.509 server certificates for inspected TLS flows before sending it to the TLS client.
The DPI engine offloads PKI processing for X.509 certificate re-signing to the crypto hardware on the Xstream Flow Processor when TLS flows meet all the following conditions:
- TLS 1.2 and 1.3 flows.
- TLS flows inspected by the DPI engine.
- Flows that use RSA authentication with key sizes up to 4096 bits.
SFOS doesn't support the following:
- Offloading of symmetric crypto operations for inspected SSL/TLS flows.
- PKI acceleration for SSL/TLS flows in web proxy mode.
- PKI acceleration for SSL VPN connections that terminate on the appliance.
PKI acceleration is turned on by default on supported firewall appliances. See the following links:
The XFRM stack offloads ESP encapsulation, encryption, decapsulation, and decryption for policy-based and route-based IPsec VPNs. IPsec acceleration improves the throughput for IPsec VPN tunnels.
The XFRM stack offloads these processes to the crypto hardware on the NPU based on the phase 2 Security Associations (SA). It offloads SAs for all the encryption and authentication combinations available on SFOS except the following:
We recommend using the cipher AES-GCM 128 for the best performance.
IPsec VPN traffic can qualify for one of the following offloading processes:
Full offload: For offloaded SAs, the NPU's crypto hardware encapsulates, encrypts, decapsulates, and decrypts the corresponding packets. If the inner traffic qualifies, SlowPath processing is offloaded to FastPath, delivering full offload.
FastPath and SlowPath: For offloaded SAs, the crypto hardware decrypts or encrypts the packets. If the inner traffic doesn’t qualify for FastPath offloading, SlowPath processes the traffic, including encapsulation and decapsulation. FastPath finalizes the encapsulation after encrypting the packet.
Full SlowPath: For SAs that aren't offloaded, SlowPath performs the entire processing.
SFOS supports IPsec acceleration for Active-active and Active-passive HA on the primary node.
It doesn't offload SAs for the following:
- SAs that use unsupported cipher suites.
- SAs on virtual interfaces, such as VLANs.
- Source and destination IP addresses don't match those expected for the SA.
- IPsec traffic over VLAN and wireless interfaces.
Turning IPsec acceleration on or off restarts all IPsec tunnels and requires downtime. To turn it on or off and see the status, see CLI commands for IPsec acceleration.
Offloading based on rules and policies
You can configure rules and policies that enable the NPU to handle traffic fully, bypassing the firewall stack and the DPI engine. This can help you optimize offloading to accelerate cloud application traffic or the DPI engine based on traffic characteristics.
Examples are as follows:
- A firewall rule without IPS, web filtering, antivirus, or application control. Traffic is offloaded to FastPath after a handshake is complete or the initial packet passes through Sophos Firewall on either side of the connection.
- A firewall rule with an application control policy. Traffic is offloaded to FastPath after about eight packets.
- A firewall rule with IPS policy set to the rule action Bypass session. Traffic that matches IPS policy rules with this action is offloaded to FastPath.
A firewall rule with the following policies:
- An IPS policy containing intelligent offload signatures from SophosLabs.
- Web filtering without malware and content scanning or DPI engine settings. For firewall rules with malware and content scanning and DPI engine settings, FastPath delivers traffic to the DPI engine directly, bypassing the firewall stack.
No SSL/TLS inspection rules. For rules with the action set to Decrypt, FastPath delivers traffic to the DPI engine directly, bypassing the firewall stack.
- SSL/TLS inspection rules with the action set to Don't decrypt. For STARTTLS connections, traffic is offloaded to FastPath after 15 packets.
Make sure of the following:
- On the CLI, firewall acceleration must be turned on. It is on by default on supported firewall appliances.
- Go to Rules and policies > Firewall rules. Under Web filtering, make sure you don't select the option for using web proxy instead of the DPI engine.
- Go to Rules and policies > SSL/TLS inspection rules > SSL/TLS settings. Under Re-sign RSA with and Re-sign EC with, make sure you select an RSA certificate with a key size of 4096 bits or lower.
If you want to use CAs other than the ones used in SSL/TLS inspection settings for specific traffic, go to Profiles > Decryption profiles. Under Re-sign RSA with and Re-sign EC with, make sure you select an RSA certificate with a key size of 4096 bits or lower. Select this decryption profile in the SSL/TLS inspection rules.
The default re-signing CAs on the firewall use RSA.
Go to Profiles > IPsec profiles. Under Encryption and Authentication for phase 2 tunnels, make sure you don't select the following: