Packet filters consider only the most basic attributes of each packet, and they don't need to remember anything about the traffic since each packet is examined in isolation. For this reason they can decide packet flow very quickly.

Because every packet of every connection is checked against the access control rules, larger, complex rule bases decrease performance. And because packet filters can only check low-level attributes, they are not secure against malicious code hiding in the other layers. Packet filters are often used as a first defense in combination with other firewall technologies, and their most common implementation today is seen in the access control lists of routers at the perimeters of networks.

Stateful inspection firewalls are 'connection-aware'. They understand that a single connection between two computers generally consists of many packets, and that they only need to compare the first packets of a given connection against the defined security policies. Once a connection has been established, it is recorded in a table. This table is checked for each packet that arrives at the firewall and if the packet belongs to an existing connection it is allowed to pass. Since the security policy is only consulted once for each connection, complex security policies don't greatly impact performance.

Although stateful inspection firewalls have improved scalability over simple packet filters, they still have several disadvantages. They still provide no application level security. The upper layers are not examined, and malicious code hiding there can still pass undetected. Stateful inspection systems also inspect, record and monitor state tables for every connection protocol, whether it makes sense to do so or not. For simple protocols where there is no connection (e.g., ICMP or UDP), packet filters are more appropriate.

Protocol agents are a flexible, configurable, and extensible component of the StoneGate security gateways. When application-level security is required by the administrator, protocol agents can be assigned to perform the additional scrutiny required. They also assist the firewall with handling complex connections, such as Oracle® or FTP, redirection of traffic to content inspection systems (e.g., anti-virus servers), enforcing protocol standards, and modifying the data payload if necessary.

One of the most useful security benefits of protocol agents is the ability to enforce protocol standards. For example, many traditional firewalls can allow SSH connections to pass through the firewall. But because SSH creates encrypted connections, many proxies or stateful inspection firewalls simply examine the destination port to determine that the connection is SSH. Since it is an encrypted connection, it is assumed that there is little else to be done. In other words, an intruder can get malicious code or packets through the firewall by disguising them as an SSH connection. With StoneGate, the SSH protocol agent is called upon at the beginning of the connection. The protocol agent in this case assists the firewall by examining the first few packets and ensuring that they conform to the SSH standard in other words, that the connection is really SSH, and not something else. Unlike proxies, the protocol agent can be ended once the encryption starts, freeing resources on the firewall gateway for other packet handling operations.

Another ability of protocol agents is the ability to redirect traffic to content inspection systems. Content inspection systems are commonly used to provide anti-virus protection or Web address filtering. They are designed to prevent attacks against servers using malicious content that is syntactically correct from a protocol perspective, yet from the perspective of the applications, semantically dangerous. In StoneGate, protocol agents can be configured at the rule level to redirect traffic to such an inspection system for further analysis; the administrator can choose to only have this redirection take place when it is necessary to do so.

In addition to inspecting the protocol in more detail than traditional systems provide, and adding the ability to redirect traffic to content inspection systems for further analysis, multi-layer inspection also provides the ability to modify application data through protocol agents. Complex protocols, such as H.323, which is used by voice over IP applications (e.g., Microsoft® NetMeeting®), do not pass through packet filters or stateful inspection firewalls when the IP addresses are translated using network address translation (NAT). Such protocols often contain address information about associated voice gateways and call endpoints within the data of the packet data which is not translated by firewalls because they are not designed to do so. With StoneGate's multi-layer inspection, protocol agents can examine and modify such application data yet, because the system does not establish two separate connections, the performance and translation problems associated with application proxies do not affect the firewall.

Other complex protocols which require multiple yet related connections, such as Oracle® database connections or even FTP, are also handled more efficiently with multi-layer inspection. Protocol agents monitor connections for these protocols, and can instruct the firewall to allow related connections. With such assistance, the firewall does not need to perform additional checks against the security policy, and all connections required for the protocol are handled without the firewall inadvertently rejecting them.