# How Security Engines examine traffic

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

Engines, Master Engines, Virtual Engines, and Layer 2 Engines 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 Security Engine itself opens, and the management connections that the Security Engine is intended to receive.

On Engine 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.

Security 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 Engine 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 Security 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 Engines can be installed either in inline mode or in capture mode.

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

- FW — Engine/VPN role
- IPS — IPS role and layer 2 physical interfaces of the inline IPS interface type on Security Engines in the Engine/VPN role
- L2FW — Layer 2 Engine role and layer 2 physical interfaces of the inline Layer 2 Engine interface type on Security Engines in the Engine/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 Security 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 Security Engine checks the validity of packets to protect the Security Engine from processing invalid packets. Depending on the action in the Inspection Policy, Security Engines in the IPS and Layer 2 Engine roles can either terminate invalid packets or bypass the traffic without processing the invalid packets. For self-protection reasons, Security Engines in the Engine/VPN role 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 Security 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 re-matched according to the number and type of layers in the tunnel and the settings of the Security Engine. The processing of the packet continues until the packet matches a rule that tells the Security Engine to allow or discard the packet. If the packet does not match any Access rule, the final action depends on the Security Engine role. An IPS engine allows the packet to pass through, while a Layer 2 Engine 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 Security 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 Security 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 Security Engine deep packet inspection. For traffic from a server to a client, Security 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 Tunnels | 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 Tunnels configuration.
12 | QoS | ALL | QoS Processing |  | The packet is let through the Security Engine according to its priority and any bandwidth limits or guarantees that might have been defined.
13 | PACKET OUT | ALL | Outgoing packet |