Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
Table of Contents
- Introduction
- Xstream architecture
- Types of acceleration
- Firewall acceleration
- User space modules
- DPI engine
- PKI acceleration
- IPsec acceleration
- Firewall and IPsec acceleration
- Benefits of Offloading
Introduction
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.
Sophos Firewall 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.
Sophos Firewall is 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:
Summary of offloading for SFOS versions and appliances
|
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) |
No |
No |
No |
|
IPsec acceleration |
XGS Series |
XGS Series |
No
|
No |
|
Firewall acceleration |
XGS and XG Series |
XGS and XG Series |
XGS and XG Series |
XG Series |
This article describes the processing and offloading mechanisms on Sophos Firewall that support these types of acceleration.
Benefits of offloading
SFOS delivers high-speed processing using the following offloading mechanisms:
- SlowPath offloads some or all processing to FastPath, minimizing CPU load and packet latency and maximizing packet throughput.
- The NPU uses zero-copy to send packets directly to the deep packet inspection engine, saving host CPU cycles for SlowPath processing.
- Additionally, Xstream architecture enables XGS Series firewalls to offload PKI processing on certain appliances and IPsec encryption and decryption, freeing up resources on the host CPU.
The policies and settings you configure determine the enforcement of SlowPath processing and the DPI engine's security policy.
Xstream architecture
Sophos Firewall appliances are based on Xstream architecture, a dual-processor architecture combining a multi-core x86 CPU and 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.
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 models perform PKI acceleration for inspected TLS flows. This enables the delivery of higher processing efficiencies.
Modules
The data plane uses both hardware and software components, delivering high levels of processing efficiency. It contains the following domains and processes:
x86 CPU
- SlowPath
- Firewall stack (kernel).
- User space modules: DPI engine, proxy applications, WAF, malware scanning, anti-spam, and SSL VPN engine.
- Offload module: Determines the trusted flows to offload intelligently for firewall acceleration.
- XFRM stack offloads qualifying flows for IPsec acceleration.
- DPI engine offloads inspected TLS flows for PKI acceleration.
NPU
- FastPath
- Firewall acceleration.
- PKI acceleration for TLS traffic inspected by the DPI engine.
- IPsec acceleration.
Types of acceleration
SFOS accelerates firewall, PKI, and IPsec 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.
Firewall acceleration
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 decide 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.
Support for firewall acceleration
The following restrictions apply to firewall acceleration:
- Doesn't support offloading for SSL VPN, proxies, WAF, QoS, DoS, wireless, RED, LAG, and PPPoE traffic.
- Doesn't offload IP fragmented traffic.
- Supports offloading only for some types of bridge deployments.
- Doesn't support firewall acceleration in active-active HA. Supports firewall acceleration in active-passive HA on the primary node.
- Optionally, offloading can remain on when tcpdump is run. FastPath traffic can be configured to be sent to tcpdump for SFOS 18.5 MR2 and later.
PKI acceleration
The firewall offloads PKI processing (re-signing the X.509 server certificates) for TLS flows that meet all the following requirements:
- The DPI engine inspects TLS flows.
- TLS 1.2 and 1.3 flows.
- Flows that use RSA authentication with key sizes up to 4096 bits.
The firewall doesn't offload symmetric crypto operations for inspected SSL/TLS flows.
Support for PKI acceleration
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.
IPsec acceleration
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:
- 3DES
- BlowFish
- MD5
We recommend using the AES-GCM 128 cipher for the best performance.
HA behavior
IPsec acceleration occurs 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 decides to offload the SAs.
Support for IPsec acceleration
The following restrictions apply to the firewall:
- Doesn't support IPsec acceleration over VLAN and wireless interfaces.
- Supports IPsec acceleration in active-active HA on the primary node. Firewall acceleration isn't available in active-active HA, and processing of the inner packets takes place on SlowPath.
- Supports firewall and IPsec acceleration in active-passive HA on the primary node. If the inner traffic qualifies for FastPath offloading, firewall acceleration occurs on the primary node.
Firewall acceleration
A summary of how SlowPath processes the first packet in the ingress and egress stages is as follows:
Ingress stage: SlowPath performs a stateful inspection on the initial packet of a connection. It does the following during the ingress stage:
SlowPath decisions
- Applies DoS (Denial of Service) policies.
- Applies the firewall rule action.
- Applies DNAT rules.
- Makes layer 2 and layer 3 decisions that include routing, switching, forwarding, and RED traffic-related decisions.
- Makes decisions related to ingress decapsulation and decryption, including decisions for IPsec VPNs (if IPsec acceleration is turned off).
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:
- Applies source NAT (SNAT) rules.
- Applies QoS (traffic shaping) policies.
- Makes decisions related to egress encryption and encapsulation for IPsec VPNs (if IPsec acceleration is turned off).
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 manages 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:
Ingress stage
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:
RED traffic
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.
Advanced protection
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.
Lookups
SlowPath looks up the following rules and parameters matching the traffic criteria:
- Destination NAT rule: For incoming traffic, SlowPath looks up the destination NAT rule matching the packet's original source, destination, and service and the inbound and outbound interfaces. It tags the packet with the DNAT rule ID. Address translation is done later in the processing. The translated destination's zone is identified as the destination zone for firewall rule lookup and processing. For example, if the translated destination IP address of the web server belongs to the DMZ, SlowPath tags the packet with DMZ as the destination zone.
- SD-WAN route: SD-WAN routes are matched with users and applications in addition to the 5-tuple criteria. SlowPath obtains the first connection's source and destination IP addresses, service, inbound interface, and user ID. The destination IP address is the translated destination IP address in the DNAT lookup.
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.
- Security Heartbeat: If Synchronized Security is turned on, the Security Heartbeat engine shares the endpoint's Heartbeat status (health status) and the source IP address.
- Users: SlowPath looks up the user ID associated with the source IP address of the packet. It also determines the groups to which the user belongs.
Firewall rule lookup and processing
SlowPath matches firewall rules based on the following traffic criteria:
|
Type |
Lookup criteria |
|
Network criteria |
· Source port and IP address · Source zones · Destination port and IP address · Destination zones · Services |
|
User identity |
· Users (based on the source IP address) · Groups · Unknown users |
|
Heartbeat status |
· Red · Green · Yellow · Missing |
If no 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.
Routing processing
The default routing precedence in Sophos Firewall is the static route, SD-WAN route, and VPN route.
- Static routes: If the default precedence is retained, SlowPath first applies static routes. These refer to directly connected networks, dynamic routing protocols, unicast routes, and SSL VPN connections.
- SD-WAN routes: If a static route doesn't match the traffic, SlowPath implements the SD-WAN route identified earlier in the process and routes traffic through the gateway specified in the route. Based on the specified settings, it performs failover between the primary and backup gateways with fallback to the default WAN link manager load balancing.
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.
- VPN routes: If traffic doesn't match the above two routes, SlowPath matches VPN routes. These apply to IPsec traffic, which must be decapsulated and decrypted.
- Default route (WAN link load balance): If traffic doesn't match any of these routes, SlowPath applies the default route, WAN link load balancing, among the gateways listed in the WAN link manager.
IPsec VPN
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.
Egress stage
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:
- Source NAT
- IPsec VPN
- QoS (Quality of service)
Source NAT
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.
IPsec VPN
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, 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.
QoS
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 the Sophos Firewall through the egress interface. QoS isn't offloaded to FastPath.
A classification decision is made after a complete handshake or the first packet of every connection flows through SlowPath. Traffic that doesn't require DPI engine processing and meets all other criteria for FastPath eligibility is offloaded to FastPath.
User space modules
The user space contains the following modules:
- Proxy applications and WAF
- Malware scanning
- Anti-spam
- SSL VPN
- DPI engine
Proxy applications and WAF
This component contains the web proxy, FTP, email, and WAF engines.
Web proxy
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 occurs in the antivirus engine in real-time or batch mode based on the scanning settings configured in the web module. Web content filtering over non-standard ports occurs in the DPI engine even when web proxy is selected.
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.
FTP protection
Protection for file transfers takes place here. You set the FTP scanning settings in the firewall rule.
Email Protection
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 responds to the client (for example, a 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.
Malware scanning
This component contains antivirus scanning and zero-day protection.
Antivirus
Antivirus scanning occurs for web, FTP, email, and WAF traffic. Sophos Firewall performs streaming antivirus scanning. If the DPI engine verifies that the traffic is safe, antivirus scanning doesn't take place for traffic flowing through the DPI engine.
Zero-day protection
Files are sent for detonation to 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.
Anti-spam
Packets are sent to the anti-spam module for spam scanning based on the settings in the SMTP policies.
SSL VPN
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.
OpenVPN decrypts the packet for incoming SSL VPN traffic and sends it to SlowPath using the TUN interface. Decrypted packets then go through the regular SlowPath processing.
SlowPath routes packets to the Tun0 interface for outgoing SSL VPN traffic 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.
DPI engine
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:
- SSL/TLS inspection
- Application identification and control
- Intrusion prevention
- Web filtering with the DPI engine
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 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.
Application identification and control
The initial connection packets 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 implemented on the current connection. The DAQ layer communicates these decisions to SlowPath.
Intrusion prevention
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. Packets are shared with the antivirus module for files that need antivirus scanning.
SSL/TLS inspection
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 can 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 verifying the certificate, 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.
Web filtering with DPI engine
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.
PKI acceleration
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 requests 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.
IPsec acceleration
Ingress stage
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:
- The packet has an offloaded SA.
- The packet's source and destination IP addresses match those expected for the SA.
- The packet has a valid ESP sequence field. Replayed packets are considered invalid.
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.
Egress stage
After SNAT processing, SlowPath will 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.
Firewall and 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, the NPU encapsulates, encrypts, decapsulates, and decrypts the corresponding IPsec VPN packets. 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 |
IPsec traffic: Offloaded SAs: FastPath performs decryption and encryption of packets. Additionally, firewall acceleration occurs if the inner traffic qualifies for FastPath offloading. SAs not offloaded: SlowPath performs decryption, firewall stack processing, and encryption. Non-IPsec traffic: 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 |
IPsec traffic: 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. Non-IPsec traffic: SlowPath processes the traffic. |
SlowPath processes all traffic. |
Firewall, PKI, and IPsec acceleration turned on.
Benefits of offloading
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, the CPU hands packets to the DPI engine 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.
Added TAGs
[edited by: Raphael Alganes at 5:29 AM (GMT -7) on 18 Sep 2024]
