Sophos Firewall appliances are next-generation firewalls securing the network, endpoint devices, and data in transit using advanced networking, application, and user controls.
Sophos Firewall appliances offload trusted traffic to FastPath after inspecting the initial packets in a connection. FastPath processes layer 2 and higher traffic, delivering packets at wire speed. Generally, most firewall processing applies in full on each packet, using more processing cycles than necessary. Offloading enables Sophos Firewall to minimize processing cycles.
XG Series appliances running SFOS 18.0 and later versions offload trusted traffic to Virtual FastPath that runs on the host x86 CPU. These appliances deliver only firewall acceleration.
XGS Series appliances are available from 18.5 and later versions. These appliances offer firewall, PKI, and IPsec acceleration for the supported versions and appliances. Processes are offloaded to the Network Processing Unit (NPU), which runs as a dedicated co-processor when traffic is offloaded. For the appliance models and versions that support the different types of acceleration, see the following table:
Offloading for versions
PKI acceleration (for TLS traffic inspected by the DPI engine)
The following XGS Series appliances:
1UL (4300, 4500)
2U (5500, 6500)
XGS and XG Series
This article describes the processing and offloading mechanisms on XGS Series models that support these types of acceleration.
SFOS delivers high-speed processing using the following offloading mechanisms:
The policies and settings you configure determine SlowPath processing and the DPI engine's security policy enforcement.
XGS Series appliances are based on Xstream architecture, a dual-processor architecture that combines a multi-core x86 CPU with a dedicated Xstream Flow Processor. The Xstream Flow Processor is a Network Processing Unit (NPU), which accelerates trusted traffic flow, freeing up resources on the host CPU for resource-intensive tasks, such as malware detection and antivirus scanning.
On XGS Series appliances, after inspecting the initial packets in a connection, the x86 CPU offloads trusted traffic to FastPath, which runs on the dedicated Xstream Flow Processor specifically designed for FastPath operations. Additionally, these appliances perform IPsec acceleration, offloading encryption and decryption to FastPath. Some XGS Series models perform PKI acceleration for inspected TLS flows. This enables the XGS Series appliances to deliver higher processing efficiencies.
The data plane uses both hardware and software components, delivering high levels of processing efficiency. It contains the following domains and processes:
SFOS performs firewall, PKI, and IPsec acceleration by offloading the qualifying processes to the NPU. These types of acceleration are turned on by default.
Turning firewall and PKI acceleration on or off restarts the IPS service (DPI engine) each time.
The first packet of every connection flows through SlowPath. After the complete TCP handshake occurs or the first packet from each direction passes through SlowPath, SlowPath fully classifies the flow.
If the firewall rule's security policies don't apply to a flow, SlowPath can make the decision to offload the flow to FastPath on the NPU. These packets don't require further processing to verify their identity and destination.
If security policies apply, the traffic requires DPI engine processing, and SlowPath instructs FastPath to deliver subsequent packets to the DPI engine through direct packet delivery. The DPI engine processes approximately eight packets before determining whether the traffic is safe based on application processing or a safe verdict from Sophos Labs. The data plane offloads some or all security processing of subsequent packets to FastPath, completing the offload process for the connection.
If the DPI engine decides to offload the flow, it instructs FastPath to cut off the flow from SlowPath, and then full firewall acceleration takes place for the connection.
The data plane uses the hardware to cache the classification decisions, such as encapsulation, decapsulation, routing and switching decisions, and security policy verdicts. The data plane programs a connection cache containing the classification decisions with FastPath.
The following restrictions apply to firewall acceleration:
The firewall offloads PKI processing (re-signing the X.509 server certificates) for TLS flows that meet all the following requirements:
Currently, the firewall doesn't offload symmetric crypto operations for inspected SSL/TLS flows.
SFOS doesn't support the following:
For IPsec tunnels, the firewall offloads CPU-intensive processes, such as ESP encapsulation, encryption, decapsulation, and decryption, to the crypto hardware on the NPU, freeing up the x86 host CPU. IPsec acceleration improves the throughput for IPsec VPN tunnels.
Criteria for offloading SAs
The XFRM stack on SlowPath offloads IPsec encryption and decryption based on the phase 2 Security Association (SA). It offloads SAs for all the encryption and authentication combinations available on Sophos Firewall except the following:
We recommend using the AES-GCM 128 cipher for the best performance.
IPsec acceleration takes place only on the primary node in both active-passive and active-active HA. When the primary node goes down and the auxiliary takes over, the SAs are renegotiated. Existing keys are removed, and the new primary node makes the decision to offload the SAs.
The following restrictions apply on the firewall:
A summary of how SlowPath processes the first packet in the ingress and egress stages is as follows:
Ingress stage: SlowPath performs stateful inspection on the initial packet of a connection. It does the following during the ingress stage:
Transfer to the DPI engine: After SlowPath processes the first ingress packet, it transfers the packet to the DPI engine if security policies apply to the traffic. The DPI engine enforces the security policy decisions and transfers the packet back to SlowPath.
Egress stage: SlowPath does the following during the egress stage:
The packet is then forwarded to its destination.
Firewall acceleration (SlowPath processing offloaded to FastPath)
After SlowPath fully classifies the flow and decides it's eligible for offload, it programs a connection cache in FastPath. Subsequent packets in the connection are offloaded to FastPath.
After the offload, SlowPath continues to manage the connection, which requires a small amount of x86 CPU involvement. If traffic can't be offloaded for any reason, SlowPath continues to process the packets in the connection.
The full details of how firewall acceleration takes place in the ingress and egress stages are as follows:
After reassembling packets received on the SFOS interface, SlowPath drops malformed packets, including those with TCP/IP protocol anomalies, such as malformed headers, and those that don't meet specifications, such as TCP time-outs, maximum segment size, and retransmissions.
SlowPath then implements the following processing in the ingress stage:
SlowPath allows incoming packets from existing RED tunnels. These are connections from Sophos Firewall to a Remote Ethernet Device (RED) or site-to-site connections between two Sophos Firewall devices using a layer 2 RED tunnel.
RED devices connect remote offices through encrypted tunnels over the WAN zone. Sophos Firewall in the head office and the RED device in the remote office contain a RED core engine, which processes the RED traffic. Static routes determine RED traffic routing from the branch office to the head office.
The RED core engine in Sophos Firewall decrypts traffic from the remote office to the head office and transfers it to SlowPath to implement firewall and NAT rules.
For outgoing traffic from the head office to the remote office, SlowPath implements firewall and NAT rules and then transfers the traffic to the RED core engine for encryption. After encrypting the traffic, the RED core engine forwards traffic to the remote office. RED traffic isn't offloaded to FastPath.
DoS and spoof protection
SlowPath applies DoS (Denial of Service) and spoof protection policies on all traffic, including traffic that bypasses stateful firewall inspection through connection bypass ACLs created on the command-line interface. Traffic crossing the SYN, UDP, TCP, and ICMP flood thresholds specified in DoS settings is dropped.
Traffic bypasses DoS protection checks for exceptions specified in DoS bypass rules. DoS checks aren't offloaded to FastPath.
SlowPath checks IP addresses based on the Advanced Threat Protection (ATP) database. If Sophos Firewall is configured as the DNS server, SlowPath checks the domain names with the ATP database. If it finds the IP addresses or domain names in the database, it takes action specified in the ATP module.
SlowPath looks up the following rules and parameters matching the traffic criteria:
The packet is tagged with the matching SD-WAN route for processing later in the flow. The SD-WAN route determines the destination interface based on the specified gateway.
After the application module in the DPI engine identifies the application, SlowPath matches an SD-WAN route for subsequent connections to the same application.
Route lookup also identifies system-destined traffic.
Firewall rule lookup and processing
SlowPath matches firewall rules based on the following traffic criteria:
· Source port and IP address
· Source zones
· Destination port and IP address
· Destination zones
· Users (based on the source IP address)
· Unknown users
If none of the firewall rules match the criteria, the default "Drop all" rule (ID 0) applies, and the packets are dropped. Traffic is blocked if the matching firewall rule has its action set to drop or reject.
For traffic with the firewall rule action set to accept, the connection is tagged with the firewall rule ID and the security policies specified in the rule, such as web filter, application filter, IPS, and QoS policies. SlowPath also flags logging and antivirus scanning if specified in the firewall rule.
If the user identity remains unknown, the connection is dropped, and the captive portal is shown to the user. After the user signs in through the captive portal, the user identity becomes available, and SlowPath processes the initial packet.
The default routing precedence in Sophos Firewall is static route, SD-WAN route, and VPN route.
If an application object is specified in the SD-WAN route, an SD-WAN route without application criteria is matched for the first connection. For subsequent connections, an application-based SD-WAN route is applied.
IPsec connections are used for site-to-site (policy-based and route-based) and remote access tunnels.
If IPsec acceleration is turned off or SAs aren't offloaded, the incoming IPsec (ESP) packet is sent to SlowPath for decapsulation and decryption. SlowPath transfers the packet to the XFRM stack residing on it. The XFRM stack decapsulates and decrypts the packet based on the Security Parameter Index (SPI). It then transfers the decrypted traffic back to SlowPath. The packet goes through the SlowPath processes from DoS and spoof protection to routing.
If SlowPath decides to offload (firewall acceleration) the inner (decrypted) packets, it instructs the NPU. Subsequent packets arriving in this tunnel are retained on FastPath and cut off from SlowPath.
After the DPI engine enforces security policies, egress traffic is handed over to SlowPath. SlowPath then processes traffic exiting Sophos Firewall. The processing flow in the egress stage is as follows:
SlowPath applies the matching SNAT rule to outgoing traffic. It applies SNAT to IPsec VPN packets if NAT settings are specified in the configured IPsec connection. If address translation isn't specified, the default SNAT rule applies, masquerading the source IP address.
Suppose IPsec acceleration is turned off, or the SAs aren't offloaded. After routing, SlowPath transfers packets egressing towards the VPN zone through IPsec0 (IPsec virtual interface) and virtual tunnel interfaces to the XFRM stack.
The XFRM stack uses the packet's source and destination IP addresses and ports, protocol, and listening interface to match the IPsec connection and profile. It encrypts and encapsulates the traffic based on the IPsec profile's criteria. It then transfers the packet to SlowPath for egress processing.
SlowPath implements traffic shaping based on the policy specified in the firewall rule and sends the packets to layer 2 for transmission outside the network. The packets then exit Sophos Firewall through the egress interface. QoS isn't offloaded to FastPath.
After a complete handshake or the first packet of every connection flows through SlowPath, a classification decision is made. Traffic that doesn't require DPI engine processing and meets all other criteria for FastPath eligibility is offloaded to FastPath.
The user space contains the following modules:
This component contains the web proxy, FTP, email, and WAF engines.
The web proxy operates in the user space but not in the DPI engine. If web proxy filtering (instead of the DPI engine) is specified in the firewall rule, traffic is handed over to the web proxy engine. The engine decrypts HTTPS traffic on the standard port 443, identifies the category, and enforces the specified web policy.
Web content scanning takes place in the antivirus engine in real-time or batch mode based on the scanning settings configured in the web module. Even when web proxy is selected, web content filtering over non-standard ports takes place in the DPI engine.
If web proxy isn't selected in the firewall rule, the DPI engine implements web filtering, including HTTPS decryption based on SSL/TLS inspection rules. It also enforces web policy settings and content scanning.
Protection for file transfers takes place here. You set the FTP scanning settings in the firewall rule.
SlowPath forwards SMTP/S, POP/S, and IMAP/S traffic to the email engine. The engine processes emails in both MTA (Mail Transfer Agent) and transparent proxy modes. Depending on the mode in which Sophos Firewall is deployed, it applies SMTP and POP-IMAP policies for spam and malware.
The engine encrypts outgoing traffic based on the SPX encryption template and decrypts incoming traffic based on the email settings. The email engine sends packets to the antivirus engine for malware processing and the anti-spam engine for a spam check.
WAF (web server protection)
The reverse proxy processes incoming connections to web applications hosted within the network.
SlowPath identifies the WAF rule based on the port and destination IP address, which is a WAN interface or public IP address, and transfers the packets to the WAF engine. The WAF engine communicates with the database and applies the settings and modifications specified in the WAF rule, such as an HTML rewrite. It then sends a response to the client (example: web browser).
If form-based authentication is configured, the WAF engine shows a sign-in page, performing reverse proxy authentication. After the user is authenticated, the WAF engine performs the modifications specified.
The engine shows an error page if the domain name isn't configured in WAF. An error page is also shown when the WAF engine blocks requests based on malware scan or common threat filter (CTF) results. WAF traffic isn't offloaded to FastPath.
This component contains antivirus scanning and zero-day protection.
Antivirus scanning takes place for web, FTP, email, and WAF traffic. Sophos Firewall performs streaming antivirus scanning. If the DPI engine passes a verdict that the traffic is safe, antivirus scanning doesn't take place for traffic flowing through the DPI engine.
Files are sent for detonation to a data center in the cloud over a secure connection based on your settings. You can exclude specific file types in email attachments and web downloads from analysis by zero-day protection.
Packets are sent to the anti-spam module for spam scanning based on the settings in the SMTP policies.
Sophos Firewall listens on the default port 8443 over TCP and UDP protocols for SSL VPN packets. The local service ACL must allow SSL VPN access for the packet's source and destination zones. Sophos Firewall implements SSL/TLS-based VPN using OpenVPN, which runs in the user space.
For incoming SSL VPN traffic, OpenVPN decrypts the packet and sends it to SlowPath using the TUN interface. Decrypted packets then go through the regular SlowPath processing.
For outgoing SSL VPN traffic, SlowPath routes packets to the Tun0 interface based on the routing entry added for the destination when the SSL VPN tunnel comes up. Packets are transferred through the Tun0 interface to OpenVPN in the user space. The OpenVPN stack encrypts the packets and transfers them to SlowPath for encapsulation and QoS implementation.
After the ingress stage, the DPI engine enforces security policies based on the tagging performed during the firewall rule lookup. The engine is in the user space and enforces the following security rules and policies:
The DPI engine inspects traffic from layers 4 to 7 using stream processing. Offloading decisions are taken at each stage of security processing based on the verdicts passed by the security modules.
SlowPath transfers the first packet to the DPI engine to enforce security policies and categorize the traffic. For subsequent packets, which are offloaded to FastPath, FastPath transfers the packets to the DPI engine through direct packet delivery.
Packet transfer takes place through the DAQ (Data Acquisition) layer. After applying security policies, the DPI engine transfers the traffic back through the DAQ layer to SlowPath or FastPath, depending on the system that sends the packets.
The DAQ layer provides a direct path for the hardware to write packet buffers into the DPI engine address space, ensuring zero-copy buffers. It also provides I/O multiplexing and routing of shared packet buffers among the DPI engine components so that packets rapidly move in and out of the DPI engine.
The initial packets of a connection are delivered to the DPI engine for application identification. The engine classifies the application after approximately eight packets and gives a policy verdict for application control.
The verdict may also include new forwarding behavior, which is implemented on subsequent connections containing the identified application. The verdict may also include new QoS parameters, which are implemented on the current connection. The DAQ layer communicates these decisions to SlowPath.
IPS may pass a verdict to stop security processing based on factors, such as a safe signature or verdict from SophosLabs, earlier verdicts, or a matching IPS policy with a bypass session rule attached. For files that need antivirus scanning, packets are shared with the antivirus module.
SSL/TLS inspection must be turned on to enforce inspection and decryption. For unencrypted traffic, the SSL/TLS module informs the DAQ layer that SSL/TLS processing isn't required for the flow.
For encrypted traffic, when the client (for example, a web browser) sends a request to the web server, the firewall implements the SSL/TLS inspection rule criteria for matching traffic, for example, the ciphers and TLS versions the traffic is allowed to use.
When the server responds with its X.509 certificate, SFOS performs the TLS handshake with the server and re-signs the server certificate. For flows that meet the PKI acceleration requirements, certificate re-signing is offloaded to crypto hardware on the NPU. For unsupported flows, the DPI engine re-signs the certificate.
The modifications apply throughout the connection lifetime to ensure the connection isn't dropped because of the modification.
After the certificate is verified, the DPI engine decrypts the application traffic, and the other modules inspect the traffic. Subsequently, the DPI engine encrypts the application traffic and forwards it to the client.
The DPI engine applies the web policy and allows or blocks web traffic based on the scanning results and the web category, URL group, file type, and user activity specified in the web policy. When the DPI engine is selected in the firewall rule, the engine performs web content filtering over standard and non-standard ports. When web filtering applies to the traffic, web traffic scanning continues until the end of the flow, depending on the returned HTTP responses. The packets are transferred to the antivirus module for scanning.
The traffic is then offloaded to FastPath. Traffic may not be fully offloaded because of SSL/TLS inspection and web filtering. Fully offloaded traffic attains cut-off from SlowPath.
With SSL/TLS inspection, SFOS processes asymmetric crypto operations of the Public-Key Infrastructure (PKI). When the server responds to a client request with the X.509 server certificate, the DPI engine verifies the certificate.
For TLS flows supported by PKI acceleration, certificate re-signing is offloaded to the NPU. The DPI engine sends a request to the NPU through the DPDK (Data Plane Development Kit) in the DAQ layer for re-signing the server certificate. Offloading the CPU-intensive PKI processing frees the x86 CPU for other processes. After the crypto hardware engine on the NPU re-signs the certificate, the result is sent back to the DPI engine through the DPDK-DAQ for TLS processing.
The DPI engine re-signs the certificate for TLS flows that aren't supported by PKI acceleration.
SlowPath offloads SAs for the encryption and authentication combinations available on the firewall, with some exceptions to FastPath. So, the decryption keys and other SA parameters for offloaded SAs are sent to the NPU before any packets arrive in the VPN tunnel.
Packets first arrive on the NPU. For ESP packets, the NPU looks up the SPI (Security Parameter Index) and verifies the following:
If the packet meets these conditions, the crypto hardware on the NPU decrypts the packet and examines the inner packet. It marks the first packet in a new connection to send to the XFRM stack, then delivers this inner packet to SlowPath. The XFRM stack sends the packet to SlowPath for further processing from DoS and spoof protection to routing. If SlowPath decides to offload (firewall acceleration) the inner flow, it instructs the NPU. Subsequent packets arriving in this tunnel are then retained on FastPath for offloaded processing.
If the packet doesn't meet the above three conditions, SlowPath transfers valid IPsec VPN traffic to the XFRM stack. After the XFRM stack decrypts the packet based on the SPI, it sends the inner packet to SlowPath for further processing.
After SNAT processing, SlowPath makes the decision to offload encryption and encapsulation to the NPU if the SAs qualify for offloading. QoS processing takes place, and the traffic is offloaded to FastPath. After encryption and encapsulation on the NPU, the packets exit the firewall through the egress interface.
IPsec VPN traffic can qualify for one of the following offload processes based on whether firewall and IPsec acceleration are turned on or off and whether the traffic qualifies for offloading:
Full offload: For offloaded SAs, the NPU encapsulates, encrypts, decapsulates, and decrypts the corresponding IPsec VPN packets. Additionally, if the inner traffic qualifies, SlowPath processing is offloaded to FastPath, delivering full offload.
FastPath and SlowPath: For offloaded SAs, the NPU decrypts or encrypts the IPsec VPN packets. If the inner traffic doesn't qualify for FastPath offloading, SlowPath performs the processing, including encapsulation and decapsulation. FastPath finalizes the encapsulation after encrypting the packet.
Full SlowPath: For SAs that aren't offloaded, SlowPath performs the entire packet processing.
Firewall and IPsec acceleration
IPsec acceleration: On
IPsec acceleration: Off
Firewall acceleration: On
Offloaded SAs: FastPath performs decryption and encryption of packets.
Additionally, firewall acceleration takes place if the inner traffic qualifies for FastPath offloading.
SAs not offloaded: SlowPath performs decryption, firewall stack processing, and encryption.
Firewall acceleration takes place if the inner traffic qualifies for FastPath offloading.
IPsec traffic: SlowPath performs decryption, firewall stack processing, and encryption.
Non-IPsec traffic: Firewall acceleration takes place for connections offloaded to FastPath.
Firewall acceleration: Off
Offloaded SAs: The NPU decrypts incoming ESP packets. Decrypted packets are sent to SlowPath for firewall stack processing.
SlowPath encapsulates outgoing packets. The NPU encrypts the ESP packets.
SlowPath processes the traffic.
SlowPath processes all traffic.
Firewall, PKI, and IPsec acceleration turned on.
The data plane offloads some or all packet processing in a connection to FastPath on the NPU from the x86 general-purpose CPUs. Offloading takes place throughout the connection's lifetime. FastPath supports programmable network processors that can carry out data plane operations at a line rate. It statefully tracks individual connections, processing the packets fully without consuming PCIe bandwidth, x86 CPU cycles, and memory bandwidth.
For security processing, packets are handed over to the DPI engine by the CPU using the Netmap SlowPath component in the DAQ layer. The NPU hands over offloaded packets from FastPath directly to the DPI engine through the DPDK (Data Plane Development Kit) in the DAQ layer, offering an efficient, zero-copy path into the DPI engine's buffers and eliminating the need to retain copies in kernel memory.
PKI and IPsec accelerations lighten the load on the CPU further. Offloading lightens the load on the CPU and accelerates security processing.
To implement offloading, see Offloading based on rules and policies.
Hi, thank you for that very detailed data process handling document.
i set mail to be processed by the dpi engine but does not seem to have made any improvements in handling the messages.
I do have one question about the data flow mail message handling both incoming and outgoing appears to be missing? Mail messages hit the proxy processing box but do not appear to go anywhere afterwards.
XG115W - v19.5 GA - Home
Test machine - Asus P10S-i E3-1225v5, 6gb, 4 intel NICs, v19.5 GA
If a post solves your question please use the 'Verify Answer' button.
Thank you for your kind words, the team has been working hard to get this published.
For your question/comment regarding the DPI engine and data flow - could you please raise this as a separate Community thread and @ me on it so that I can help follow up?