Sophos XG Firewall is a next-generation firewall based on Xstream architecture.
The architecture is available from SFOS 18.0 and later versions.
XG Firewall processes traffic from layer 2 to layer 7 of the OSI model, securing the network, endpoints, as well as data in transit using advanced networking, application, and user controls.
Xstream architecture enables XG Firewall to 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 stack processing is stateless and applies in full on each packet, using more processing cycles than necessary. Offloading enables XG Firewall to minimize processing cycles. The following architecture and offloading mechanisms deliver high-speed processing:
The architecture uses the following mechanisms:
Offloading uses the following mechanisms to deliver processing efficiency:
The policies and settings you configure determine the firewall stack processing and the DPI engine’s security policy enforcement. You can configure policies to offload trusted packets at each level of protection.
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 XG Firewall offers.
Xstream architecture minimizes CPU usage by the firewall stack, maximizing CPU availability for deep packet inspection. It provides the hardware and software platform to offload packet processing throughout the connection's lifetime.
The data plane uses both hardware and software components, delivering high levels of processing efficiency. It contains the following domains:
Firewall stack: The firewall stack (kernel space) enforces layer 2 and layer 3 decisions in the ingress and egress stages.
DPI engine: The deep packet inspection engine located in the user space, applies layer 4 to layer 7 security policies.
Other user space modules: The user space runs applications and contains application software, programs, libraries, and processes. In XG Firewall, it contains the DPI engine, proxy applications and WAF, malware scanning, anti-spam, and SSL VPN engines.
FastPath: The data plane offloads trusted traffic to FastPath from the firewall stack and the DPI engine throughout a connection's lifetime.
Traffic flows in the stateful firewall mode initially. The processing flow for the firewall stack is SlowPath processing and is as follows:
Ingress stage: The firewall stack performs stateful inspection of the initial packet of a connection. It enforces DoS and spoof protection, threat protection, authentication, firewall and NAT rules, and implements VPN, bridging, routing, forwarding, and QoS decisions.
Transfer to the DPI engine: After the firewall stack processes the first ingress packet, it transfers the packet to the DPI engine. The DPI engine enforces security policy decisions and transfers the packet back to the firewall stack.
Egress stage: The firewall stack implements source NAT (SNAT), VPN, and QoS policies, and then the packet is forwarded to its destination.
Offload to FastPath: After processing one packet from both directions for a connection, the firewall stack caches the classification decisions it has taken. Subsequent packets in the connection are offloaded to FastPath.
After the offload, the firewall stack continues to manage the connection, requiring the CPU to handle the connection rate. If traffic can’t be offloaded for any reason, the firewall stack continues to process the packets in the connection.
After reassembling packets received on the SFOS interface, the firewall stack 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.
The firewall stack then implements the following processing in the ingress stage:
The firewall stack allows incoming packets from existing RED tunnels. These are connections from XG Firewall to a Remote Ethernet Device (RED) or site-to-site connections between two XG Firewall devices using a layer 2 tunnel.
RED devices connect remote offices through encrypted tunnels over the WAN zone. The XG 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 XG Firewall decrypts traffic from the remote office to the head office and transfers it to the firewall stack to implement firewall and NAT rules.
For outgoing traffic from the head office to the remote office, the firewall stack 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.
The firewall stack 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.
The firewall stack checks IP addresses based on the advanced threat protection (ATP) database. If XG Firewall is configured as the DNS server, the firewall stack 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.
The firewall stack looks up the following rules and parameters matching the traffic criteria:
The firewall stack matches a firewall rule 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. The firewall stack 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 the firewall stack processes the initial packet.
The default routing precedence in XG Firewall is static route, SD-WAN policy route, VPN route.
IPsec connections are used for site-to-site and remote access tunnels.
For incoming traffic that's encrypted, the firewall stack identifies the matching IPsec connection rule based on the source and destination IP addresses and the IP protocol field (ESP) in the outer header.
The firewall stack then transfers VPN traffic to the XFRM stack. The XFRM stack looks up the SPI (Security Parameter Index) value in the ESP header to match the encryption and authentication settings. It then identifies the IPsec policy associated with the SPI value.
The XFRM stack decrypts the packet based on the policy. It does a route lookup on the decapsulated packet and transfers the decrypted traffic back to the firewall stack. The packet then goes through the firewall stack processes from DoS and spoof protection to routing.
After the DPI engine enforces security policies, egress traffic is handed over to the firewall stack. The firewall stack then processes traffic exiting XG Firewall. The processing flow in the egress stage is as follows:
The firewall stack 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.
After routing, the firewall stack transfers packets egressing towards the VPN zone through IPsec0 (IPsec virtual interface) 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 policy. Based on the policy criteria, the XFRM stack encrypts and encapsulates the traffic. It then transfers the packet to the firewall stack for egress processing.
The firewall stack 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 XG Firewall through the egress interface.
After the first packet of every connection flows through the firewall stack, a classification decision is made. Traffic that doesn’t require DPI engine processing is offloaded to FastPath.
The user space contains the following modules:
The module details are as follows:
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.
The firewall stack 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 XG 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.
The firewall stack 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 and Sandstorm scanning.
Antivirus scanning takes place for web, FTP, email, and WAF traffic. XG 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 Sandstorm 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 Sandstorm analysis.
Packets are sent to the anti-spam module for spam scanning based on the settings in the SMTP policies.
XG 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. XG 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 the firewall stack using the TUN interface. Decrypted packets then go through the regular firewall stack processing.
For outgoing SSL VPN traffic, the firewall stack 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 the firewall stack 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 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.
The firewall stack 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.
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 the firewall stack 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 the firewall stack.
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 cutoff from the SlowPath.
The first packet of every connection flows through the firewall stack. After the first packet from each direction passes through the firewall stack, the firewall stack fully classifies the flow. The data plane then offloads some or all processing of subsequent packets from the CPU to FastPath throughout the connection's lifetime. These packets don't require further processing to verify their identity and destination.
For security processing, the initial packet from the firewall stack and the offloaded packets from FastPath are handed over to the DPI engine through 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.
On the offloaded packets, FastPath implements the classification decisions taken by the firewall stack and the DPI engine.
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.
Some or all processing of packets in the connection is offloaded to FastPath from the x86 general-purpose CPUs. Offloading lightens the load on the x86 hardware. FastPath applies the classification decisions to subsequent packets in the connection. FastPath supports programmable network processors that can carry out the data plane operations at line rate.
FastPath can statefully track 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 take advantage of wire speed FastPath processing, see How to use rules and policies to leverage FastPath.
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…
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.
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.