Policy & Segmentation

Why

How

The evaluation order, and why each stage happens where it does. Every packet first gets matched to a session (so the firewall is always reasoning about a session, not individual packets in isolation), and every session then gets matched against the rulebase. Authentication Policy, if configured, runs before Security Policy — the firewall has to know who's making the request before it can apply a rule that might depend on user identity. Once identity (if any) is settled, rules are checked top-to-bottom, and the very first rule that matches wins and stops evaluation entirely — nothing below it is even considered for that session. This single fact is what makes rule order just as important as rule content: a broad, permissive rule sitting above a narrow, restrictive one will silently swallow the traffic the narrow rule was written to catch, because evaluation never reaches the narrow rule at all.

The default rules at the very bottom — what they mean in practice. If nothing above matches, two implicit defaults apply: intrazone traffic (same zone to same zone) is allowed, interzone traffic (different zones) is denied. This reflects an assumption baked into the zone model itself — that everything inside one zone shares a similar trust level, so traffic between two hosts in the same zone is assumed benign by default, while traffic crossing a trust boundary is assumed risky until a rule says otherwise. The practical trap: if you lump hosts of genuinely different trust levels into one zone (say, servers and workstations both in "Trust"), that default intrazone-allow quietly permits traffic between them that you probably didn't intend to allow — the fix is finer-grained zone design, not just remembering the default exists.

Policy Optimizer — closing the loop on rule hygiene. Over time, rulebases built on ports/IPs accumulate rules nobody's sure are still needed, and broad "allow any app" rules hide what traffic is actually flowing. Policy Optimizer analyzes real traffic against existing rules and highlights which specific apps and ports are actually being used by a given rule, which lets you tighten a broad port-based rule into a precise App-ID-based one (or retire it entirely if nothing's actually using it) — without guessing.

Why

How

Source NAT — three flavors, each solving a different constraint:

• Static IP — a fixed one-to-one, bidirectional mapping with no port translation. Used when a host needs a consistent, predictable public identity — a server that partners connect to by a known address, where the public IP itself is effectively part of the service's identity.
• Dynamic IP — draws from a pool of public IPs, still one internal host per public IP per session (no port sharing). This solves "I have more internal hosts than one public IP can represent," but only up to the size of the pool — run more concurrent sessions than you have pool addresses, and new sessions fail until one frees up.
• Dynamic IP and Port (DIPP) — the same pool idea, but now also translates the source port, which is what actually solves the scaling problem: because a single public IP has roughly 64,000 possible source ports, many, many internal hosts can share just one or a few public IPs simultaneously, each session distinguished by its unique port rather than needing its own IP. This is why DIPP is the default choice for ordinary outbound internet access — it's the only one of the three designed to scale hosts-to-IPs at a large ratio.

Destination NAT — the inbound direction, for traffic reaching your own servers. A static mapping forwards one external IP/port to one specific internal host — a public-facing web server, say. A dynamic destination NAT mapping (with a translated port range) instead spreads incoming connections across several internal hosts, a one-to-many pattern useful for simple load distribution without a dedicated load balancer.

NAT is supported on Layer 3 and virtual-wire interfaces, and DIPP oversubscription pushes the port-sharing idea further still — multiplying how many source ports are available per translated IP so an even larger ratio of internal hosts can share the same small public IP pool, at the cost of exhausting that larger port pool faster under genuinely heavy concurrent load.

Why

How

These two features are easy to conflate because they sound similar and both defend against similar attack types, but they operate at genuinely different scopes — that difference is the whole point of having both rather than just one:

• Zone Protection profiles — "defend the boundary itself, broadly." Attached to an entire zone, these defend against flood attacks (SYN floods, UDP/ICMP floods), reconnaissance (port scans, host sweeps — attackers mapping out what's alive before attacking it), packet-based attacks (malformed packets designed to exploit parsing bugs), and non-IP-protocol abuse. One profile can be reused across multiple zones with similar exposure (e.g. every internet-facing zone), which is efficient when you have several zones that face the same class of threat.
• DoS Protection profiles/rules — "defend one specific, high-value system, precisely." Attached via a DoS Protection Policy rule to a specific address — an internet-facing database server, for instance — rather than to a whole zone. This exists because a zone-wide profile can't express "this one server matters more than everything else in the zone and needs tighter, dedicated flood/session-exhaustion thresholds" — DoS Protection is the mechanism for exactly that finer granularity.

Both operate before Security Policy is ever consulted — they're a first line of defense against volumetric/reconnaissance abuse that doesn't need App-ID or user context to recognize, so there's no reason to wait for the rest of the classification pipeline to run first.