6.1 Policy Architecture & Precedence

6.1 Policy Architecture & Precedence

Quick Answer: Fireware implements two fundamental policy architectures: Packet Filter policies, which evaluate traffic at OSI Layers 3 and 4 using stateful connection tables with near-zero latency, and Proxy policies, which terminate connections at OSI Layer 7 to inspect application commands, headers, and payloads. Out of the box the Web Setup Wizard (or WSM Quick Setup Wizard) generates nine default policies — Outgoing, WatchGuard, WatchGuard Web UI, WatchGuard Certificate Portal, Ping, DNS, and the FTP-proxy, HTTP-proxy, and HTTPS-proxy policies with their default client proxy actions — and the WatchGuard management policy covers TCP ports 4105, 4117, and 4118. Policies can be processed in Auto-Order Mode (Fireware sorts rules from most specific to least specific) or Manual Order Mode (strict top-to-bottom evaluation using the first-match principle, where misplacing broad rules causes rule shadowing).

---

Packet Filter Policies vs. Application Proxy Policies

At the core of Fireware OS lies a dual-engine policy framework. When configuring traffic rules in Policy Manager or the Fireware Web UI, administrators must choose between two distinct policy inspection paradigms: Packet Filters and Application Proxies.

+-----------------------------------------------------------------------------------------+
|                         PACKET FILTER vs APPLICATION PROXY ARCHITECTURE                 |
+---------------------------------------------+-------------------------------------------+
|         PACKET FILTER (LAYERS 3-4)          |          APPLICATION PROXY (LAYER 7)      |
|                                             |                                           |
|  [Client] -------- SYN --------> [Server]   |  [Client] <--- Conn 1 ---> [Proxy Engine] |
|           <----- SYN/ACK -------            |                                |          |
|           -------- ACK -------->            |                        Deep Inspection    |
|                                             |                                |          |
|  • Inspects: Source/Dest IP, Port, TCP Flag |  [Proxy Engine] <-- Conn 2 --> [Server]   |
|  • Payload: Passed transparently unread     |  • Inspects: Commands, Headers, Payloads  |
|  • Speed: Wire-speed, minimal RAM/CPU       |  • Security: Enforces RFCs, Strips Malware|
+---------------------------------------------+-------------------------------------------+

Packet Filter Policies: Layer 3 and Layer 4 Stateful Inspection

Packet filter policies operate at the Network (Layer 3) and Transport (Layer 4) layers of the OSI model. When a packet reaches an interface governed by a packet filter policy, the Fireware kernel inspects only the packet headers:

• 5-Tuple Matching: Source IP address, Destination IP address, IP Protocol (e.g., TCP, UDP, ICMP), Source Port, and Destination Port.
• Stateful Connection Tracking: For TCP connections, the Firebox monitors the three-way handshake (SYN -> SYN/ACK -> ACK). It records the state in a dynamic state table, verifying sequence and acknowledgment numbers. Once the handshake completes, return packets matching the existing state table session are permitted automatically without requiring an explicit reverse policy.
• Wire-Speed Throughput: Because packet filters do not assemble or interpret application data, packet processing occurs entirely in the Fireware network subsystem with negligible CPU interrupt overhead and minimal RAM utilization.
• Architectural Limitations: Packet filters cannot examine the application payload. If an attacker initiates an HTTP connection over TCP port 80 carrying an SQL injection exploit, or embeds ransomware inside an allowed FTP transfer, a packet filter permits the transmission because the Layer 3 and Layer 4 parameters are valid.

Application Proxy Policies: Layer 7 Deep Packet Inspection

Proxy policies operate at the Application Layer (Layer 7). Instead of allowing client packets to pass directly through the firewall to the server, a proxy policy acts as an intermediary or protocol terminator:

