How Engines examine traffic

Engines check the validity of packets, then process only the valid packets.

Firewalls, Master Engines, Virtual Firewalls, and Layer 2 Firewalls pass through only traffic that is explicitly allowed in the policy. All other traffic is discarded. IPS engines allow packets to pass if the engine’s policy does not apply a more specific action. All connections are handled in the same way, including connections that the Engine itself opens, and the management connections that the Engine is intended to receive.

On Firewall Clusters and clustered Master Engines, the load-balancing filter first determines which node in the cluster actually processes the received packet. The processing then begins on the selected node.

Engines check new connections against the policy, rule by rule. The header on each packet arriving on an interface is examined for the source and destination IP address, and protocol-related information, such as the port. The authentication status of the user attempting a connection and the current date and time can also be included as parameters in the examination process.

An IPS engine or Layer 2 Firewall matches traffic to different protocols and then checks the definitions for known vulnerabilities and other threats for that protocol. The protocol is assigned first, before the deep inspection. An Engine in inline mode can also filter traffic based on protocols, IP addresses, and the interface that received the traffic without analyzing the traffic for threat patterns. IPS engines and Layer 2 Firewalls can be installed either in inline mode or in capture mode.

The following table describes the packet processing flow for Engines. The following abbreviations are used for the roles and interface types:

FW — Firewall/VPN role
IPS — IPS role and layer 2 physical interfaces of the inline IPS interface type on Engines in the Firewall/VPN role
L2FW — Layer 2 Firewall role and layer 2 physical interfaces of the inline Layer 2 Firewall interface type on Engines in the Firewall/VPN role

Some stages apply to all roles.

Table 1. Packet processing
	Stage	Role	Event / Check	Action	Notes
1	PACKET IN	ALL	Incoming packet
2	Ethernet rules	IPS, L2FW	Allowed?	Packet dropped	The Engine checks Ethernet frames against the Ethernet rules in the policy. The packet is processed until it matches an Ethernet rule that tells whether to allow or to discard the packet.
3	Packet validity checks	ALL	Valid packet?	Packet dropped	The Engine checks the validity of packets to protect the Engine from processing invalid packets. Depending on the action in the Inspection Policy, Engines in the IPS and Layer 2 Firewall roles can either terminate invalid packets or bypass the traffic without processing the invalid packets. For self-protection reasons, Engine Engines in the Firewall/VPN role always terminate invalid packets without establishing a connection. Packets dropped in this phase produce log entries with specific situations, such as TCP_Segment-SYN-No-Options. Not all invalid packet drops are logged unless Packet Filter diagnostics is enabled. Note: Invalid Packet Situations are always log rate limited.
4	Antispoofing	FW	Spoofed?	Packet dropped	Checks that the traffic is coming in through the correct interface or VPN tunnel as defined in the routing and antispoofing configuration or VPN configuration.
5	Connection tracking	ALL	Existing connection or new related connection?	Access rule matching	Checks the current connection tracking information to see if the packet is part of an established connection (for example, a reply packet to a request that has been allowed). If TCP SYN rate limits or other DoS protection features are enabled, they are enforced at this stage. If the packet is not part of an existing connection, the packet is compared with the Access rules in the installed policy. The processing continues until the packet matches a rule that tells the Engine to allow or stop the packet. If there is no rule match anywhere else in the policy, the packet is allowed or discarded according to the final action of the policy.
6	Access rule matching	ALL	Allowed by Access rules?	Packet dropped	If the packet is not part of an existing connection, the packet is matched to IPv4 or IPv6 Access rules according to the IP protocol used. If the traffic is tunneled using IP-in-IP or Generic Routing Encapsulation (GRE), the traffic can be checked against the IPv4 or IPv6 Access rules several times. The traffic is rematched according to the number and type of layers in the tunnel and the settings of the Engine. The processing of the packet continues until the packet matches a rule that tells the Engine to allow or discard the packet. If the packet does not match any Access rule, the final action depends on the Engine role. An IPS engine allows the packet to pass through, while a Layer 2 Firewall drops the packet.
7	Protocol Validation	ALL	Valid for connection state?	Packet dropped	If the packet is allowed as an existing connection or in an Access rule, checks that the packet is valid for the state of the connection. If not, the packet is dropped. For example, a TCP connection must always begin with a SYN packet (as defined in the protocol standards). The Engine checks that the first packet of a new connection is a valid SYN packet.
8	Inspection and File Filtering Rules	ALL	Harmful pattern or file?	Action defined for rule	Applies Inspection rules to connections that are selected for deep packet inspection, Snort inspection, or file filtering in the Access rules. Inspection applies to all packets in a connection, so the Inspection rules are applied even if the packet is a part of an existing connection. If both Engine deep packet inspection and Snort inspection are enabled, the order in which inspection is applied depends on the direction of the traffic. For traffic from a client to a server, Snort inspection is applied before Engine deep packet inspection. For traffic from a server to a client, Engine deep packet inspection is applied before Snort inspection. The Inspection rules look for patterns of interest in allowed connections. The patterns can indicate potential attacks, exploits, or other possible threats. They can also be any other patterns of interest, such as multiple logon attempts, use of peer-to-peer or instant messaging software, or protocol violations in the traffic. If a pattern in traffic matches a pattern defined in a rule, the actions defined in the rule are taken.
9	NAT Modifications	FW	Address Translation (if needed for the connection)		Applies Network Address Translation (NAT) rules to IPv4 and IPv6 connections. The source and destination addresses are translated according to the first matching NAT rule (or not done at all, if a NAT rule so defines). If none of the NAT rules match, the packet continues with the original addresses. By default, NAT is not applied to traffic to or from policy-based VPNs.
10	VPN	FW	Policy-based VPN processing		Policy-based VPN processing includes finding the correct tunnel from the VPN configuration. If a VPN configuration does not match Access rules correctly, packets might be discarded with the message ”VPN tunnel selection failed”.
11	Routing / Route-based VPN	FW	Route Selection GRE/IP-IP encapsulated with policy-based VPN?	Go back to policy-based VPN processing	If a Zone is used as the Destination in an Access rule, the packet is matched against the Access rules after the final route has been selected. If the packet does not match a rule due to applied NAT, it is dropped. If the packet is routed to a tunnel interface, the packet is encapsulated according to the route-based VPN configuration.
12	QoS	ALL	QoS Processing		The packet is let through the Engine according to its priority and any bandwidth limits or guarantees that might have been defined.
13	PACKET OUT	ALL	Outgoing packet