Study guide
6.2 Policy Configuration, Aliases & Schedules
WatchGuard Network Security Essentials Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Firebox Architecture & Initial Setup
1.1 Firebox Hardware Family & Virtual Appliances 1.2 Initial Configuration & Quick Setup Wizard 1.3 Fireware Management Tools & Access Control
2 Chapter 2: Network Interfaces & Operating Modes
2.1 Interface Types & Physical Configuration 2.2 Network Operating Modes 2.3 VLAN Configuration & Link Aggregation
3 Chapter 3: Routing & Local Network Services
3.1 Static Routing & Dynamic Routing Protocols 3.2 DHCP Server, DHCP Relay & PPPoE 3.3 DNS Configuration & Dynamic DNS
4 Chapter 4: Network Address Translation (NAT)
4.1 Dynamic NAT (Source NAT) 4.2 Static NAT (Server NAT & Port Forwarding) 4.3 1-to-1 NAT 4.4 NAT Loopback & Policy-Based NAT
5 Chapter 5: Multi-WAN & SD-WAN
5.1 Multi-WAN Methods & Load Balancing 5.2 Link Monitor & WAN Health Checks 5.3 SD-WAN Actions, Metrics & Path Selection
6 Chapter 6: Firewall Policies & Packet Filtering
6.1 Policy Architecture & Precedence 6.2 Policy Configuration, Aliases & Schedules 6.3 Default Threat Protection & Packet Handling
7 Chapter 7: Application Proxies & Deep Packet Inspection
7.1 Proxy Policies & Proxy Actions 7.2 HTTPS Content Inspection & TLS Decryption 7.3 Domain Name Rules, Content Actions & Inspection Exceptions
8 Chapter 8: Subscription Services — Antivirus, Web & Content Security
8.1 Gateway AntiVirus (GAV) & IntelligentAV 8.2 WebBlocker URL Filtering 8.3 spamBlocker & Reputation Enabled Defense (RED)
9 Chapter 9: Subscription Services — Advanced Threat Protection & ThreatSync
9.1 Intrusion Prevention Service (IPS) & Application Control 9.2 APT Blocker & DNSWatch 9.3 Geolocation, Botnet Detection & ThreatSync
10 Chapter 10: Authentication & Identity Management
10.1 Authentication Servers & Directory Integration 10.2 Single Sign-On (SSO) Architecture 10.3 Authentication Portal, User-Aware Policies & AuthPoint MFA
11 Chapter 11: Mobile Virtual Private Networks (Mobile VPN)
11.1 Mobile VPN with SSL 11.2 Mobile VPN with IKEv2 11.3 Mobile VPN with L2TP & Legacy IPSec
12 Chapter 12: Branch Office Virtual Private Networks (BOVPN)
12.1 Policy-Based Branch Office VPN (BOVPN) 12.2 BOVPN Virtual Interfaces (BOVPN VIF) 12.3 Dynamic Peers, NAT & BOVPN Multi-WAN
13 Chapter 13: Logging, Monitoring & Dimension
13.1 Firebox Logging Architecture & Traffic Monitor 13.2 WatchGuard Dimension & FireWatch 13.3 WatchGuard Cloud Visibility & Diagnostic Tools
14 Chapter 14: High Availability (FireCluster) & Maintenance
14.1 FireCluster Architecture & Operating Modes 14.2 FireCluster Prerequisites, Configuration & Synchronization 14.3 Device Maintenance, Backups & Firmware Upgrades
6.2 Policy Configuration, Aliases & Schedules
Key Takeaways Explain This Topic AI
A Fireware policy definition is built on five core elements: Policy Name, Policy Type (Packet filter or Proxy), Connection Action (Allowed or Denied), Source list (From), and Destination list (To).
Built-in aliases dynamically aggregate interfaces and system roles: Any includes all routed interfaces, Any-External groups all WAN interfaces, Any-Trusted and Any-Optional aggregate LAN and DMZ interfaces, and Firebox represents the physical/virtual firewall itself.
Custom aliases allow administrators to group IP addresses, IP address ranges, subnets, and nested aliases into reusable objects, simplifying policy maintenance across multi-site architectures.
Fully Qualified Domain Name (FQDN) aliases permit policy enforcement against dynamic cloud hostnames by snooping DNS queries and maintaining a local IP cache table governed by DNS TTL values.
Policy schedules allow administrators to define recurring or one-time time windows during which a policy is active; outside scheduled hours, the policy is ignored, and traffic falls through to subsequent policies or the default drop rule.
Last updated: September 2026
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
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.
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).
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).
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.
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.
Built-in Alias Scope of Inclusion Common Enterprise Use Cases Architectural Considerations
Any Includes all IPv4 and IPv6 traffic across all interfaces (External, Trusted, Optional, and Custom). Wide-scale network testing, general deny rules, or global NTP policies. Use with caution; referencing Any in an allow rule can unintentionally expose internal subnets to untrusted zones.
Any-External Aggregates all physical, virtual, or VLAN interfaces assigned to the External zone. Default gateway egress, public Internet browsing rules, branch-to-cloud tunnels. Automatically expands when secondary WAN interfaces are deployed in Multi-WAN topologies.
Any-Trusted Aggregates all interfaces assigned to the Trusted zone. Corporate LAN egress policies, internal printer/server sharing, Active Directory authentication rules. Includes both physical Trusted Ethernet ports and internal VLANs configured as Trusted.
Any-Optional Aggregates all interfaces assigned to the Optional zone (typically DMZ networks). DMZ outbound web services, isolated guest Wi-Fi access to the Internet. Isolated from Any-Trusted by default; traffic between Optional and Trusted requires explicit inter-zone policies.
Firebox Represents the Firebox security appliance itself, encompassing all IP addresses assigned to all interfaces. Local device administration (TCP 4105, TCP 8080), SNMP polling, NTP synchronization, VPN termination. Never use Firebox as the destination when the intended target is an internal server behind the firewall.
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 ).
Loading diagram...
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:
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.
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.
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.
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.