• Dual-Connection Architecture: The Firebox proxy engine intercepts the client's connection request and completes the initial TCP handshake on behalf of the destination server (Connection 1). Simultaneously, the proxy initiates a separate, independent TCP connection to the actual target server (Connection 2). The client and server never exchange raw IP packets directly.
• Protocol Conformance & RFC Validation: The proxy engine decodes the application protocol syntax (such as HTTP/1.1, HTTP/2, SMTP, DNS, or FTP). It checks whether incoming commands adhere strictly to official RFC standards. For example, the HTTP-proxy verifies header lengths, disallows illegal ASCII characters in URLs, and validates chunked transfer encoding to prevent buffer overflow exploits.
• Deep Content Inspection & Subscription Service Hook: Proxies assemble packet fragments into memory buffers to reconstruct files, MIME types, and scripts. This reconstruction allows Fireware's security subscription engines—including Gateway AntiVirus (GAV), IntelligentAV, Intrusion Prevention Service (IPS), WebBlocker, and APT Blocker—to scan the payload before forwarding it to the recipient.
• Content Transformation: Proxies can strip dangerous HTTP headers, mask internal server banners, block unauthorized HTTP methods (e.g., denying PUT or DELETE while allowing GET and POST), and enforce safe search settings.

Technical Comparison Matrix

The following table outlines the operational differences between packet filter policies and application proxies in Fireware OS:

---

Default Fireware Policies Out of the Box

When a Firebox is initialized using the Web Setup Wizard or the WSM Quick Setup Wizard, Fireware automatically creates a foundational policy configuration and enables the licensed security services with WatchGuard's recommended settings. This ensures that internal workstations can reach the Internet immediately — with outgoing FTP, HTTP, and HTTPS already inspected by proxies — while securing the appliance itself against external administrative tampering.

+-----------------------------------------------------------------------------------------+
|                             DEFAULT OUT-OF-THE-BOX POLICIES                             |
+-----------------------------+---------------+-----------------------------------------------+
| POLICY NAME                 | POLICY TYPE   | PURPOSE / PORTS                               |
+-----------------------------+---------------+-----------------------------------------------+
| Outgoing                    | Packet Filter | Outbound TCP and UDP from Any-Trusted and     |
|                             |               | Any-Optional to Any-External                  |
+-----------------------------+---------------+-----------------------------------------------+
| WatchGuard                  | Packet Filter | Device management from trusted/optional       |
|                             |               | networks on TCP 4105, 4117, and 4118          |
+-----------------------------+---------------+-----------------------------------------------+
| WatchGuard Web UI           | Packet Filter | Browser management of the Firebox (TCP 8080)  |
+-----------------------------+---------------+-----------------------------------------------+
| WatchGuard Certificate      | Packet Filter | Lets users download the Firebox certificates  |
| Portal                      |               | used for HTTPS content inspection             |
+-----------------------------+---------------+-----------------------------------------------+
| Ping                        | Packet Filter | ICMP echo for connectivity testing            |
+-----------------------------+---------------+-----------------------------------------------+
| DNS                         | Packet Filter | Outbound name resolution                      |
+-----------------------------+---------------+-----------------------------------------------+
| FTP-proxy                   | Proxy         | Default-FTP-Client proxy action               |
+-----------------------------+---------------+-----------------------------------------------+
| HTTP-proxy                  | Proxy         | Default-HTTP-Client proxy action              |
+-----------------------------+---------------+-----------------------------------------------+
| HTTPS-proxy                 | Proxy         | Default-HTTPS-Client proxy action             |
+-----------------------------+---------------+-----------------------------------------------+

The Outgoing Policy

The Outgoing policy is a broad packet filter that permits all outbound TCP and UDP connections originating from Any-Trusted or Any-Optional networks to Any-External destinations across virtually all port numbers.

