6.2 Policy Configuration, Aliases & Schedules

6.2 Policy Configuration, Aliases & Schedules

Quick Answer: Every Fireware policy is defined by its Name, Policy Type (packet filter vs. proxy), Connection Action (Allowed vs. Denied), Source list (From), and Destination list (To). Fireware provides built-in aliases—such as Any, Any-External, Any-Trusted, Any-Optional, and Firebox (which represents the appliance itself)—to simplify management. Administrators can also define Custom Aliases containing IP hosts, subnets, ranges, and FQDNs (which dynamically resolve and cache domain IPs via DNS inspection), as well as Policy Schedules that restrict policy enforcement to specific days of the week and operating hours.

---

Anatomy of a Firewall Policy

Creating an effective security policy in WatchGuard Fireware requires configuring five foundational parameters within the policy configuration dialog, accompanied by directionality, logging, and notification settings.

+-----------------------------------------------------------------------------------------+
|                               FIREWARE POLICY ARCHITECTURE                              |
+-----------------------------------------------------------------------------------------+
|  1. POLICY NAME & TYPE       : HTTPS-proxy (Proxy Policy, TCP Port 443)                 |
|  2. CONNECTIONS              : Allowed (or Denied)                                      |
|  3. FROM (SOURCE)            : Any-Trusted, Alias: Finance_Workstations, User: JSmith   |
|  4. TO (DESTINATION)         : Any-External, FQDN: *.salesforce.com                    |
|  5. LOGGING & NOTIFICATIONS  : Send Log Message (Enabled), Send SNMP Trap               |
|  6. OPERATIONAL SCHEDULE     : Schedule Object: Standard_Business_Hours                 |
+-----------------------------------------------------------------------------------------+

Core Policy Components

1. Policy Name and Description: A descriptive identifier (e.g., Allow_Branch_RDP or Strict_HTTP_Proxy). Descriptive naming is critical for change tracking and compliance audits.
2. Policy Type: Specifies whether the rule behaves as a Layer 3/4 Packet Filter or a Layer 7 Application Proxy. The policy type binds the rule to specific network protocols and destination port definitions (e.g., TCP port 25 for SMTP, TCP port 443 for HTTPS, or custom port ranges).
3. Connections (Action): Determines what happens when matching traffic encounters the rule:
   • Allowed: Traffic satisfying all policy parameters is permitted to establish a session.
   • Denied: Traffic is discarded. Fireware allows administrators to configure the denial behavior as either a silent Drop (packet is dropped without notifying the sender) or a Reject (transmits an ICMP Port Unreachable message for UDP, or a TCP RST flag for TCP sessions).
4. From (Source List): Defines the permitted initiators of the connection. Entries can include individual IPv4/IPv6 addresses, subnet CIDR blocks, interface names, user identities authenticated through Active Directory, or built-in and custom aliases.
5. To (Destination List): Defines the permitted targets of the connection. Entries can include remote hosts, external subnets, Static NAT (SNAT) actions, server load balancing virtual IPs, or domain-based objects (FQDNs).

Directionality and Stateful Return Traffic Handling

A fundamental principle tested on the certification exam is that Fireware policies define the initiation of a connection:

• When a policy specifies From: Any-Trusted and To: Any-External, it grants hosts in the Trusted zone the authority to initiate sessions to external destinations.
• Because Fireware is stateful, return packets sent by the external server back to the internal client are permitted automatically as part of the established connection tracking table.
• Administrators do not need to create reverse policies (e.g., From: Any-External to Any-Trusted) for legitimate return traffic. Creating an unnecessary reverse allow policy inadvertently opens the internal network to unsolicited inbound attacks.

---

Built-in System Aliases

To simplify policy authoring and eliminate the need to update dozens of rules whenever physical network topology changes, Fireware maintains a suite of built-in system aliases. These aliases update dynamically whenever interfaces are added, reconfigured, or re-zoned.

The Firebox Alias in Management Access Controls

The Firebox alias plays a specialized role in device security. Because a Firebox possesses multiple IP addresses—including its External WAN IP, primary Trusted IP (e.g., 10.0.1.1), DMZ IP, and loopback addresses—referencing Firebox in the To list ensures that the policy applies regardless of which interface receives the administrative connection.

[!IMPORTANT] If an administrator wishes to lock down the Fireware Web UI so that it can only be accessed from the Trusted LAN, they edit the WatchGuard Web UI policy:

• From: Change from Any-Trusted and Any-Optional to Any-Trusted (or a specific management host IP like 10.0.1.50).
• To: Retain Firebox as the destination. If the administrator accidentally placed Any-Trusted in the To field instead of Firebox, the policy would no longer permit management of the firewall itself; instead, it would permit port 8080 connections to internal LAN computers.

---

Custom Aliases and FQDN Objects

While built-in aliases represent whole security zones, enterprise administration demands granular object grouping. Fireware allows engineers to construct Custom Aliases.

+-----------------------------------------------------------------------------------------+
|                                 CUSTOM ALIAS STRUCTURES                                 |
+---------------------+---------------------+---------------------+-----------------------+
| SINGLE HOST IP      | IP ADDRESS RANGE    | IP NETWORK / CIDR   | FQDN / WILDCARD       |
| 192.168.10.15       | 10.0.5.10-10.0.5.50 | 172.16.0.0/20       | *.office365.com       |
+---------------------+---------------------+---------------------+-----------------------+

Custom Alias Member Types

A single Custom Alias can combine multiple diverse member objects:

