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 come with Virtual FastPath that runs on the host x86 CPU when traffic is offloaded with firewall acceleration.
XGS Series appliances are based on Xstream architecture, which is a dual-processor architecture. This combines a multi-core x86 CPU with a dedicated Xstream Flow Processor, which is a Network Processing Unit (NPU). It runs as a dedicated co-processor when traffic is offloaded, freeing the host CPU for resource-intensive processes. XGS Series appliances are available from 18.5 and later versions. These appliances offer firewall acceleration on 18.5 versions.
IPsec acceleration is available on XGS Series appliances on 19.0 and later versions.
This article describes the processing and offloading mechanisms on XGS Series appliances.
SFOS delivers high-speed processing using the following offloading mechanism:
The policies and settings you configure determine SlowPath processing and the DPI engine's security policy enforcement.
You can use the advanced protection settings and security policies, including SSL/TLS inspection, IPS, web filtering, application control, and full antivirus scanning for traffic that requires the complete protection Sophos Firewall offers.
XGS Series appliances have a dual-processor architecture, which combines a multi-core x86 CPU with a dedicated Xstream Flow Processor for hardware acceleration. 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 TLS inspection and deep packet inspection.
These appliances deliver firewall and IPsec acceleration in 19.0 and later versions. 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. This enables the XGS Series appliances to deliver higher processing efficiencies.
The XG Series appliances offload trusted traffic to FastPath on the same x86 CPU and deliver only firewall acceleration.
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 and IPsec acceleration by offloading trusted traffic to FastPath. Both types of acceleration are turned on by default.
If the firewall rule’s security policies don’t apply to a flow, SlowPath can make the decision to offload the flow to FastPath. If security policies apply, requiring DPI engine processing, SlowPath instructs FastPath to deliver subsequent packets to the DPI engine through direct packet delivery. After the DPI engine processes the packets, if it decides to offload the flow based on application processing or a safe verdict from Sophos Labs, it instructs FastPath to cut-off the flow from SlowPath, and then full firewall acceleration takes place.
The firewall offloads CPU-intensive processes, such as ESP encapsulation, encryption, decapsulation, and decryption, to the NPU, freeing up the x86 host CPU. This is made possible by the NPU's hardware crypto capabilities. Additionally, IPsec acceleration improves the throughput for IPsec VPN tunnels.
Criteria for offloading SAs
The firewall offloads IPsec encryption and decryption to FastPath 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 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 for offloading the SAs.
Active-passive HA: Additionally, if the inner traffic qualifies for FastPath offloading, firewall acceleration takes place only on the primary node.
Active-active HA: Firewall acceleration isn't available in active-active HA and processing takes place on the SlowPath.
Currently, the firewall places the following restrictions on offloading:
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 that the flow is 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.
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. Traffic related to DoS checks isn'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 also checks the domain names with the ATP database. If it finds the IP addresses or domain names in the database, it takes the action specified in the ATP module.
SlowPath looks up the following rules and parameters matching the traffic criteria:
SlowPath matches firewall rules based on the following traffic criteria:
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 they're 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, VPN route.
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 to FastPath, the incoming IPsec (ESP) packet is sent to SlowPath for decapsulation and decryption. SlowPath then transfers the packet to the XFRM stack, which is on SlowPath. 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 then goes through 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 then retained on FastPath and are 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 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 to FastPath. 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, the 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 traffic 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.
However, 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 to the anti-spam engine for spam check
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 (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.
If the domain name isn't configured in WAF, the engine shows an error page. 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 came 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
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 layer 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 sent 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 are moved in and out of the DPI engine rapidly.
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 that contain 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 to it. 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, the DPI engine modifies the traffic to perform man-in-the-middle inspection. The engine continues to modify traffic throughout the connection lifetime to ensure the connection isn't dropped because of the modification. After decryption, the other modules in the DPI engine perform security processing.
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 HTTP responses that are returned. 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.
Firewall acceleration turned on. IPsec acceleration turned off.
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 Xstream processor (the NPU) before any packets arrive in the VPN tunnel.
Packets first arrive at the Xstream processor on the FastPath. For ESP packets, the NPU looks up the SPI (Security Parameter Index) and verifies the following:
If the packet meets these conditions, FastPath decrypts the packet and examines the inner packet. It marks the first packet in a new connection to send it 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 FastPath if the SAs qualify for offloading. QoS processing takes place and then the traffic is offloaded to FastPath. After encryption and encapsulation on the NPU, the packets exit the firewall through the egress interface.
Highlighted the components of IPsec acceleration
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, FastPath 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, FastPath 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.
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.
IPsec traffic: SlowPath performs decryption, firewall stack processing, and encryption.
Non-IPsec traffic: Firewall acceleration takes place for connections offloaded to FastPath.
Offloaded SAs: FastPath decrypts incoming ESP packets. Decrypted packets are sent to SlowPath for firewall stack processing.
SlowPath encapsulates outgoing packets. FastPath encrypts the ESP packets.
Firewall and IPsec acceleration turned on
On the XGS Series appliances running SFOS 19.0 and later versions, traffic can be offloaded to FastPath for firewall and IPsec acceleration.
The first packet of every connection flows through SlowPath. After the complete handshake occurs or the first packet from each direction passes through SlowPath, SlowPath fully classifies the flow.
The data plane then offloads some or all processing of subsequent packets from the CPU to FastPath on the Xstream Flow Processor throughout the connection's lifetime. These packets don't require further processing to verify their identity and destination.
For security processing, packets are handed over to the DPI engine by the CPU using the Netmap SlowPath component in the DAQ layer. The Xstream Flow Processor, that is, the NPU, hands over offloaded packets from FastPath to the DPI engine through the DPDK (Data Plane Development Kit) in the DAQ layer. FastPath provides an efficient, zero-copy path into the DPI engine. The ability to deliver packets directly to the DPI engine's buffers eliminates the need to retain copies in the kernel memory.
The DPI engine processes approximately eight packets before it determines the traffic to be safe. After it passes a verdict that the traffic is safe, the data plane offloads some or all security processing of subsequent packets to FastPath, completing the offload process for the connection.Some or all processing of packets in the connection is offloaded to FastPath on the NPU from the x86 general-purpose CPUs. Offloading lightens the load on the x86 hardware. FastPath supports programmable network processors that can carry out the data plane operations at line rate.
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.
FastPath acts only based on these classification decisions. It implements the classification decisions taken by SlowPath and the DPI engine to subsequent packets in the connection.
For IPsec VPN tunnels, the XFRM stack on SlowPath makes the decision to offload SAs. For SAs that qualify for offloading, encryption and decryption are offloaded to FastPath in the NPU, freeing up CPU space. The decrypted traffic can also qualify for FastPath offloading.
FastPath statefully tracks individual connections, processing the packets fully without consuming PCIe bandwidth, x86 CPU cycles, and memory bandwidth. The offload lightens the load on the hardware and accelerates security processing.
To implement FastPath processing, 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?
Hi,thank you for that very detailes .
if you have scan email enabled, DPI does not work with imaps scanning in the current version.
Could you include IPv6 frames in this documentation?
Hi na karu,We'll soon update our Life of a packet Recommend Read to include information related to SF 19.5 (that will be released before the end of the year).We haven't included any information about IPv6 yet but we've got your request and will work on amending the document as soon as possible.