• Operational Purpose: Allows users to connect to web servers, email hosts, DNS resolvers, and remote services immediately after deployment without requiring administrators to define individual port rules manually.
• Security Implications: Because Outgoing is a generic packet filter rather than a proxy, it performs no application-layer payload analysis. Malicious software inside the network can establish outbound Command and Control (C2) connections over arbitrary non-standard ports.
• Enterprise Best Practice: In production environments, administrators should disable or delete the Outgoing policy. It should be replaced with granular, protocol-specific proxy policies—such as HTTP-proxy, HTTPS-proxy with content inspection, and DNS-proxy—enforcing the principle of least privilege.

The Default Proxy Policies and Services

The wizard does not stop at packet filters. It also builds three proxy policies — FTP-proxy, HTTP-proxy, and HTTPS-proxy — bound to the Default-FTP-Client, Default-HTTP-Client, and Default-HTTPS-Client proxy actions, so that outgoing FTP, HTTP, and HTTPS traffic is inspected from the first day. In the same pass it enables the licensed security services (Application Control, WebBlocker, Gateway AntiVirus, Intrusion Prevention, Reputation Enabled Defense, Botnet Detection, Geolocation, and APT Blocker) with logging turned on for reporting.

The WatchGuard Management Policy

The WatchGuard policy is an administrative packet filter that allows management connections to the Firebox itself:

• Ports and Protocols: TCP ports 4105, 4117, and 4118. WatchGuard documents that "the WatchGuard policy controls access to the Firebox on these TCP ports: 4105, 4117, 4118," which is why remote administration requires all three to be reachable.
• Source and Destination: Originates from Any-Trusted and Any-Optional; terminates at the Firebox built-in alias.
• Functional Role: Enables network administrators to connect to the appliance using desktop utilities — WatchGuard System Manager (WSM), Policy Manager, and Firebox System Manager (FSM) — as well as the CLI over SSH on TCP 4118.
• Cloud and Virtual Appliances: On FireboxV and Firebox Cloud, the WatchGuard policy allows connections from Any-External by default so that initial configuration can be completed remotely; restrict it as soon as the deployment is reachable another way.
• Access Restriction Best Practice: By default, this policy permits access from both Any-Trusted and Any-Optional. Administrators should edit this policy to restrict the From list to a dedicated Management Subnet or specific administrative workstation IPs, removing Any-Optional to prevent DMZ hosts from attempting management logins.

The WatchGuard Web UI Policy

The WatchGuard Web UI policy permits web-based device administration:

• Ports and Protocols: TCP port 8080 over TLS/HTTPS (https://<firebox-ip>:8080).
• Source and Destination: Originates from Any-Trusted and Any-Optional; terminates at Firebox.
• Functional Role: Allows management access via standard web browsers to view system status, adjust firewall policies, and run diagnostic tasks without installing WSM on Windows.

The Default Deny Rule (Implicit Drop)

Fireware enforces an implicit Default Deny rule at the end of the policy evaluation sequence. If an incoming packet does not match any allowed policy, Fireware automatically drops the packet and writes a Deny entry to the traffic log. Unsolicited incoming traffic from Any-External targeting internal hosts is dropped by this rule unless a specific inbound policy (such as a Static NAT rule) explicitly permits it.

---

Policy Ordering Modes: Auto-Order vs. Manual Order

Fireware supports two distinct modes for determining the sequence in which policies are evaluated against network traffic: Auto-Order Mode and Manual Order Mode.

+-----------------------------------------------------------------------------------------+
|                        AUTO-ORDER MODE PRECEDENCE ALGORITHM                             |
|                                                                                         |
|  [Most Specific]                                                        [Least Specific]|
|  +-------------+     +---------------+     +------------------+     +----------------+  |
|  | Host IP /   | --> | Small Subnet  | --> | Large Network /  | --> | Wildcard /     |  |
|  | Host FQDN   |     | (e.g., /28)   |     | Zone Alias       |     | Any / Outgoing |  |
|  +-------------+     +---------------+     +------------------+     +----------------+  |
+-----------------------------------------------------------------------------------------+

Auto-Order Mode (Default)

In Auto-Order Mode, Fireware automatically sorts and organizes all configured policies. The administrator does not manually position policies up or down in the list; instead, the Fireware policy engine calculates precedence based on the specificity of the traffic criteria defined in the From and To lists.

The Fireware Specificity Hierarchy

Fireware applies a deterministic mathematical ordering algorithm:

1. Specific Host IP or Host FQDN: Policies referencing an individual host (e.g., 10.0.1.25 or db.internal.corp) receive the highest priority.
2. Small Subnets (Longer CIDR Prefix): Policies referencing smaller subnets (e.g., 10.0.1.0/28) are evaluated before larger subnets (e.g., 10.0.1.0/24).
3. Large Networks & Built-in Zone Aliases: Policies referencing broad network interfaces or built-in aliases (such as Any-Trusted or Any-Optional) are evaluated next.
4. Wildcards and Catch-All Rules: Policies containing Any or broad packet filters like Outgoing are pushed to the bottom of the evaluation list.

Advantages and Limitations

• Advantage: Auto-Order Mode virtually eliminates human error when creating granular exceptions. If an administrator creates a broad policy allowing web access to Any-Trusted, but subsequently creates a deny policy blocking web access for a single compromised host 10.0.1.50, Fireware automatically evaluates the host-specific deny rule first. The host is blocked without needing manual list rearrangement.
• Limitation: In complex enterprise networks with overlapping policies, multiple service definitions, and mixed allow/deny actions, Auto-Order Mode may not reflect custom organizational logic, necessitating a switch to Manual Order Mode.

Manual Order Mode

When an administrator switches Policy Manager or the Web UI from Auto-Order Mode to Manual Order Mode, Fireware relinquishes automatic rule positioning. Policies are displayed as a numbered list from top to bottom (e.g., Rule 1, Rule 2, Rule 3).

The First-Match Principle

In Manual Order Mode, incoming packets are evaluated strictly against Rule 1, then Rule 2, then Rule 3, in descending sequential order:

• Immediate Action on First Match: The moment a packet satisfies all criteria of a policy (protocol, port, source IP/alias, and destination IP/alias), the policy action (Allow or Deny) is applied immediately.
• Termination of Evaluation: Once a match occurs, packet evaluation terminates. Fireware ceases checking subsequent policies in the list for that connection.

Incoming Packet: Source = 10.0.1.50, Dest = 93.184.216.34, Port = 80 (HTTP)
       |
       v
+--------------------------------------------------------------------------------+
| Policy 1: HTTP-Allow-All (From: Any-Trusted -> To: Any-External) [ALLOW]       |
+--------------------------------------------------------------------------------+
       | Matches! Packet is ALLOWED immediately. Evaluation terminates.
       x (Never reaches Policy 2)
+--------------------------------------------------------------------------------+
| Policy 2: Block-Compromised-Host (From: 10.0.1.50 -> To: Any-External) [DENY]  |
+--------------------------------------------------------------------------------+
       ^ SHADOWED / UNREACHABLE RULE: Traffic from 10.0.1.50 is never blocked!

Shadowed and Unreachable Rules

The most common and dangerous vulnerability introduced in Manual Order Mode is rule shadowing (creating unreachable rules):

• Mechanism of Shadowing: If a broad policy is positioned above a specific policy governing the same protocol or port, the broad policy intercepts the packet first. The specific policy beneath it is never evaluated.
• Example: Suppose an administrator wants to block host 10.0.1.50 from accessing the web, but allow all other internal users web access. In Manual Order Mode, if the policy Allow HTTP (From: Any-Trusted To: Any-External) is placed at position 5, and the policy Deny HTTP (From: 10.0.1.50 To: Any-External) is placed at position 12, host 10.0.1.50 will successfully browse the web. Because 10.0.1.50 belongs to Any-Trusted, Rule 5 matches and permits the connection immediately, rendering Rule 12 unreachable.
• Remediation: In Manual Order Mode, specific exceptions must always be placed physically higher in the rule list than general policies.