• Host IPv4 or IPv6 Address: A single endpoint (e.g., 10.0.1.25).
• IP Address Range: A contiguous block of IP addresses that does not align with standard subnet boundaries (e.g., 10.0.1.100 to 10.0.1.150, often used for static DHCP pools).
• Network (Subnet CIDR): A full broadcast domain or routed network (e.g., 192.168.100.0/24).
• Nested Aliases: An alias can contain other aliases. For instance, an alias named All_Corporate_Offices can contain Alias_HQ, Alias_London, and Alias_Tokyo.
• User and Group Accounts: Active Directory or local Firebox database users and groups.

Fully Qualified Domain Name (FQDN) Aliases

Modern enterprise infrastructure relies heavily on multi-tenant cloud platforms (such as Microsoft 365, Amazon Web Services, Salesforce, and Google Workspace). These cloud providers utilize thousands of dynamic IP addresses that shift across global Content Delivery Networks (CDNs) multiple times per day. Defining firewall policies based on static IP addresses or CIDR blocks for cloud platforms is unfeasible.

To solve this, Fireware supports Fully Qualified Domain Name (FQDN) aliases:

• Exact Match FQDN: Matches a specific host (e.g., portal.azure.com).
• Wildcard FQDN: Matches any subdomain under a root domain (e.g., *.microsoft.com or *.salesforce.com).

sequenceDiagram
    autonumber
    actor Client as Workstation
    participant DNS as Internal DNS Server
    participant Firebox as Firebox (FQDN Engine)
    actor Cloud as Cloud Server (e.g., *.github.com)
    
    Note over Firebox: Admin creates policy with To: *.github.com
    Client->>DNS: Resolves api.github.com
    DNS-->>Client: Returns IP: 140.82.112.6 (TTL: 300s)
    Firebox->>Firebox: Snoops DNS response packet & extracts IP + TTL
    Firebox->>Firebox: Caches 140.82.112.6 in FQDN table under *.github.com
    Client->>Firebox: Outbound HTTPS request to 140.82.112.6:443
    Firebox->>Firebox: Evaluates policy: Matches FQDN cache for *.github.com
    Firebox->>Cloud: Permits & forwards session to 140.82.112.6

The Fireware FQDN Dynamic Resolution Mechanics

A common point of confusion on certification exams is how the Firebox resolves and tracks FQDNs. The Firebox does not continuously poll external DNS servers for every possible wildcard subdomain:

1. DNS Snooping / Inspection: When internal clients resolve hostnames through DNS queries traversing the Firebox, the Fireware DNS engine intercepts and inspects the DNS response packets.
2. Dynamic Cache Population: When the Firebox sees a DNS answer mapping api.github.com to 140.82.112.6, and the policy contains *.github.com, Fireware adds 140.82.112.6 to its active internal kernel FQDN cache table.
3. TTL Enforcement: Fireware honors the Time To Live (TTL) value supplied by the authoritative DNS server. If the DNS response specifies a TTL of 300 seconds, Fireware retains the IP mapping in its FQDN table for 5 minutes. When the TTL expires, the entry is flushed unless refreshed by a subsequent query.
4. Static Periodic Probing: For non-wildcard FQDNs (e.g., time.nist.gov), the Firebox also sends periodic background DNS queries using its configured Network DNS servers to keep the cache updated even if no client has made a recent request.

---

Policy Schedules & Temporal Access Controls

Organizations frequently require policies that operate only during specific times. Fireware allows administrators to attach Policy Schedules to any packet filter or proxy policy.

Creating and Managing Schedule Objects

Policy Schedules are configured as discrete reusable objects in Policy Manager (under Setup > Schedules) or in the Web UI:

• One-Time Schedule: Specifies a discrete start date/time and end date/time (e.g., from 2026-10-01 00:00 to 2026-10-01 06:00). Ideal for planned maintenance windows or temporary vendor onboarding.
• Recurring Schedule: Defines recurring weekly activation windows. The administrator selects the days of the week (e.g., Monday through Friday) and the daily time range using a 24-hour clock (e.g., 08:00 to 18:00).

+-----------------------------------------------------------------------------------------+
|                            POLICY SCHEDULE BEHAVIOR TIMELINE                            |
|                                                                                         |
|  Schedule: Mon-Fri 08:00 - 18:00 (Guest_WiFi_Access)                                    |
|                                                                                         |
|  00:00                 08:00                              18:00                   23:59 |
|  [------ INACTIVE -----][=========== ACTIVE ==============][--------- INACTIVE --------] |
|            |                                                            |               |
|            v                                                            v               |
|   Traffic falls through to                                    Traffic falls through to  |
|   subsequent policies or                                      subsequent policies or    |
|   Default Deny (Drop & Log)                                   Default Deny (Drop & Log) |
+-----------------------------------------------------------------------------------------+

Operational Behavior of Scheduled Policies

Understanding how Fireware handles traffic when a schedule is active versus inactive is crucial for predictable policy design:

• Active State: When the Firebox system clock falls within the scheduled window, the policy is enabled. Traffic matching its criteria is processed normally.
• Inactive State: When the current time falls outside the scheduled window, the policy is treated as though it does not exist in the active rule set. Matching traffic is not automatically dropped by the scheduled policy itself; instead, the connection falls through to the next matching policy lower in the evaluation list.
• Fallback to Default Deny: If no subsequent policy matches the traffic, the packet reaches the end of the policy list and is discarded by the implicit Default Deny rule.
• System Clock Dependency: Because schedules rely strictly on the internal system clock, accurate Network Time Protocol (NTP) synchronization is mandatory. If an appliance clock drifts by several hours due to failed NTP synchronization, scheduled policies will activate and deactivate at incorrect times.