How NGFW Engines examine traffic
NGFW Engines check the validity of packets, then process only the valid packets.
Firewalls, Master NGFW 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 NGFW Engine itself opens, and the management connections that the NGFW Engine is intended to receive.
On Firewall Clusters and clustered Master NGFW 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.
NGFW 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 NGFW 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 NGFW 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 NGFW 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 NGFW Engines in the Firewall/VPN role
Some stages apply to all roles.
Stage | Role | Event / Check | Action | Notes | |
---|---|---|---|---|---|
1 | PACKET IN | ALL | Incoming packet | ||
2 | Ethernet rules | IPS, L2FW | Allowed? | Packet dropped | The NGFW 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 NGFW Engine checks the validity of packets to protect the NGFW Engine from processing invalid packets. Depending on the action in the Inspection Policy, NGFW 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, NGFW 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 NGFW 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.
|
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 NGFW 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 or file filtering in the Access rules.
|
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 NGFW Engine according to its priority and any bandwidth limits or guarantees that might have been defined. | |
13 | PACKET OUT | ALL | Outgoing packet |