Study guide
7.3 Domain Name Rules, Content Actions & Inspection Exceptions
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
7.3 Domain Name Rules, Content Actions & Inspection Exceptions
Key Takeaways Explain This Topic AI
Server Name Indication (SNI) inspection reads the unencrypted hostname in the TLS ClientHello, letting the Firebox filter and categorize HTTPS domains without full decryption; WatchGuard documents SNI as the most accurate source and falls back to the certificate Common Name when SNI is unavailable.
Domain Name rules in an HTTPS proxy action support five actions — Allow (pass the connection through without decrypting), Inspect (decrypt and hand the stream to an HTTP proxy action or content action), Deny (refuse the request and answer the client), Drop (refuse and drop the connection), and Block (refuse, drop, and add the site to Blocked Sites).
A separate "Action to take if no rule above is matched" setting defines the default disposition for domains that match no rule, and rules are evaluated in the order listed; wildcard patterns accept an asterisk, a period, or a question mark.
An HTTP content action routes inbound HTTP requests to different internal web servers based on the HTTP host header and request path (host header redirect); routes set in the content action override the NAT settings in the proxy policy, and using one with the HTTPS proxy requires content inspection in an HTTPS server proxy action.
Applications that pin certificates (mobile banking apps, cloud sync clients, OS update services) break under HTTPS Content Inspection because the re-signed certificate does not match the pinned key, so those domains need Domain Name rules set to Allow rather than Inspect.
Last updated: September 2026
7.3 Domain Name Rules, Content Actions & Inspection Exceptions
Quick Answer: The Firebox can enforce policy on HTTPS traffic without full decryption by reading the Server Name Indication (SNI) extension sent in cleartext in the TLS ClientHello . Within an HTTPS proxy action, Domain Name rules support five actions — Allow (permit the request without decrypting it), Inspect (decrypt and pass the stream to an HTTP proxy action or content action), Deny (refuse the request and send a response to the client), Drop (refuse the request and drop the connection), and Block (refuse, drop, and add the site to the Blocked Sites list) — plus a separate setting for the action to take when no rule matches. A related object, the HTTP content action , routes inbound HTTP requests to different internal web servers based on the HTTP host header and path. Administrators also enforce server certificate validation and create selective inspection exceptions (Allow rules) for sensitive categories under GLBA/HIPAA and for applications that enforce certificate pinning .
Server Name Indication (SNI) Inspection vs. Full TLS Decryption
In high-throughput enterprise networks, performing full HTTPS Content Inspection on every outbound session can be resource-intensive, legally problematic, or technically incompatible with certain proprietary software. To address this, Fireware OS provides a hybrid inspection model that leverages Server Name Indication (SNI) .
Mechanics of Server Name Indication (RFC 6066)
When a client web browser initiates a TLS connection, multiple virtual web servers may reside behind a single destination public IP address. To inform the remote web server which digital certificate to present, the client inserts the target hostname into the server_name extension of the initial ClientHello packet.
Plaintext Visibility: In standard TLS 1.2 and TLS 1.3 handshakes, the ClientHello message is transmitted in cleartext before cryptographic cipher suites or symmetric session keys are negotiated.
SNI Snooping: The Firebox HTTPS proxy engine parses this initial packet and extracts the Fully Qualified Domain Name (e.g., banking.chase.com or malware-c2-node.ru ).
WebBlocker Categorization Without Decryption: The Firebox can submit this extracted domain name directly to the WebBlocker cloud database to categorize the site (e.g., Gambling, Social Media, Malicious Websites) and enforce policy actions (Allow, Deny, Warn) without decrypting the payload or requiring a Proxy Authority CA certificate on the client.
Certificate Fallback: WatchGuard documents the SNI as the most accurate source for the server domain. When the client does not send an SNI extension, the Firebox falls back to the Common Name (CN) in the server certificate. +---------------------------------------------------------------------------------------------------+
- | SNI INSPECTION vs FULL TLS DECRYPTION |
- +------------------------------------+--------------------------------------------------------------+
- | SNI-ONLY INSPECTION (Allow rules) | FULL HTTPS CONTENT INSPECTION (Inspect rules) |
- +------------------------------------+--------------------------------------------------------------+
- | • Inspects: ClientHello SNI header | • Inspects: Decrypted HTTP commands, paths, headers, payload |
- | • Client CA Cert: NOT required | • Client CA Cert: MANDATORY (Proxy Authority CA / GPO) |
- | • WebBlocker: Domain-level only | • WebBlocker: Full URL paths (e.g., /path/file.html) |
- | • Malware Scanning: BLIND | • Malware Scanning: FULL (GAV, APT Blocker, IPS) |
- | • Resource Cost: Negligible CPU | • Resource Cost: Moderate CPU and memory buffering |
- | • Application Compatibility: 100% | • Application Compatibility: Pinned apps need Allow rules |
- +------------------------------------+--------------------------------------------------------------+
- Configuring Domain Name Rules within HTTPS Proxy Actions
Within an HTTPS-Client proxy action, the Domain Name rules table directs every outbound encrypted session. The Firebox evaluates the domain name — taken from the TLS SNI extension, or from the server certificate Common Name when no SNI is present — and applies one of five operational actions. +---------------------------------------------------------------------------------------------------+
- | HTTPS PROXY ACTION - DOMAIN NAME RULES TABLE |
- +-------------------+-----------------------+---------------+---------------------------------------+
- | DOMAIN PATTERN | ACTION | PROXY ACTION | OPERATIONAL PURPOSE |
- +-------------------+-----------------------+---------------+---------------------------------------+
- | *.chase.com | Allow | N/A | Privacy compliance (GLBA/Banking) |
- | *.wellsfargo.com | Allow | N/A | Privacy compliance (GLBA/Banking) |
- | *.mayoclinic.org | Allow | N/A | Regulatory compliance (HIPAA/Health) |
- | *.apple.com | Allow | N/A | Certificate pinning (Software update) |
- | *.gambling.com | Deny | N/A | Policy violation (client is answered) |
- | malware-c2.example| Block | N/A | Drop and add site to Blocked Sites |
- | (no rule matched) | Inspect | HTTP-Client | "Action to take if no rule above is |
- | | | | matched" setting: full DPI & AV |
- +-------------------+-----------------------+---------------+---------------------------------------+
- The Five Domain Name Rule Actions
WatchGuard documents exactly five actions for a Domain Name rule. There is no separate "Bypass" action — Allow is the action that exempts a domain from decryption.
Action Fireware Behavior Typical Use
Allow "Allows the HTTPS request (the proxy does not decrypt the connection)." The Firebox logs the connection and tracks TCP state, but the original client-to-server TLS session stays intact. Inspection exceptions: banking, healthcare, and certificate-pinned applications.
Inspect "Uses the specified HTTP proxy action or content action to inspect content." The Firebox terminates the client TLS session, re-signs the certificate with the Proxy Authority CA, decrypts the payload, and hands the cleartext stream to an HTTP proxy action (or an HTTP content action) for GAV, IPS, APT Blocker, WebBlocker, and MIME filtering. General web browsing where deep threat prevention is required.
Deny "Denies the specific request and sends a response to the client." The user sees an explicit denial rather than a silent failure. Unsanctioned SaaS and policy violations where user feedback is wanted.
Drop "Denies the request and drops the connection." No response is returned; the client times out. Hostile or unwanted domains where you do not want to acknowledge the request.
Block "Denies the request, drops the connection, and blocks the site." The source is added to the Blocked Sites list for the configured duration. Confirmed malicious domains and command-and-control infrastructure.
Note
In an HTTPS server proxy action, selecting Allow or Inspect in a Domain Name rule additionally lets you configure a routing action and port, so inbound requests for a published domain can be sent to a specific internal server and port.
Rule Order, Wildcards & the Unmatched-Domain Action
Rule Order: Domain Name rules "are processed in the rule order listed if multiple rules match for a domain." Administrators reorder them with the Move Up and Move Down buttons, placing explicit hostnames (such as login.microsoftonline.com ) above broad wildcards.
Wildcard Syntax: Pattern matching accepts an asterisk ( * ), a period ( . ), or a question mark ( ? ) as wildcard characters. For instance, *.dropbox.com matches www.dropbox.com and client.dropbox.com .
Unmatched Domains: The default disposition is not a catch-all row in the table. It is a separate, mandatory setting — "Action to take if no rule above is matched" — and it offers the same five actions. In a high-security configuration this is set to Inspect , so every domain that is not explicitly excepted is decrypted and scanned.
HTTP Content Actions: Host-Header Routing & TLS Offload
A content action is a distinct Fireware object that is easy to confuse with a Domain Name rule, and the exam objectives list the two together. Where a Domain Name rule decides whether to decrypt , a content action decides which internal server receives the request .
What a Content Action Does
WatchGuard defines the feature this way: "An HTTP content action enables the Firebox to route inbound HTTP requests to different internal web servers based on the content of the HTTP host header and the path in the HTTP request." Because the decision is driven by the domain in the host header, this behavior is also called host header redirect . A content action serves two purposes:
Host Header Redirect: One public IP address can front many internal web servers. The Firebox reads the host header (and optionally the path) and forwards the request to the matching internal server, reducing the number of public IPv4 addresses an organization must buy.
TLS/SSL Offloading: When a content action is used with an HTTPS server proxy action and content inspection is enabled, "the Firebox decrypts the inbound requests, and then sends unencrypted traffic to the internal web server." The Firebox carries the cryptographic load instead of the web servers. +---------------------------------------------------------------------------------------------------+
- | HTTP CONTENT ACTION - INBOUND HOST HEADER ROUTING |
- +-------------------------------+-------------------+-----------------------------------------------+
- | CONTENT RULE (host + path) | ROUTING ACTION | RESULT |
- +-------------------------------+-------------------+-----------------------------------------------+
- | shop.example.com /* | 10.0.2.51 : 8080 | Commerce farm receives the request |
- | www.example.com /blog/* | 10.0.2.52 : 80 | Blog server receives the request |
- | www.example.com /* | 10.0.2.50 : 80 | Corporate web server receives the request |
- | (no rule matched) | Use Policy Default| Falls back to the SNAT settings in the policy |
- +-------------------------------+-------------------+-----------------------------------------------+
- Configuring and Applying a Content Action
Create the object: In Fireware Web UI, select Firewall > Content Actions (in Policy Manager, the content action is created from the proxy action). Add the action and give it a name.
Add content rules: Each rule specifies the pattern to match in the HTTP host header and the path in the request.
Set the routing action: For each rule, choose Use and type the IP address of the internal server (and, if required, the port), or select Use Policy Default so the request falls back to the NAT settings configured in the proxy policy.
Bind it to a policy: Use the content action in an inbound HTTP proxy policy, or — for encrypted traffic — in an HTTPS server proxy action with content inspection enabled , which is what allows the decrypted request to be examined and routed.
Important
Routes specified in the content action override the NAT settings configured in the policy. If a published site suddenly reaches the wrong internal server after a content action is added, inspect the content rules before troubleshooting the SNAT action — the content action wins.
Object Question it answers Where it lives Requires content inspection?
Domain Name rule Do we decrypt this HTTPS session, deny it, drop it, or block the site? HTTPS proxy action (client or server) No — Allow rules work on SNI alone
HTTP content action Which internal web server and port should this inbound request go to? Firewall > Content Actions, bound to an HTTP or HTTPS server proxy action Yes, when used with the HTTPS proxy
SNAT action Which internal IP does this public IP and port map to? Network > SNAT, referenced in the policy To list No
Server Certificate Validation Controls
When HTTPS Content Inspection is active, internal client workstations place complete trust in the Firebox to validate the security posture of upstream web servers. If an external website utilizes an expired SSL certificate, a fraudulent root CA, or a revoked credential, the client browser will never see that defective certificate directly—it will only see the synthetic certificate generated by the Firebox.
Therefore, Fireware includes robust Server Certificate Validation controls within the HTTPS Proxy Action to prevent the firewall from blindly accepting and re-signing untrusted or compromised external certificates. +---------------------------------------------------------------------------------------------------+
- | SERVER CERTIFICATE VALIDATION ARCHITECTURE |
- +---------------------------------------------------------------------------------------------------+
- | |
- | [External Web Server] |
- | | |
- | | Presents Server Certificate during TLS Handshake |
- | v |
- | [Firebox HTTPS Proxy Engine] |
- | | |
- | +---> 1. Expiration Check : Is certificate currently valid? (Not expired) |
- | +---> 2. Certification Authority: Is issuer in Firebox Trusted CA Store? |
- | +---> 3. Revocation Check (CRL) : Has serial number been revoked? |
- | +---> 4. Revocation Check (OCSP) : Real-time query to OCSP Responder |
- | +---> 5. Name Mismatch Check : Does CN / SAN match requested domain? |
- | | |
- | | IF VALIDATION FAILS: |
- | +====================> Configured Action: BLOCK, DROP, or WARN (Send Alarm) |
- | | |
- | | IF VALIDATION SUCCEEDS: |
- | +====================> Proceed to Re-Signing and Decrypted Content Inspection |
- +---------------------------------------------------------------------------------------------------+
- Core Validation Checks and Configurable Actions
Administrators configure validation actions under the Validation settings of the HTTPS Proxy Action:
Expired Certificates: When an external web server presents a certificate whose expiration date has passed (or whose Not Before date is in the future). The recommended enterprise action is Block/Drop to prevent connections to neglected, abandoned, or hijacked web servers.
Untrusted Certification Authority: Occurs when the external certificate was signed by a self-signed entity or an internal CA not present in the Firebox's trusted root store. The default action is Block/Drop . Administrators can manually import custom partner CA certificates into the Firebox if a legitimate business partner utilizes a private PKI.
Certificate Revocation Status (CRL and OCSP):
Certificate Revocation Lists (CRL): The Firebox downloads published lists of revoked certificate serial numbers over HTTP/LDAP.
Online Certificate Status Protocol (OCSP): The Firebox transmits real-time queries to an OCSP responder specified in the certificate's Authority Information Access (AIA) extension.
Action on Revocation Failure: If an external certificate is confirmed revoked (e.g., compromised private key), the Firebox immediately drops the connection. Administrators can also define fallback actions if the OCSP responder is temporarily unreachable (Allow or Drop).
Common Name (CN) / SAN Mismatch: Occurs when the domain name in the URL does not match any name listed in the Subject Common Name or Subject Alternative Name fields. This is a classic indicator of a man-in-the-middle attack on the public Internet or a misconfigured web server; the Firebox drops matching sessions.
Regulatory Compliance & Certificate Pinning Exceptions
Deploying universal, blanket HTTPS inspection across an entire organization without exceptions is neither legally viable nor technically feasible. Two primary drivers necessitate the implementation of Inspection Exceptions : legal privacy mandates and application certificate pinning.
1. Regulatory Privacy Compliance (HIPAA, GLBA, GDPR)
In most jurisdictions, decrypting personal or financial communications of employees or patients introduces immense legal liability:
Gramm-Leach-Bliley Act (GLBA): Mandates strict protection of non-public personal financial information. If an employer decrypts employee sessions to personal banking portals (e.g., Chase, Wells Fargo, Bank of America), personal bank account numbers, investment portfolios, and financial records are exposed in cleartext memory buffers, logs, and potential packet captures.
Health Insurance Portability and Accountability Act (HIPAA): Governs Protected Health Information (PHI). Intercepting patient or employee connections to health insurance portals, medical clinics, or pharmacy systems constitutes unauthorized processing of health data.
General Data Protection Regulation (GDPR) & State Privacy Laws: Prohibits the unlawful intercept, processing, or logging of sensitive personal data.
Implementation via Domain Name Rules: The exception is expressed as a Domain Name rule whose action is Allow , which lets the session pass without decryption. Administrators typically maintain a curated list of financial, healthcare, and government domains (plus the WebBlocker category enforcement available in the HTTPS proxy action) rather than decrypting those sessions and accepting the liability.
2. The Challenge of TLS Certificate Pinning
Many modern cloud applications, mobile apps, operating system updaters, and collaboration platforms implement Certificate Pinning (also known as SSL Pinning or Public Key Pinning):
The Pinning Mechanism: To prevent man-in-the-middle attacks, software developers hardcode (pin) the expected cryptographic hash of the server's public key or intermediate certificate directly inside the application binary.
The Collision with HTTPS Inspection: When the Firebox intercepts a pinned application (such as Apple iOS software updates, Google Drive sync, Microsoft 365 telemetry, Dropbox desktop clients, or dedicated banking apps), it presents its synthetic certificate signed by the Proxy Authority CA. Even though the client operating system trusts the Proxy Authority CA, the pinned application compares the presented certificate's public key against its hardcoded hash.
Application Failure: Because the keys do not match, the application detects an unauthorized intermediary, terminates the connection immediately, and logs a fatal cryptographic handshake failure. The application stops working entirely.
The Remedy: Administrators must identify the specific destination FQDNs utilized by the pinned software and add Domain Name rules with the Allow action for those domains (e.g., *.apple.com or *.dropbox.com ), so the Firebox passes the session through without re-signing the certificate.
Comparison Table: SNI Domain Filtering vs. Full HTTPS Content Inspection
The following table summarizes when to deploy SNI filtering versus full deep packet inspection:
Criteria / Feature SNI Domain Filtering (No Decryption) Full HTTPS Content Inspection (DPI)
Primary Mechanism Reads unencrypted ClientHello SNI header (falls back to certificate CN) Terminates TLS, re-signs with CA, decrypts payload
Certificate Distribution Zero client certificates required Requires Proxy Authority CA on all endpoints (GPO)
Threat Protection Level Blocks known malicious domains only Scans full files, zero-day malware, scripts, and exploits
WebBlocker Granularity Categorizes base domains only Categorizes full URL paths and subdirectories
Performance Impact Near-zero latency; negligible CPU usage Requires cryptographic processing and stream buffering
Regulatory Risk Very low (No private user data decrypted) High unless sensitive categories are bypassed
Pinned App Compatibility 100% compatible (Never breaks pinned apps) Incompatible; pinned domains need Allow rules