PAN-OS, Cisco FTD and FortiGate: how zones, NAT and HA differ

Every next-generation firewall answers the same questions: where did the traffic come from, which rule applies, what address does the rule see after NAT, what application is it, and what happens when a box fails. The vendors answer them in different words and sometimes in a different order. These are my notes on five of those questions, each checked against the vendor's own documentation.

1. Zones and interfaces

• PAN-OS. An interface must be assigned to a security zone before it can process traffic, and an interface belongs to only one zone. Security policy rules reference source and destination zones, not interfaces (Security Zone Overview).
• Cisco Secure Firewall Threat Defense (FTD). Each interface can go into a security zone, an interface group, or both. An interface can be in only one security zone. Interface groups work in NAT, prefilter and QoS policies, and Cisco recommends defaulting to security zones because every feature supports them (Security zones and interface groups).
• FortiGate. A firewall policy names an incoming and an outgoing interface (Firewall policy). Zones are optional: they group interfaces so several segments can share one policy, and they don't change routing. A zone's intrazone setting decides whether its members can talk to each other without a policy (Zone).
• Huawei USG. Policy is also built on security zones, and interfaces are added to them. There is a Local zone for the firewall itself; Huawei's hot standby FAQ, for example, discusses whether policy must permit packets between the Local zone and the heartbeat interface's zone (FAQ About Hot Standby).

So on PAN-OS and FTD the zone is the normal unit of policy, while on FortiGate the interface is, with zones as a convenience.

2. Policy evaluation order

All three main vendors use top-down, first match, so specific rules go above general ones.

• PAN-OS evaluates security rules from top to bottom and uses the first rule that matches. The predefined default rules at the bottom allow intrazone traffic and deny interzone traffic. They are read-only by default, but you can override a few of their settings, such as the action, tags, logging and security profiles (Security Policy).
• FTD numbers access control rules from 1 and matches them in ascending order. The one exception is Monitor rules: after traffic matches one, evaluation continues to the rules below (Access control rule order).
• FortiGate checks policies in the order shown in the By Sequence view. Traffic that matches no policy is denied (Firewall policy).

3. NAT and how it meets the security policy

This is where most "why doesn't my rule match" questions come from.

• PAN-OS evaluates NAT rules top-down, and a packet matches only one NAT rule. Security rules then match the pre-NAT addresses but the post-NAT zones (NAT Policy Overview).
• FTD keeps NAT in its own policy, in one table with three sections: manual NAT first, then auto NAT (ordered by the system), then manual NAT placed after auto NAT. A Section 0 holds rules the system creates for itself. Once a rule matches, later sections are not checked (NAT rule order).
• FortiGate can do source NAT inside each firewall policy, or in a separate Central SNAT table. Central NAT is off by default. When it is on, the NAT option in policies is skipped, the table is read top-down, and NAT is applied after the security policy. In policy-based NGFW mode, central SNAT is assumed to be on (Central SNAT).

4. Application identification

• PAN-OS App-ID identifies an application regardless of port, protocol or encryption, using signatures, protocol decoders and, for evasive applications, heuristics. If the traffic is decrypted, the signatures run again on the decrypted flow (App-ID Overview).
• FTD uses application conditions in access control rules, backed by application detectors that Cisco updates through system and vulnerability database (VDB) updates (Application rule conditions). The inspection engine is Snort, which runs on the threat defense device (Snort 3). Identification should take 3 to 5 packets, or, for encrypted traffic, until after the server certificate exchange in the SSL handshake. Until then the system lets packets pass and the connection be set up, then applies the rule's action to the rest of the session (Recommendations for application control).
• FortiGate application control uses IPS protocol decoders and can detect applications on non-standard ports. An application sensor is added to a firewall policy, and the feature needs a FortiGuard Application Control subscription (Application control). Sensor actions are monitor, allow, block or quarantine (Configuring an application sensor). In policy-based NGFW mode, applications go directly into the security policy instead (config firewall security-policy).

The common point: the application is rarely known from the first packet, because a TCP handshake carries no application data. So some traffic passes before the application is known, and the decision is made again once it is.

5. High availability

• PAN-OS offers active/passive (virtual wire, Layer 2 and Layer 3) and active/active (virtual wire and Layer 3 only). Active/active does not load-balance traffic by itself; that needs ECMP, multiple ISPs or load balancers (HA Modes).
• FTD high availability is Active/Standby failover: one unit passes traffic, the two are joined by a failover link and optionally a state link, and they synchronize configuration and state (Threat Defense high availability). Clustering is a separate feature.
• FortiGate uses the FortiGate Clustering Protocol (FGCP). Members must be the same model with the same firmware (FGCP). Clusters run active-passive or active-active, and FGCP changes the interfaces' MAC addresses when the cluster forms.
• Huawei USG calls it hot standby, with HRP heartbeats and VRRP virtual addresses, in active/standby or load-balancing networking (FAQ About Hot Standby).

What I take from this

When I move between platforms, I translate the questions, not the configuration lines. Which object does policy use, zone or interface? Which rule wins? Which address does the rule see after NAT? When is the application known? Each vendor answers these clearly, but only in its own documentation and for its own version, so that is where I check before I change a rule.