WatchGuard Training

Network Security Essentials

for Locally-Managed Fireboxes
Study Guide
WatchGuard Locally-Managed Fireboxes

Guide Revised For: Fireware v12.11.2

Revision Date: March 2025
 About This Document
Information in this document is subject to change without notice. Companies, names, and data used in examples
herein are fictitious unless otherwise noted. No part of this document may be reproduced or transmitted in any form or
by any means, electronic or mechanical, for any purpose, without the express written permission of WatchGuard
Technologies, Inc.

Guide revised: 27 March 2025

Copyright, Trademark, and Patent Information

Copyright © 2025 WatchGuard Technologies, Inc. All rights reserved.
All trademarks or trade names mentioned herein, if any, are the property of their respective owners.

About WatchGuard Address

255 S. King St.
For 25 years, WatchGuard has pioneered cutting-edge cybersecurity
Suite 1100
technology and delivered it as easy-to-deploy and easy-to-manage
Seattle, WA 98104
solutions. With industry-leading network and endpoint security,
secure Wi-Fi, multi-factor authentication, and network intelligence
products and services, WatchGuard enables more than 250,000
small and midsize enterprises from around the globe to protect their Support
most important assets including over 10 million endpoints. In a world
where the cybersecurity landscape is constantly evolving, and new www.watchguard.com/support
threats emerge each day, WatchGuard makes enterprise-grade U.S. and Canada +877.232.3531
cybersecurity technology accessible for every company. All Other Countries +1.206.521.3575
WatchGuard is headquartered in Seattle, Washington, with offices
throughout North America, Europe, Asia Pacific, and Latin America.

For additional information, follow WatchGuard on social media. Also,

Sales
visit our InfoSec blog, Secplicity, for real-time information about the
U.S. and Canada +1.800.734.9905
latest threats and how to cope with them at www.secplicity.org.
All Other Countries +1.206.613.0895

Network Security Essentials for Locally-Managed Fireboxes Study Guide 2

 Contents

How to Use This Study Guide 7

Introduction 9
Firebox Management Types 10
Firebox Management Tools 11
Key Concepts 13
Firebox Setup and Management 20
Set Up a New Firebox 21
Configuration Files and Backup Images 27
Role-based Administration 32
Feature Keys 34
Upgrade a Firebox 37
Default Threat Protection 40
Global Settings and NTP 44
Policies Introduction 47
Logging, Monitoring, and Reporting 51
Logging and Notification 52
Types of Log Messages 54
Firebox Visibility with WatchGuard Cloud 57
Set Up Dimension for Firebox Logging 59
Configure Firebox Logging to Dimension 60
Monitoring with Firebox System Manager 61
Monitoring with Fireware Web UI 65
Read Traffic Log Messages in Traffic Monitor 68
Network Settings 72
Network Routing Modes 73
Interfaces 75
WINS/DNS in Mixed Routing Mode 79
Network Bridges 80
Secondary Networks 83

Network Security Essentials for Locally-Managed Fireboxes Study Guide 3

 VLANS 86
Static Routing 93
Multi-WAN 95
Link Monitor 97
Dynamic NAT 101
Static NAT (SNAT) 104
1-to-1 NAT 106
NAT Loopback 108
Firewall Policies 110
Policy Source and Destination 111
Management Policies 114
Limit Policy Scope 115
Policy Precedence 117
Policy Checker 119
Hidden Policies 120
Policy Logging and Notification 122
Policy Schedules 125
Packet Filters and Proxy Policies 126
Security Services 129
Security Services Overview 130
Intrusion Prevention Service 134
Application Control 136
Proxies and Proxy-Based Services 140
Proxies and Proxy Actions 141
AntiVirus Scanning and Proxies 144
APT Blocker 149
HTTP-proxy Policies and Proxy Actions 154
WebBlocker and the HTTP and HTTPS Proxies 161
HTTPS-proxy Policies 164
Content Actions and Routing Actions 173
Authentication 177
Authentication Servers 178

Network Security Essentials for Locally-Managed Fireboxes Study Guide 4

 Firebox Authentication 179
AuthPoint Authentication Server 183
Third-Party Authentication Servers 185
Users and Groups in Policies 187
Mobile VPN 190
Mobile VPN Introduction 191
Select a Mobile VPN Type 193
Mobile VPN with IKEv2 196
Mobile VPN with SSL 198
Setup Overview 200
Client Configuration Files 204
Mobile VPN Routing Options 206
Branch Office VPN 208
BOVPN Introduction 209
Topology 210
Fireware BOVPN Types 211
IPSec VPN Algorithms and Protocols 214
Policies and VPN Traffic 219
VPN Negotiations 221
BOVPN Configuration 225
BOVPN Virtual Interface Configuration 234
BOVPN and NAT 238
BOVPN and Dynamic Public IP Addresses 240
BOVPN Topologies 245
Troubleshoot BOVPN Tunnels 247
Additional Resources 255
Firebox Setup and Management Additional Resources 256
Logging, Monitoring, and Reporting Additional Resources 258
Network Settings Additional Resources 259
Firewall Policies Additional Resources 260
Security Services Additional Resources 261
Proxies and Proxy-Based Services Additional Resources 262

Network Security Essentials for Locally-Managed Fireboxes Study Guide 5

 Authentication Additional Resources 263
Mobile VPN Additional Resources 264
BOVPN Additional Resources 265
About the Network Security Essentials for Locally-Managed Fireboxes Exam 266
Exam Description 267
Sample Exam Questions 270

Network Security Essentials for Locally-Managed Fireboxes Study Guide 6

 How to Use This Study Guide

How to Use This Study Guide

This guide covers the Network Security Essentials for Locally-Managed Fireboxes course and is a resource to help
you study for the Network Security Essentials for Locally-Managed Fireboxes certification exam.

Use this guide in conjunction with instructor-led training, online video training and demos, and the WatchGuard Help
Center documentation to prepare to take the exam.

For a list of recommended resources to help you prepare for the exam, see Additional Resources.

For an introduction to important networking and security concepts, we recommend that you watch the Network and
Security Basics videos available in the Network Security Essentials for Locally-Managed Fireboxes course in the
WatchGuard Learning Center.

For information about the exam content and format, see About the Network Security Essentials for Locally-Managed
Fireboxes Exam.

WatchGuard provides training and online courseware to help you prepare for the Network
Security Essentials exam. In addition to this study guide, the training, and courseware, we
strongly recommend that you install, deploy, and manage one or more Firebox devices that run
Fireware v12.11.2 or higher before you begin the exam.

Document Conventions
This document uses these formatting conventions to highlight specific types of information:

This is a key point. It highlights or summarizes the key information in a section.

This is a note. It highlights important or useful information.

This is a best practice. It describes the recommended configuration for a Firebox feature.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 7

 How to Use This Study Guide

USE CASE:

This is a use case. It describes how you could configure the Firebox in a real-world scenario.

This is a caution. Read carefully. There is a risk that you could lose data, compromise system
integrity, or impact device performance if you do not follow instructions or recommendations.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 8

 Introduction

Introduction
The content in this Study Guide supports the Network Security Essentials for Locally-Managed Fireboxes technical
certification exam.

You can also configure Fireboxes for cloud management with WatchGuard Cloud. You can prepare for and earn your
Network Security Essentials technical certification by choosing one of two exams:
n Network Security Essentials for Locally-Managed Fireboxes
n Network Security Essentials for Cloud-Managed Fireboxes
You must only pass one exam to earn your Network Security Essentials technical certification. Technical training self-
study content and virtual instructor-led trainings are available for each exam. Make sure you select the correct study
content for the exam you want to take.

In this section you learn about:

n Firebox management types
n Firebox management tools
n Key concepts

WatchGuard provides training and online courseware to help you prepare for the Network
Security Essentials for Locally-Managed Fireboxes exam. In addition to this study guide, the
training, and courseware, we strongly recommend that you install, deploy, and manage one or
more Firebox devices that run Fireware v12.10.1 or higher before you begin the exam.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 9

 Introduction

Firebox Management Types

There are two ways to set up a new Firebox:
n Locally-managed — Use a setup wizard to configure the device. After initial configuration, use Fireware Web
UI or WatchGuard System Manager to manage the configuration.
n Cloud-managed — Add the Firebox to WatchGuard Cloud and configure it as a cloud-managed device. When
the Firebox starts with factory-default settings, it connects to WatchGuard Cloud to download its configuration.
In WatchGuard Cloud, you can also add a Firebox as a locally-managed device. You still manage the device
configuration in WSM, Fireware Web UI, or the Command Line Interface, but you can monitor live status, and
view log messages and reports for locally-managed devices you add to WatchGuard Cloud.

This guide describes how to use the setup wizards to configure a Firebox as a locally-managed device with basic
network settings and recommended policies.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 10

 Introduction

Firebox Management Tools

To manage and monitor a locally-managed Firebox, you can use one of these tools:
n WatchGuard System Manager > Policy Manager
n Fireware Web UI
n Fireware Command Line Interface (CLI)

You can also add your Firebox to WatchGuard Cloud as a cloud-managed device to manage
and monitor the device from WatchGuard Cloud. If you configure your Firebox as a cloud-
managed device, you cannot use the local device management tools. Configuration of cloud-
managed devices is outside the scope of this guide.

WatchGuard System Manager

WatchGuard System Manager (WSM) is the primary management tool used to monitor and manage Fireboxes and
WatchGuard servers. WSM is a software application that you install on a Windows computer. From WSM, you can
open Policy Manager to build a configuration file for a Firebox, entirely offline.

In WSM, you can:

n Pre-configure a Firebox — create a new configuration file that you later save to a Firebox
n Update an existing configuration, save your changes to a local file, and then deploy it to the Firebox when you
are ready
n Automatically save a backup copy of the configuration file to your computer when you save the configuration
to a Firebox
n Open a previously saved configuration file and save it to your Firebox
n Migrate a configuration from one Firebox to another Firebox

You can also use WSM to connect to a WatchGuard Management Server for centralized
management of Fireboxes. WatchGuard Management Server is outside the scope of this guide.

You install WatchGuard System Manager on a Windows management computer. To download the latest version of
WatchGuard System Manager, go to software.watchguard.com.

Fireware Web UI
Fireware Web UI is a browser-based management tool on the Firebox. You can connect to Fireware Web UI from the
web browser on any device on your local network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 11

 Introduction

Configuration changes you make in Fireware Web UI take effect immediately. Unlike WSM, you do not save changes
in a locally-stored configuration file and save them to the Firebox all at once. In Fireware Web UI you save each
change to the Firebox as you work.

When you save a configuration change to the Firebox from Fireware Web UI, the updated configuration file is not
saved automatically to a local file.

If you use Fireware Web UI to modify the configuration, we recommend that you manually
save a copy of the configuration to a file before and after you make significant changes.

Fireware Web UI can import existing XML configuration files that were saved from Web UI or
saved from Policy Manager with the Save As Version option.

Fireware Command Line Interface

Fireware also includes a Command Line Interface (CLI). You can use the CLI to manage the Firebox through a
network interface with an SSH connection on port 4118 or through the Firebox serial console port.

WatchGuard Cloud
In WatchGuard Cloud, you can add a Firebox as a locally-managed device. You manage the device configuration in
WSM, Fireware Web UI, or the Command Line Interface. You can monitor live status, and view log messages and
reports for locally-managed devices you add to WatchGuard Cloud.
WatchGuard Cloud supports this functionality for locally-managed devices:
n Initiate system actions (RapidDeploy, upgrade firmware, backup images, and reboot)
n Monitor live status (network status, routes, VPNs, users)
n View log messages and reports

ThreatSync is a WatchGuard Cloud service that provides eXtended Detection and Response
(XDR) technology for WatchGuard products. ThreatSync uses data from multiple security
products to detect and score malicious scenarios and present them as incidents in WatchGuard
Cloud. The ThreatSync user interface is designed primarily for Incident Responders, and
enables them to respond to incidents on-demand and configure automated responses to
malicious detections and abnormal behaviors.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 12

 Introduction

Key Concepts
To best use this study guide, you should understand these basic concepts of network security.

Internet Protocol (IP) Addresses

For one computer on the Internet to send data to a different computer, it must know the address of that computer. A
computer address is known as an Internet Protocol (IP) address. All devices on the Internet have unique IP
addresses, which enable other devices on the Internet to find and interact with them.

Fireboxes supports two versions of IP addresses in the global Internet:

IPv4
An IPv4 address consists of four octets (8-bit binary number sequences) expressed in decimal format and
separated by periods. Each number between the periods must be within the range of 0 and 255. Some
examples of IPv4 addresses are:
n 203.0.113.99
n 4.2.2.2
n 10.0.4.1

IPv6
An IPv6 address contains eight hextets (16-bit hexadecimal values, separated by colons). The hexadecimal
digits are not case-sensitive. Some examples of IPv6 addresses are:
n FE80:0000:0000:0000:0200:F8FF:FE21:67CF
n 2001:0DB8:0000:0000:5D11:D837:FC76:12FC
n fe80:0000:0000:0000:2045:FaeB:33AF:8374
The first four groups of 16-bit hexadecimal values represent the network. The last four groups of 16-bit
hexadecimal values are the interface ID that uniquely identifies each networked device. This value is usually
derived from the MAC address of the device.

Media Access Control (MAC) Addresses

A MAC address is the unique identifier assigned to a Network Interface Card (NIC) and is set by the manufacturer as
the physical address of each NIC. The address is a 48-bit hexadecimal address used for Layer 2 communication.
There are three types of MAC address:
n Unicast — Unique MAC address assigned to an interface
n Multicast — MAC address used for applications or protocols sent from one host to many
n Broadcast — MAC address that is sent to all devices within a local network

Network Security Essentials for Locally-Managed Fireboxes Study Guide 13

 Introduction

Address Resolution Protocol (ARP)

Address Resolution Protocol (ARP) is a protocol that associates the IP address with the MAC address of a network
device. When packet of data arrives for a host machine, the Firebox uses ARP to find the MAC address that matches
the IP address. The ARP cache maintains a list of each IP address and its corresponding MAC address.

Subnetting
For better security and performance, networks are often divided into smaller portions called subnets. All devices in a
subnet have similar IP addresses. For example, all devices that have IP addresses whose first three octets are 10.0.1
belong to the same /24 subnet.

The subnet mask for a network IP address, or netmask, is a series of bits that mask sections of the IP address that
identify which parts of the IP address are for the network and which parts are for the host. A subnet mask can be
written in the same way as an IP address, for example, 255.255.255.0.

When you configure an interface IP address for a Firebox or other network device, the device listens for connections
to that specific IP address. The subnet mask defines the local network connected to that interface, but the Firebox
listens for connections only to the configured interface IP address.

Routing
A route is the sequence of devices through which network traffic is sent. Each device in this sequence, usually called
a router, stores information about the networks it is connected to inside a route table. This information is used to
forward the network traffic to the next router in the route.

Routing processes direct traffic based on routing tables, which are typically seen in routers, firewalls, or intelligent
switches.

There are three types of routing:

n Static Routing — Sends packets through a manually created path to their destination.
n Default Routing — Sends all packets to the same hop unless a more specific route entry exists for a
destination.
n Dynamic Routing (RIP, OSPF, BGP, EIGRP) — Automatically adjusts routes, based on conditions advertised
between routing devices.

Private IP address ranges are not routable on the Internet.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 14

 Introduction

The Firebox automatically creates entries in the routing table for each subnet/network
configured on the interfaces. Traffic that the Firebox does not have a route for is dropped as IP
spoofing.

Network Address Translation (NAT)

Network Address Translation (NAT) is a term used to describe any of several forms of IP address and port translation.
At its most basic level, NAT changes the IP address header information of a packet from one value to a different
value.

The primary purposes of NAT are to increase the number of computers that can operate off a single publicly routable
IP address, and to hide the private IP addresses of hosts on your LAN. When you use NAT, the source IP address is
changed on all the packets you send.

Locally-managed Fireboxes support these types of NAT:

Static NAT (SNAT)

Allows inbound connections on specific ports to one or more public servers that use a single external IP
address. The Firebox changes the destination IP address of the packets and forwards them based on the
original destination port number. You can also translate the original destination port to an alternative port on
which the server is listening internally.

Dynamic NAT (DNAT)

Changes the source IP address of each outgoing connection to match the IP address of the Firebox interface
that the connection goes out through. For traffic that goes to an external network, packets go out through the
Firebox external interface, so dynamic NAT changes the source IP address to the Firebox external interface IP
address. The Firebox tracks the private source IP address and destination address, as well as other IP header
information such as source and destination ports, and protocol.

1-to-1 NAT
1-to-1 NAT creates a mapping between IP addresses on one network and IP addresses on a different network.
1:1 NAT is recommended only when you have many public IP addresses available, or your servers need to
initialize connections with the same public IP address on which they receive traffic.

VLANs
A virtual local area network (VLAN) is a collection of computers on a LAN or LANs that are grouped together in a
single broadcast domain independent of their physical location.

VLANs provide three main benefits:

n Increased performance by restricting broadcasts — Each computer you add to a LAN increases the amount
of background (broadcast) traffic, which can reduce performance. With VLANs, you can restrict this traffic and
reduce the amount of bandwidth used by your network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 15

 Introduction

n Improved manageability and simplified network tuning — When you consolidate common resources into a
VLAN, you reduce the number of routing hops necessary for those devices to communicate. You can also
manage traffic from each functional group more easily when each group uses a different VLAN.
n Increased security options — By default, members of one VLAN cannot see the traffic from another VLAN.
You can apply separate security policies to VLANs. By contrast, a secondary network on a Firebox interface
gives no additional security because there is no separation of traffic. The Firebox does not filter traffic between
the primary network of an interface and a secondary network on that interface. It automatically routes traffic
between primary and secondary networks on the same physical interface with no access restrictions.

TCP vs UDP
The two primary protocols at the transport layer are Transmission Control Protocol (TCP) and User Datagram
Protocol (UDP).

TCP
TCP is a connection-oriented protocol and is the most widely chosen option for transmitting data because it
can reliably send and receive data and provides extensive error checking mechanisms. Because of this, TCP
is slower than UDP. TCP is useful for web, mail, and FTP server activities.

UDP
UDP is a datagram-oriented protocol, which does not open, maintain and terminate connections. This type of
protocol is useful for voice/video calls, gaming, and streaming.

Important Protocols
Different applications and services require ports to communicate. Available ports range from 0 to 65535 and are
divided into three types.

Well-known
Well-known port numbers (0–1023), also known as standard or default ports, are permanently assigned to a
service or an application for consistency and easier troubleshooting.

Registered
Registered port numbers (1024–49151) can be registered by companies for their applications but can be used
more than once.

Dynamically Assigned
Dynamically assigned port numbers (49152-65535), also called ephemeral ports, are freely or dynamically
assigned, and are typically used as source ports for client connections.

The most known important protocols include:

n DHCP (Dynamic Host Configuration Protocol) — UDP (67/68), provides the ability to assign IP addresses
and other information to hosts on the network that are not statically configured

Network Security Essentials for Locally-Managed Fireboxes Study Guide 16

 Introduction

n DNS (Domain Name System) — TCP/UDP (53), translates human-readable domain names into routable IP
addresses for locating services and devices
n HTTP (Hyper Text Transport Protol) — TCP (80), used to load data from websites on the World Wide Web
into a browser with commands like “GET” or “POST”
n HTTPS (Hyper Text Transport Protol Secure) — TCP (443), used to load data from websites on the World
Wide Web into a browser with commands like “GET” or “POST”, but is encrypted through SSL/TLS (Secure
Socket Layer/Transport Layer Security)
n FTP (File Transfer Protol) — TCP (20/21), used to transfer data between clients and servers
n SSH (Secure Shell) — TCP (22), command line access to server and network equipment; provides secure
channel for communication
n Telnet — TCP (23), command line access to server and network equipment, unencrypted
n POP3 (Post Office Protocol) — TCP (110), email clients connect to a server to receive and store emails
locally on the device
n IMAP (Internet Message Access Protocol) — TCP (143), email clients connect to a server to retrieve emails,
but emails remain on the server so that multiple clients can access them simultaneously
n SMTP (Simple Mail Transfer Protocol) — TCP (25), used by email clients and email servers to send emails
n NTP (Network Time Protocol) — TCP/UDP (123), used to synchronize clocks on computers
n SNMP (Simple Network Management Protocol) — UDP (161), sed to share information between devices,
often through a central system that identifies and monitors devices to keep track of status changes

Encryption
Encryption protects sensitive data; it takes plain text data (such as an email or document) and uses a secret key to
encrypt it into an unreadable format, called cipher text. To decrypt the data, a key is required. Encryption keys are
created by algorithms that use a series of numbers. There are two types of cryptographic systems: symmetric and
asymmetric. Encryption methods are typically combined to provide optimal security and performance.

Symmetric
Symmetric uses the same key for encryption and decryption. Symmetric is more efficient but less secure than
asymmetric.

Asymmetric
Asymmetric uses two different keys for encryption and decryption. A private key is used to decrypt the data,
and a public key is used to encrypt the data. Both keys are mathematical in nature. Processing asymmetric is
more demanding, and is primarily used to exchange a symmetric key.

Certificates
Certificates match the identity of a person or organization with a method for others to verify that identity and secure
communications. They use an encryption method called a key pair, or two mathematically related numbers called the
private key and the public key. A certificate includes both a statement of identity and a public key, and is signed by a
private key.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 17

 Introduction

The private key used to sign a certificate can be from the same key pair used to generate the certificate, or from a
different key pair. If the private key is from the same key pair used to create the certificate, the result is called a self-
signed certificate. If the private key is from a different key pair, the result is a regular certificate. Certificates with
private keys that can be used to sign other certificates are called CA (Certificate Authority) Certificates. A certificate
authority is an organization or application that signs and revokes certificates.

If your organization has a PKI (public key infrastructure) set up, you can sign certificates as a CA yourself. Most
applications and devices automatically accept certificates from prominent, trusted CAs. Certificates that are not
signed by prominent CAs, such as self-signed certificates, are not automatically accepted by many servers or
programs, and do not operate correctly with some Firebox features.

Several certificates can be used together to create a chain of trust, which allows clients to trust anything signed by a
trusted CA.

Virtual Private Network (VPN)

VPN provides the ability to send data across unsafe or public networks (Internet) through tunnels so eavesdroppers
cannot read the data. VPN service providers provide a way to safely connect from public areas and hide traffic on the
Internet. There are two types of VPN:

Branch Office (Site-to-Site)

A branch office VPN (BOVPN) is an encrypted and authenticated connection between two networks.
Companies use a BOVPN to securely send data through an untrusted network such as the Internet. A BOVPN
connection is also known as a site-to-site tunnel.

Mobile (Remote Access or Host-to-Network)

Mobile Virtual Private Networking (Mobile VPN) creates a secure connection between a remote computer and
network resources behind the Firebox.

Locally-managed Fireboxes support these Mobile VPN types:

n Mobile VPN with IKEv2 — Mobile VPN with IKEv2 provides the best security, performance, and ease of
deployment. This VPN type uses IPSec for strong encryption and authentication. Users connect with
native Windows, macOS, or iOS VPN clients, or with the strongSwan app for Android. To authenticate
users, you can configure local authentication on the Firebox (Firebox-DB), RADIUS, and AuthPoint. If
your users authenticate with Active Directory, we recommend that you configure RADIUS authentication
so the Mobile VPN with IKEv2 can pass through Active Directory credentials.

We recommend Mobile VPN with IKEv2 in most cases.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 18

 Introduction

n Mobile VPN with SSL — Mobile VPN with SSL provides good security and performance, and uses a
default port (TCP 443) that is usually open on most networks. Mobile VPN with SSL uses Transport Layer
Security (TLS) to secure the connection. Windows and macOS users can download a client from
software.watchguard.com. Android and iOS users can download an OpenVPN client from an app store.
To authenticate users, you can configure local authentication on the Firebox (Firebox-DB), Active
Directory, RADIUS, AuthPoint, and SAML. Your Firebox can support Mobile VPN with IKEv2 and Mobile
VPN with SSL simultaneously.

We recommend Mobile VPN with SSL when remote networks do not allow IKEv2 IPSec traffic.

n Mobile VPN with L2TP — Mobile Virtual Private Networking (Mobile VPN) with L2TP (Layer 2 Tunneling
Protocol) creates a secure connection between a remote computer and the network resources behind the
Firebox. By default, Mobile VPN with L2TP uses IPSec to provide strong encryption and authentication.
Mobile VPN with L2TP supports connections from most L2TPv2 VPN clients that comply with the L2TP
RFC 2661 standard. Mobile VPN with L2TP supports local authentication on the Firebox (Firebox-DB)
and RADIUS authentication servers.
n Mobile VPN with IPSec — Mobile VPN with IPSec accepts connections from IPSec VPN client software
installed on a remote computer or device. The VPN client makes a secure connection from the remote
computer to your protected network through an unsecured network, such as the Internet. The Mobile VPN
client uses Internet Protocol Security (IPSec) to secure the connection. You can enable Mobile VPN with
IPSec for a group of users you have already created, or you can create a new user group. The users in
the group can authenticate either to the Firebox or to a third-party authentication server included in your
Firebox configuration.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 19

 Firebox Setup and Management

Firebox Setup and Management

To set up a new Firebox, you must know how to activate it, how to use the setup wizards, and how to use the
management tools.

In this section you learn about:

n Firebox activation and setup wizards
n Default policies and subscription services
n Firebox configuration files and backup images
n Feature keys
n Fireware OS upgrades
n Default Threat Protection
n Global settings and NTP
n Firewall policy basics

For a list of additional resources on these topics, go to Firebox Setup and Management Additional Resources.

WatchGuard provides training and online courseware to help you prepare for the Network
Security Essentials exam. In addition to this study guide, the training, and courseware, we
strongly recommend that you install, deploy, and manage one or more Firebox devices that run
Fireware v12.11.2 or higher before you begin the exam.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 20

 Firebox Setup and Management

Set Up a New Firebox

This guide describes how to use the setup wizards to configure a Firebox as a locally-managed device with basic
network settings and recommended policies.

The setup wizards configure:

n External (Eth0) and Trusted (Eth1) networks

n Passphrases for administrative user accounts

n Default policies and licensed security services to allow outgoing connections

The Firebox must have a feature key for the setup wizards to configure all features and licensed
services. The Firebox can automatically download the feature key, or you can manually add it
when you run the setup wizards.

Firebox Activation
Before you set up a new Firebox, you must activate it on the WatchGuard website. To activate your Firebox, go to
watchguard.com/activate.

To activate your Firebox, you must have:

n An account on the WatchGuard website — To create a new WatchGuard account, go to
https://accountmanager.cloud.watchguard.com/create-account.
n The Firebox serial number

After you activate your Firebox, copy and paste the feature key to a local file.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 21

 Firebox Setup and Management

Factory-Default Settings
A new Firebox ships with factory-default settings. You can also reset a Firebox to factory-default settings if
necessary.

Default Interface Settings

Ethernet 0 (Eth0) n External interface/ISP-facing interface

n Enabled as a DHCP client
n It is not required to connect Eth0 to a network when you run the setup
wizards, but it is recommended to enable more automated options in the
setup wizard

Ethernet 1 (Eth1) n Trusted interface

n IP address: 10.0.1.1/24
n Enabled as a DHCP server
n The Firebox assigns IP addresses on the 10.0.1.0/24 subnet to connected
computers (if the connected computer is configured as a DHCP client)

Ethernet 2 (Eth2) and n Optional interfaces

higher n Default interface IP addresses are 10.0.x.1/24 with x = interface number
n DHCP is disabled
n After the web setup wizard runs, these interfaces are disabled

Ethernet 24 (Eth24) — n Trusted interface

Firebox M4800 only n IP address: 10.0.24.1
n Enabled as a DHCP server, and configured to assign IP addresses on the
10.0.24.0/24 subnet
n When you run the Web Setup Wizard or Quick Setup Wizard, you must
connect your computer to interface 24 or to a network connected to
interface 24

Network Security Essentials for Locally-Managed Fireboxes Study Guide 22

 Firebox Setup and Management

Ethernet 32 (Eth32) — n Trusted interface

Firebox M5600 and 5800 n IP address: 10.0.32.1
only
n Enabled as a DHCP server, and configured to assign IP addresses on the
10.0.32.0/24 subnet
n When you run the Web Setup Wizard or Quick Setup Wizard, you must
connect your computer to interface 32 or to a network connected to
interface 32

Wireless — Firebox n In Fireware v12.5.3 and higher, wireless is enabled with these default Wi-Fi
wireless models only settings:
n SSID: Firebox model plus last part of the wireless MAC address.
n Password: Firebox serial number with the dash included.
n Wireless interface (Ath1) and Trusted interface (Eth1) are members of a
bridge that uses these default settings:
n Trusted interface
n IP address: 10.0.1.1/24
n Enabled as a DHCP server
n The Firebox assigns IP addresses on the 10.0.1.0/24 subnet to
connected computers (if the connected computer is configured as a
DHCP client)

With factory-default settings, the Firebox allows management connections on any trusted or optional interface.
Because Interface 1 (Eth1) is enabled as a DHCP server by default, we recommend you connect your management
computer to interface 1 to run the setup wizards. The Firebox also allows one outbound connection from the trusted
network to any external network.

For a wireless Firebox that runs Fireware v12.5.3 or higher, you can also connect through Wi-Fi to run the setup
wizard. See the sticker attached to the Firebox for the default Wi-Fi network SSID and password.

Setup Wizards
There are two setup wizards you can use to set up your Firebox.

Web Setup Wizard

When a Firebox starts with factory-default settings, you can connect to the Firebox and run the Web Setup
Wizard to set up the Firebox. You can run the Web Setup Wizard from any computer that has a web browser.

To start the Web Setup Wizard, in a web browser, type https://10.0.1.1:8080. If the external interface is
connected to a network with Internet access, the Web Setup Wizard can activate the Firebox and download
the required feature key.

Quick Setup Wizard

The Quick Setup Wizard is a component of WatchGuard System Manager that you can use to discover and set
up your Firebox. To start the Quick Setup Wizard, in WatchGuard System Manager, select Tools > Quick
Setup Wizard.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 23

 Firebox Setup and Management

The Quick Setup Wizard does not help you with device activation, but does provide some additional network
configuration options that are not available in the Web Setup Wizard, such as optional interface configuration.

With the Quick Setup Wizard, if you configure the external interface with a static IP address, you
can select the option to use the same IP address for the trusted interface. This configures the
Firebox in Drop-In mode.

To run either setup wizard you need:

n Feature key — The feature key is required for full Firebox functionality and enables the setup wizard to
automatically configure your subscription services.
o If Eth0 on the Firebox is connected to a network with Internet access, the setup wizards automatically

download the feature key from WatchGuard.

o If the Firebox does not have Internet access, you must copy the feature key manually and paste it into the
setup wizard. To get your feature key, log in to the WatchGuard Portal, select Support Center > Manage
Products, and search for your Firebox by serial number. On the Product Details page, click Get your
Feature Key.
n A computer with an Ethernet network interface card (or Wi-Fi to connect to a wireless Firebox that runs
Fireware v12.5.3 or higher)
n External network configuration (DHCP, Static, or PPPoE)
n Trusted network IP address — The IP address and DHCP pool for your internal network.

Before you run either setup wizard, connect your management computer to Eth1. Connect Eth0 to a network with
Internet access. By default, the external interface uses DHCP to request an IP address so the Firebox can connect to
the Internet.

To create a new configuration for a locally-managed Firebox, connect to the Firebox with one of the setup wizards,
and select the configuration method Locally-Managed. This is also called "Create New Configuration" in previous
versions of Fireware.

In both setup wizards, you configure basic network settings for Eth0 and Eth1, and set passphrases for the
administrative user accounts. The wizards configure policies and services with recommended settings to allow only
outgoing connections.

In Fireware v12.5.3 and higher, the setup wizards include options to configure wireless settings. The setup wizard
configure the wireless interface as a member of a trusted network bridge, which also contains interface 1. The bridge
uses the trusted network settings you configure in the setup wizard.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 24

 Firebox Setup and Management

Other Configuration Methods

The Web Setup Wizard includes these additional configuration methods:
n Cloud-Managed — Configure network settings so the Firebox can connect to WatchGuard Cloud to download
the configuration.
n RapidDeploy — Configure network settings so the Firebox can connect to WatchGuard to download a
configuration created for RapidDeploy.
n Restore from Backup Image — Restore the configuration from an exported backup image.

These options are not covered in this training.

Default Policies and Services

The setup wizards automatically create a new configuration with these default policies and services:

Default Policies
n FTP-proxy
n HTTP-proxy
n HTTPS-proxy
n WatchGuard Certificate Portal
n WatchGuard Web UI
n Ping
n DNS
n WatchGuard
n Outgoing

Enabled Services (if licensed in the feature key)

n WebBlocker
n Gateway AntiVirus
n Intrusion Prevention
n Application Control
n APT Blocker
n Botnet Detection
n Geolocation

The terms incoming and outgoing refer to whether a network connection is leaving or entering
the network protected by your firewall. Outgoing connections come from a protected network
and send traffic to an external network. Incoming connections come from an external network
and connect to a location in an internal (protected) network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 25

 Firebox Setup and Management

The default policies allow outgoing FTP, Ping, TCP and UDP connections, and do not allow incoming connections.
The default FTP, HTTP, and HTTPS proxy actions enable services and enable logging for reports.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 26

 Firebox Setup and Management

Configuration Files and Backup Images

Both configuration files and backup images are important for disaster recovery.

Configuration files and backup images have different content and uses.
n A configuration file contains device configuration settings, and can be used to restore an

earlier configuration or to migrate configuration settings from one Firebox to another

n A backup image contains the configuration file and other items unique to a specific
Firebox, and can be restored only to the same Firebox

Configuration Files
Firebox configuration settings are stored in a configuration file. When you edit the Firebox configuration with Policy
Manager, you also save the Firebox configuration to a local file.

A device configuration file includes all configuration data, options, IP addresses, and other
information for the Firebox. On the Firebox, the configuration file works with Fireware OS to
control the flow of traffic through the Firebox. The file extension for a device configuration file is
.xml.

In Fireware Web UI, each time you make a configuration change, the change is saved to the
Firebox immediately. From the Web UI you can also download the configuration to a
compressed configuration file (.gz). You can restore a previously downloaded configuration file.

In WatchGuard System Manager, you can create and save configuration files. You can restore
or copy a Firebox configuration file to multiple devices.

Before you make major changes to your Firebox configuration, we recommend that you save
a copy of your configuration file. If you have problems with your new configuration, you can
open the saved copy of the old configuration in Policy Manager and save it back to the
Firebox.

Configuration files do not include these elements that are unique to a specific device:
n Feature keys
n Users and passwords
n Certificates
n Firmware

Network Security Essentials for Locally-Managed Fireboxes Study Guide 27

 Firebox Setup and Management

You can copy or move a configuration file you create on one Firebox to another Firebox. You can even save the
configuration file to a different Firebox model. This is useful if you manage multiple devices and want to use the same
configuration.

If you migrate a configuration file from one Firebox to a different model with fewer interfaces,
make sure to review the network interface settings. If you save a configuration file to a model
with fewer interfaces than the original Firebox, the configuration settings for the additional
interfaces are removed.

In Policy Manager, you can select File > Save > As Version to save a configuration file for a specific Fireware
version. This is useful when you want to save a configuration file to a Firebox that runs a different version of Fireware
or use RapidDeploy (not covered in this guide).

To save a configuration file that you can restore through Fireware Web UI, you must use File
> Save > As Version when you save the file from Policy Manager.

Policy Manager
Policy Manager is the tool for offline configuration management. In Policy Manager:
n You can open the configuration file currently in use on the Firebox, or a configuration file saved on your
computer or network
n You can create a new configuration file
n Configuration changes you make in Policy Manager have no effect on Firebox operation until you save the
configuration to the Firebox

Each time you save configuration changes to the Firebox, Policy Manager saves a copy of the configuration to a local
file. By default, the file name is the same each time you save the configuration. You can change the file name so you
do not overwrite any previously saved configuration file. To configure Policy Manager to automatically save an
additional copy of the configuration file with a time stamp, select File > Save > Always create a backup.

Fireware Web UI
Fireware Web UI is a tool for web-based configuration of the Firebox. In Fireware Web UI:
n You connect directly to the Firebox to make configuration changes
n Configuration changes take effect on the Firebox immediately when you save each change
n A copy of the configuration file is not automatically saved to the management computer

To download the configuration file to a local file or restore a saved configuration, select System > Configuration File
> Download the Configuration File.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 28

 Firebox Setup and Management

Backup Images

A backup image is a file that contains your Firebox configuration file, device feature key, users,
certificates, and more. You can use a backup image to restore the Firebox to a previous state.
Backup images are saved in .fxi file format and are stored on the Firebox. You can also export a
backup image to your management computer for improved disaster recovery.

We recommend that you save a backup image of your Firebox before you upgrade the
firmware. Keep a record of the Firebox management IP address and the credentials for
management user accounts in the saved backup image. If you restore the backup image, you
will need this information to connect to the Firebox.

A backup image includes:

n Configuration file
n Certificates
n Passwords
n Feature key
n Other information unique to that Firebox

A backup image can only be restored to the device it was created from. You cannot use a
backup image to move configuration and settings from one device to another.

Automatic Backups with OS Upgrades

When you upgrade the version of Fireware OS on your Firebox, a backup image is automatically saved to the
Firebox. You can also use Policy Manager, Fireware Web UI, and WatchGuard Cloud (locally-managed Firebox) to
save a backup image of your Firebox.
n Policy Manager — File > Backup and Restore
n Fireware Web UI — System > Backup and Restore Image
n WatchGuard Cloud — Configure > Devices > Backup > Add Backup

Because available storage is limited, backup images stored on the Firebox do not include the Fireware OS. You can
always download different Fireware OS versions from software.watchguard.com. Backup images remain on the
Firebox until they are deleted manually or the Firebox is reset to factory-default settings.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 29

 Firebox Setup and Management

Export a Backup Image

You can export backup images from the Firebox to your computer or to a directory on your network or other
connected storage device. Because the backup image includes sensitive information, exported backup images are
encrypted with a password.

We recommend that you export a backup image before you reset your Firebox to factory-
default settings.

When you export a backup image, you can choose to include the Fireware OS. In some cases, this can make
restoration easier.

If you reset your Firebox to factory-default settings, all backup images are deleted from the
Firebox. If you want to reset the Firebox but do not want to delete the backup images, use the
CLI command restore factory-default without the all parameter.

Restore a Backup Image

Restore a saved backup image to restore your Firebox to a known previous state.

Do not try to restore a backup image created from a different Firebox. Each backup image is
unique to the device that created it. The backup image includes the certificates and private
keys for that device.

Because configuration settings vary by Fireware version, each backup image is compatible only with the version of
Fireware OS it was saved from. You can restore any backup image that was saved with the same version of Fireware
OS as the current OS version installed on the Firebox.
n To restore a backup image saved from a higher Fireware OS version, you must upgrade the OS on the
Firebox before you restore the backup image.
n To restore a backup image that was saved from a lower Fireware OS version, you must downgrade the
Firebox and select the backup image as part of the Fireware OS downgrade process.
n If your Firebox has been reset to factory-default settings, you can use the Web Setup Wizard or connect
directly to the Firebox with WatchGuard System Manager to restore an exported backup image.
n In WatchGuard Cloud (locally-managed Firebox), restore is only available for backup image files created with
Fireware v12.5.2 or higher. Backup images created with Fireware v12.5.1 or lower might be visible in
WatchGuard Cloud, but you cannot restore them.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 30

 Firebox Setup and Management

n In WatchGuard Cloud (locally-managed Firebox), if the Fireware OS version of the backup file is different from
the version installed on the Firebox, WatchGuard Cloud automatically upgrades or downgrades the OS on the
Firebox to the same version in the backup image.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 31

 Firebox Setup and Management

Role-based Administration

You can use role-based administration to share configuration and monitoring responsibilities for
your Firebox between several people in your organization. Create separate user accounts for
each administrative user so that you can run audit reports to monitor who makes changes to
your device configuration.

The user role of an administrative user account determines whether the user can save changes to the device
configuration. By default, your Firebox includes these default user accounts and roles:

Default User Account Default Role Default Passphrase

admin Device Administrator (read-write permissions) readwrite

status Device Monitor (read-only permissions) readonly

In Fireware v12.10 or higher, the wg-support user account is no longer a default account. You
can add and edit an account named wg-support.

We recommend you add separate accounts for each user who can log into the Firebox.
Assign each user a role that determines their level of access.

Administrative Roles
Log in as a Device Administrator to manage users and roles in Firebox System Manager or Fireware Web UI.
n In Firebox System Manager — Tools > Manage Users and Roles
n In Fireware Web UI — System > Users and Roles

For each administrative user, the role determines the permissions.

Role Permissions

Device Administrator (read-write permissions) Can see the configuration and save changes

Device Monitor (read-only permissions) Can see the configuration but not save changes

Guest Administrator Can only manage hotspot guest user accounts

Network Security Essentials for Locally-Managed Fireboxes Study Guide 32

 Firebox Setup and Management

More than one Device Monitor can connect to the Firebox at the same time. But, if you want to
allow more than one Device Administrator to log in to the Firebox at the same time, you must
enable an option in the Global Settings. For more information about Global Settings, see Global
Settings and NTP.

Authentication Servers
By default, administrative users are stored in the Firebox-DB authentication server. You can also specify users on an
external third-party authentication server, such as Active Directory.

You can specify users on any of these authentication servers:

n Firebox-DB
n Active Directory
n LDAP
n RADIUS
n SAML
n SecurID

For external authentication servers (not Firebox-DB), make sure to add the user account to the authentication server
before you add the user account to your Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 33

 Firebox Setup and Management

Feature Keys
A new Firebox ships in a factory-default state with no feature key installed. You must activate the Firebox to get the
feature key that enables licensed features and services.

Without a feature key:

n The Firebox allows only one device to have an outbound connection to the Internet

n You cannot upgrade Fireware OS

n You cannot enable licensed subscription services
n You cannot enable features like dynamic routing, VPN, multi-wan, and more

A feature key enables a set of licensed features on your Firebox. When you get a new device, you activate the device
on the WatchGuard website to create a feature key and then install the feature key on your device to enable all the
device functions. You can add the feature key to your Firebox from the Quick Setup Wizard, Web Setup Wizard,
Policy Manager, or the Fireware Web UI. The setup wizards download the feature key for an activated Firebox
automatically.

When you activate a new service, upgrade, or renewal for your Firebox on the WatchGuard website, an updated
feature key is created. You must update your Firebox with the new feature key before you can configure the licensed
features.

The feature key includes a line item for each licensed feature or service. Some features, such as service
subscriptions, have expiration dates. Those features expire and stop working on the specified expiration date. If a
feature line has an expiration date of never, it will never expire and will always work.

To install Fireware updates, the Firebox must have a feature key with an active support
subscription. This is called LiveSecurity Service in the feature key.

Automatic Feature Key Synchronization

Make sure the Automatic Feature Key Synchronization setting is enabled to automatically add
new services launched as part of Total Security.

Automatic Feature Key Synchronization enables the Firebox to automatically check for a feature key update when
services in the current feature key will expire within 7 days. Automatic Feature Key Synchronization is enabled by
default to ensure your services are not interrupted when you renew your subscriptions. Synchronization also
automatically adds any new services launched as part of the Total Security Suite.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 34

 Firebox Setup and Management

Every 12 hours, the Firebox checks to see if any feature in the feature key will expire within 7 days. If so, the Firebox
automatically downloads the latest feature key from WatchGuard every 12 hours, until it successfully downloads a
feature key with no expired features.

When you manage the Firebox, you see warnings in these locations if a feature key will expire soon:
n Fireware Web UI Front Panel — Shows a feature key expiration warning message in the upper-right corner
n Policy Manager — Shows a warning when you save a configuration file if a feature expires within 90 days

Warnings also appear in the feature key when you manage the feature key in Policy Manager.

Manage Feature Keys

To manage the feature key, in Policy Manager, select Setup > Feature Key.

From here, you can click Details to see the actual text in the feature key file.

If you need to restore the feature key, you can copy and paste the feature key details from a saved configuration file
or the WatchGuard Portal into the Firebox configuration.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 35

 Firebox Setup and Management

Feature Key File

The feature key details are not stored in the configuration file. In Policy Manager, when you save a copy of the device
configuration to a local file, the feature key is saved in a separate file with the extension *_lic.tgz in the same
location.

For example, if you save a device configuration with the file name Example, Policy Manager saves two files:
n Example.xml — the device configuration file
n Example_lic.tgz — the device feature key

Network Security Essentials for Locally-Managed Fireboxes Study Guide 36

 Firebox Setup and Management

Upgrade a Firebox
To keep your Firebox up to date with the latest security features, you must periodically upgrade Fireware OS.

There are three methods to upgrade Fireware OS on a Firebox:

n Policy Manager — Can be an efficient method to upgrade many Fireboxes

n Fireware Web UI — Easier to use if you only have a few devices to upgrade
n WatchGuard Cloud — Upgrade a locally-managed Firebox from WatchGuard Cloud

Before You Upgrade

Before you upgrade Fireware OS, make sure you understand what is in the update, and that you
have the necessary files to downgrade to the previous version if something goes wrong.

n Read the Release Notes — these include any special upgrade considerations
n Save a copy of the configuration file
n Save a backup image
n Schedule the upgrade for a planned maintenance window — the Firebox reboots after the upgrade

Upgrade Fireware from Policy Manager

If you use WatchGuard System Manager to administer your Fireboxes, you must upgrade WatchGuard System
Manager before you upgrade the Fireboxes it manages. The version of WatchGuard System Manager you use must
be the same as, or higher than, the version of Fireware OS on any Firebox it manages.

Before you use Policy Manager to upgrade a Firebox, download and install these upgrade files to your management
computer:
n WatchGuard System Manager — Installs WSM management software, including Policy Manager
n Fireware OS — Installs the OS upgrade image that Policy Manager uses to upgrade the Firebox

The Fireware OS upgrade file is different for each Firebox model. If you manage multiple
Firebox models, you must download and install a separate Fireware OS upgrade file for each
model.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 37

 Firebox Setup and Management

To upgrade the Firebox from Policy Manager, select File > Upgrade. Policy Manager asks you to save a copy of your
configuration. It also saves a backup image automatically before the upgrade starts.

Upgrade Fireware from Fireware Web UI

In Fireware Web UI, the upgrade process is simpler, and the Firebox can download the upgrade directly from
WatchGuard. The Upgrade OS page shows whether a new OS version is available.

To download and install an OS upgrade, select an available version. If needed, you can also select an OS upgrade
file you have downloaded to your management computer. The upgrade process automatically saves a backup image
to the Firebox before the upgrade starts.

After you upgrade a Firebox from Fireware Web UI, you must still upgrade WatchGuard System Manager before you
can open the Firebox configuration with Policy Manager.

Upgrade Firmware from WatchGuard Cloud

You can upgrade the firmware for a locally-managed Firebox in WatchGuard Cloud. You can upgrade the firmware
immediately or schedule the upgrade for a future time.

An individual Firebox must run Fireware v12.5.2 or higher to be able to update the firmware
from WatchGuard Cloud.

From WatchGuard Cloud, select Configure > Devices > Firmware Upgrades. In the Firmware Upgrades window,
click Upgrade Firmware.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 38

 Firebox Setup and Management

For locally-managed Fireboxes, the Firebox automatically creates a backup when you upgrade the firmware from
WatchGuard Cloud.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 39

 Firebox Setup and Management

Default Threat Protection

With default threat protection, the firewall examines the source and destination of each packet it receives. It looks at
the IP address and port number and monitors the packets to look for patterns that show your network is at risk. If a
risk exists, you can configure the Firebox to automatically block a possible attack.

Default Threat Protection has three configurable components:

n Blocked Ports
n Blocked Sites
n Default Packet Handling

Default Threat Protection is the first line of defense, and takes precedence over configured policy rules and other
services.

Blocked Ports
By default, the Blocked Ports list includes several ports related to known threats. You can also manually block the
ports that you know can be used to attack your network. This stops specified external network services from
connecting to your network. Blocking ports can protect your most sensitive services.

When you block a port, you override all the rules in your policy definitions.

The Firebox blocks inbound traffic from external sources that use the blocked ports, but these ports are not blocked
for outbound traffic.

WatchGuard recommends you review the default Blocked Ports list to make sure it does not
block ports required for services you want to allow on your network.

Blocked Sites
A blocked site is an IP address that cannot make a connection through the Firebox, regardless of the configured
policies. Sites can be permanently blocked or temporarily blocked. You can configure exceptions for sites you never
want the Firebox to block.

The Firebox sends a log message each time a blocked site tries to connect to your network. In the log file, you can
see the services that the sources use to launch attacks.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 40

 Firebox Setup and Management

Permanently Blocked Sites

The Firebox denies connections to or from sites that are permanently blocked.

You can configure the Firebox to block the IP addresses of specific sites that are sources of suspicious traffic.
Permanently blocked sites are the sites you add to the Blocked Sites list in the Firebox configuration.
n No sites are blocked by default, so you must add them manually.
n The Firebox blocks connections to and from sites on the Blocked Sites list.
n You can block by IP address, network address, host name, or FQDN.

Adding the FQDN of a site that has a large number of domain names and changing IP
addresses (such as Facebook) to the Blocked Sites list, is generally not an effective way to
block traffic for those sites. WebBlocker is a more effective method to block applications such
as Facebook.

Temporarily Blocked Sites

The Firebox denies connections from sites that are temporarily blocked, but does not deny
connections to these sites.

In addition to the permanently blocked sites you configure on the Blocked Sites list, the Firebox can also auto-block a
site, which adds the site to the Blocked Sites list with an expiration time. Auto-blocked sites are temporarily blocked
until the expiration time elapses. The Firebox denies connections from auto-blocked sites, but does not block
connections to auto-blocked sites.

The Duration for Auto-Blocked Sites setting specifies how long auto-blocked sites remain on the Blocked Sites list.
The default duration is 20 minutes. Each time the Firebox blocks traffic from a blocked site, the expiration time for the
block resets. You can think of the auto-block duration as a rolling duration, used to reset the expiration time of the
auto-blocked site.

The Firebox can auto-block sites based on triggers in the configuration. For example:
n Proxy actions and services configured with the Block action

n Default Packet Handling thresholds and settings with the Block action

You can also manually add temporarily blocked sites to the Blocked Sites list, and specify the expiration time. In
Fireware Web UI or Firebox System Manager, you can edit the expiration time for an auto-blocked site:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 41

 Firebox Setup and Management

n Fireware Web UI — System Status > Blocked Sites

n Firebox System Manager — Blocked Sites tab.

When you reboot the Firebox, any temporarily blocked sites are removed from the Blocked Sites list.

Blocked Sites Exceptions

This feature is typically used for internal hosts and servers that you never want on the Blocked
Sites list. For sites on the Blocked Sites Exception list, the Firebox bypasses Default Packet
Handling checks except IP Spoofing and IP Source Route attacks.

If the Firebox blocks connections to a site you believe to be safe, you can manually add the site to the Blocked Site
Exceptions list. Use this option carefully, because the Firebox bypasses Default Packet Handling checks for sites on
the Blocked Site Exceptions list (except for IP Spoofing and IP Source Route attacks).

By default, the Blocked Sites Exceptions list includes default exceptions for servers that WatchGuard products and
subscription services must connect to.

Default Packet Handling

Default packet handling automatically drops or blocks traffic that matches the pattern of well-
known network attacks, such as Denial-of-Service attacks, SYN flood attacks, and port scans.

When your Firebox receives a packet, it examines the IP address and port number of the packet source and
destination. The device monitors the packets to identify patterns that can show your network is at risk. This process is
called default packet handling.

To make sure that default packet handling does not affect traffic from your email server or any
other server that has a high volume of traffic, add the server to the Blocked Sites Exceptions list.

Default packet handling can:

n Reject a packet that could be a security risk, including packets that could be part of a spoofing attack or SYN
flood attack.
n Automatically block all traffic to and from an IP address.
n Throttle a Distributed Denial-of-Service attack.
n Add an event to the log file.
n Send an SNMP trap to the SNMP management server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 42

 Firebox Setup and Management

n Send a notification of possible security risks.

n Block or drop traffic for dangerous activities by default.
o Each option is described as a Drop or Block action:
o Drop — Drops the connection

o Block — Drops the connection and adds the site to the auto-blocked sites list
o For most attack types, the Firebox drops the traffic but does not auto-block the site.
o For Port Scans and IP Scans, the Firebox auto-blocks the source IP address.
o You can configure the thresholds for flood attacks and quotas.

Unhandled Packets
An unhandled packet is a packet that does not match any configured firewall policy. By default, the Firebox denies all
unhandled packets and generates a log message. The source of unhandled packets is not auto-blocked by default.

To automatically block all incoming connections from sites that send unhandled packets, in the Default Packet
Handling settings, select Auto-block source IP of unhandled external packets.

Use this option with caution. This causes the Firebox to block all traffic from a remote host if a
packet, such as a ping request, does not match a firewall policy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 43

 Firebox Setup and Management

Global Settings and NTP

Global settings, time zone, and Network Time Protocol (NTP) settings affect the overall operation of the Firebox.

Global Settings
In Global Settings, you can configure general settings, global networking settings, and the logon disclaimer.

General Settings
Web UI Port
Specifies the port you use to connect to Fireware Web UI. By default, Fireware Web UI uses port 8080.

Automatic Reboot
Schedule a daily or weekly reboot of the Firebox. A reboot can free up RAM or CPU and can help maintain
healthy operation.

Device Feedback
This setting enables the Firebox to send feedback to WatchGuard. WatchGuard uses device feedback to
improve products and features and to populate our Internet Security Report. Device feedback includes
subscription service statistics, but does not include any information about your company or any company data
that is sent through the Firebox. All device feedback sent to WatchGuard is encrypted.

Fault Report
Enable this setting to automatically send fault reports to WatchGuard once each day. All fault reports sent to
WatchGuard are encrypted. Your Firebox collects and stores information about the faults that occur on your
Firebox and generates diagnostic reports of the fault. Faults are collected for these categories:
n Failed assertions
n Program crashes
n Kernel exceptions
n Hardware problems

Device Administrator Connections

If this setting is disabled, only one Device Administrator at a time can make changes in any of the management
interfaces. Enable this setting to allow multiple users with the Device Administrator role to log in to the Firebox
at the same time. When this setting is enabled, Device Administrators who log in to Fireware Web UI must
unlock the configuration file in each page before they can make changes.

Traffic Generated by the Firebox

This setting enables you to see and configure policies that control traffic generated by the Firebox. This setting
is disabled by default. In most cases, we recommend that you do not enable this setting.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 44

 Firebox Setup and Management

This setting has a high impact on the operation of the Firebox. Before you enable this setting,
read the documentation to make sure you understand the changes that occur when you
enable it. If you enable this setting, incorrect policy configuration can cause serious problems
with the operation of the Firebox. For example, you could lose the ability to connect to your
Firebox for management, or you could cause subscription services to fail.

Networking Settings
Many global networking settings have defaults set to recommended values. We recommend that you keep the default
settings unless you have a specific reason to adjust them. There is one setting you must change if you want to
configure Traffic Management and QoS (quality of service) networking features.

Traffic Management and QoS

We do not recommend that you enable this setting unless you need to implement traffic management and QoS
on the Firebox. When you enable this setting, there will be a high impact on the performance of the Firebox.
For performance testing or network debugging purposes, you can disable the Traffic Management and QoS
features.

There is one other setting you might want to change, to improve the reliability of Path MTU (PMTU) discovery.

TCP MTU Probing

This option is disabled by default. You can change the TCP MTU Probing setting to Enabled only when
ICMP network issues are detected to enable the Firebox to use TCP MTU probing as a secondary method
when ICMP probing fails. This change improves network reliability if your network has ICMP network issues,
and has no negative impact when no ICMP network issues are detected.

Logon Disclaimer
Enable the logon disclaimer to specify a message with terms and conditions that users must agree to before they can
log in to manage the Firebox. In Policy Manager, you configure this in the Global Settings. In Fireware Web UI, this is
a separate system setting.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 45

 Firebox Setup and Management

Time Zone and NTP (Network Time Protocol)

NTP servers synchronize the time for your network. NTP is enabled by default on the Firebox. When NTP is enabled,
the Firebox contacts an NTP server to synchronize the time. It sets the time based on the time zone specified in the
Firebox system settings. You select the time zone when you run the setup wizards to configure your Firebox. You can
also change the time zone in the System Settings. (Setup > System in Policy Manager).

It is important for the Firebox to have accurate time so that log messages correctly show when events occurred.
Accurate time is also critical for:
n Certificates
n VPNs
n Subscription services
n Feature key updates

When NTP is enabled, you can optionally enable your Firebox as an NTP server so that clients on your private
networks can contact your Firebox to synchronize the time.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 46

 Firebox Setup and Management

Policies Introduction

A firewall policy allows or denies connections that match these policy configuration settings:
n From and To — the traffic source and destination
n Port and Protocol — the traffic type

The default firewall policies allow outbound connections to the Internet from the protected
network, and deny connections from the Internet to the protected network.

When you add a policy to your Firebox configuration, you control what types of traffic the Firebox allows or denies.
You can set a policy to allow or deny traffic based on criteria such as the source and destination of the packet, the
TCP/IP port or protocol used to transmit the packet, or the time of day. In the policy settings you can give the Firebox
more instructions on how to handle the packet. For example, you can define logging and notification parameters for
the policy, or use network address translation (NAT).

Firewall policies can help you meet several objectives. Here are some common ones:

Define allowed connectivity on your network

n Define what types of connections are allowed
n Allow connections from specific sources to specific destinations
n Allow internal traffic between local interfaces

Protect your network from threats

n Identify and block viruses, botnets, and other malware
n Drop or block connections based on the content of the IP header or packet content
n Deny connections to sites with a bad reputation

Enforce your organization’s computer use policy

n Control access to social media sites
n Prevent the download of specific file types
n Control the types of applications that operate on your network
n Restrict types of traffic to specific hours

Enable different levels of access or set bandwidth limits for different users
n Set different policies by department or user role
n Allow guests to safely connect to the Internet

To meet some of these objectives, you must enable and configure security services in your policies. For example, you
use Application Control to control applications used on your network. If your Firebox has licensed services, many
services are enabled by default. You can update the default policies and services to control the types of traffic you
want to allow on your network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 47

 Firebox Setup and Management

Default Firewall Policies

The default firewall policies prevent inbound connections to your protected network, and safely allow outbound
connections to the Internet from the protected network. You can further customize the policies and other configuration
settings based on the requirements for your network.

To and From Fields

Each policy has a source and a destination:
n The From list specifies the sources of connections the policy applies to.
n The To list specifies the destinations of connections the policy applies to.

The source and destination for the policy can be a host IP address, host IP range, host name, network address, user
name, group, alias, VPN tunnel, FQDN, or any combination of these objects. A destination can also be a static
NAT action.

A policy that allows connections initiated from a source to a destination also allows response
traffic from the destination back to the source. You do not need to add a separate policy to allow
response traffic from a destination back to the source that initiated the connection.

The terms incoming and outgoing refer to whether a network connection is leaving or entering the network protected
by your firewall. Outgoing connections come from a protected network and send traffic to an external network.
Incoming connections come from an external network and connect to a location in an internal (protected) network.

Disposition
The disposition specifies whether connections that match the policy settings are allowed or denied. To configure the
disposition, select one of these settings:
n Allowed — The Firebox allows traffic that matches the rules in the policy.
n Denied — The Firebox drops all traffic that matches the rules in the policy and does not send a notification to
the device that sent the traffic.
n Denied (send reset) — The Firebox denies all traffic that matches the rules in the policy and sends a
notification, such as TCP RST or ICMP error, to the device that sent the traffic.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 48

 Firebox Setup and Management

Port and Protocol

Each policy applies to traffic that uses a specific port and protocol. In the policy list, the Port column shows the port
and protocol each policy applies to. For example, the FTP-Proxy policy templates create policies that apply to
TCP traffic on port 21.

Policy Templates

You use policy templates to add a new policy. Policy templates define the port and protocol a
policy applies to. You cannot edit the port and protocol within a policy. To add a policy for a
custom protocol or port you must create a custom policy template.

You cannot edit default policy templates.

You can edit custom policy templates, even after policies have been created based on them.
Changes you make to the ports or protocols in a custom policy template automatically
propagate to any policies that were created from that template.

Policy templates make it easy to add policies for many traffic types that use standard ports and protocols. When you
add a firewall policy, you select a policy template that defines what type of traffic the policy applies to. Fireware
includes many predefined templates. When you select a template, you can see the ports and protocol the policy
applies to.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 49

 Firebox Setup and Management

After you select a template and add a policy, you edit the policy settings to meet your needs. When you edit the policy,
you cannot change the port and protocol defined in the policy template.

If you want to create a policy that applies to a protocol that is not included in the list of predefined policy templates,
you must create a custom policy template. A custom policy can match traffic from one or more TCP or UDP port.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 50

 Logging, Monitoring, and Reporting

Logging, Monitoring, and Reporting

The Firebox can generate log messages and notifications to help you monitor network activity.

In this section you learn about:

n Logging and notifications
n Log messages and types
n Firebox visibility with WatchGuard Cloud
n How to set up Dimension for Firebox logging
n How to log to Dimension
n Monitoring with Firebox System Manager
n Monitoring with Fireware Web UI
n How to read Traffic Log messages

For a list of additional resources on these topics, go to Logging, Monitoring, and Reporting Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 51

 Logging, Monitoring, and Reporting

Logging and Notification

Logging is the process of recording the activity that occurs on a Firebox. For example, when your Firebox denies a
packet, this event is recorded as a log message in the log file. Notification is the process of informing an administrator
when a specified activity occurs.

When the Firebox detects a threat that you have configured for notification, such as a port space probe, it generates
an alarm log message. You can configure Dimension or WatchGuard Cloud to send an email notification to the
network administrator for alarm log messages. When the administrator receives the notification message for a threat,
they can examine the log files and decide how to make the network more secure. For example, the administrator
could decide to block the ports that the probe targeted, block the IP address that sent the packets, or contact the
Internet Service Provider through which the packets were sent.

The Firebox can send log messages to these types of servers:

n WatchGuard Cloud
n Dimension Server
n Syslog Server
n WatchGuard Log Server (supports fewer reports)

Logging and Notification Components

The WatchGuard logging and notification system includes these components:

Fireboxes and WatchGuard Servers

A Firebox generates log messages for each event that occurs. You can configure a Firebox to send log
messages to WatchGuard Cloud or Dimension. If an event has a notification action associated with it, the
Firebox sends an Alarm log message so that WatchGuard Cloud or Dimension can notify the administrator.

WatchGuard Servers, such as the Management Server, also generate log messages. WatchGuard Servers
can send log messages to Dimension or a local file.

WatchGuard Cloud
WatchGuard Cloud is a cloud-based visibility platform that collects log messages and automatically generates
dashboards and reports based on the log data. WatchGuard Cloud includes some reports that are not
available in the other monitoring and reporting tools. When you add a Firebox to WatchGuard Cloud, the
Firebox sends log messages to WatchGuard Cloud in addition to any other log servers you configure.
WatchGuard Cloud can also send an email notification message when it receives an alarm from the Firebox.

Dimension
WatchGuard Dimension integrates with your Fireboxes to provide a flexible, cloud-ready logging, reporting,
and management solution. You deploy Dimension as a Hyper-V or VMware virtual machine (VM).

Network Security Essentials for Locally-Managed Fireboxes Study Guide 52

 Logging, Monitoring, and Reporting

Dimension can collect log messages from your Fireboxes and WatchGuard Servers. Your Firebox can send
log messages to one or more Dimension servers at the same time. Dimension can also send an email
notification message when it receives an alarm from the Firebox.

Syslog Server
In addition to any other configured log servers, Fireboxes can send log messages to a third-party syslog server
or keep a limited number of log messages locally.

WatchGuard Log Server

WatchGuard Log Server is a component of WatchGuard Server Center that collects log messages that the
Report Server can use to generate reports.

WatchGuard Log Server and Report Server are not covered in this training.

WatchGuard Log Server and Report Server do not generate reports or notifications for security
services and features added in Fireware version 11.8 or higher, such as APT Blocker. Because
security services require alerts and reports to be fully effective, we recommend you use
Dimension or WatchGuard Cloud to monitor your Fireboxes.

You can configure a Firebox to send log messages to multiple locations at the same time. For example, a Firebox can
send log messages to WatchGuard Cloud, Dimension, and a syslog server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 53

 Logging, Monitoring, and Reporting

Types of Log Messages

As part of a good network security policy, it is important to collect log messages from your security systems, examine
those messages frequently, and keep them in a log file archive. You can use these log files to monitor your network
activity, and to identify and address any security risks.

A Firebox sends five types of log messages: Traffic, Alarm, Event, Debug, and Statistic. Each log message includes
the name of the log type as part of the log message.

Traffic Log Messages

The Firebox sends traffic log messages as it applies packet filter and proxy policy rules to traffic that goes
through the device.

For the Firebox to generate log messages for allowed traffic, you must enable logging of
allowed traffic in packet filter policies or logging for reports in proxy policies. Logging of allowed
traffic is enabled by default in the policies created by the Firebox setup wizards.

For packet filter policies that allow traffic, you can separately select to send log messages for logging purposes
(which you can see in Traffic Monitor or Log Manager) or only for reporting purposes (these log messages are
only used in reports and do not appear in Traffic Monitor).

For proxy policies, when logging for reports is enabled, log messages for allowed traffic appear in Traffic
Monitor.

Alarm Log Messages

The Firebox sends alarm log messages when an event occurs that causes the Firebox to send a notification
request.

Event Log Messages

The Firebox sends event log messages when a device administrator completes tasks, when the device starts
up or shuts down, and when problems occur with the device hardware components.

Debug Log Messages

Debug log messages include information used to help troubleshoot problems. You can select the level of
debug log messages to see in Traffic Monitor and you can change the Diagnostic Log Level settings in the
Firebox configuration.

Statistic Log Messages

Statistic log messages include information about the performance of your Firebox. By default, the Firebox
sends log messages about external interface performance and VPN bandwidth statistics. These log messages
can help you determine how to change your Firebox settings to improve performance.

For more information about log messages, see the WatchGuard Log Catalog, available on the WatchGuard Firebox
Documentation page.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 54

 Logging, Monitoring, and Reporting

Log Files
The Firebox can send log messages to WatchGuard Cloud or Dimension. For Dimension, log messages are stored in
a local PostgreSQL database. You can also select to use an external PostgreSQL database.

Diagnostic Log Levels

You can set the diagnostic log level for different categories of log messages. The available levels, from lowest to
highest are:
n Off — No diagnostic log messages are sent for this category.
n Error — Includes log messages for serious errors that cause a service or process on the Firebox to terminate.
This log level also includes log messages for branch office VPN (BOVPN) errors.
n Warning — Includes details of abnormal conditions that help to explain behavioral process issues, as well as
the information from the Error level.
n Information — Includes details of successful operation for log messages, as well as the information from the
Error and Warning levels.
n Debug — Includes detailed log messages for all log levels. Use only with direction from a WatchGuard
technical support representative.

By default, the diagnostic log level for all log message types is set to Error.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 55

 Logging, Monitoring, and Reporting

To see more information about traffic and events on the Firebox, you can increase the diagnostic log level. This can
be helpful for troubleshooting.

Use the Debug log level for troubleshooting only. The Debug log level generates a large
number of log messages which can fill the log database more quickly in Dimension. Debug
logging can also impact the performance of the Firebox. After you finish troubleshooting,
reset the diagnostic log level back to the default Error level.

The Diagnostic Log Level settings include two options that enable logging for traffic that originates from the Firebox
itself. These options enable logging in the hidden Any From Firebox policy.
n Enable logging for traffic sent from this device — Enables the Firebox to send log messages for traffic the
Firebox sends.
n Enable logging for reports for traffic sent from this device — Enables the Firebox to send log messages
about traffic the Firebox sends that can be used to generate reports.

These settings are disabled by default.

When these settings are enabled, the additional log messages can make reports confusing
or misleading. We recommend you only enable these settings temporarily for
troubleshooting.

For more information about hidden policies, see Hidden Policies.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 56

 Logging, Monitoring, and Reporting

Firebox Visibility with WatchGuard Cloud

You can add a Firebox to WatchGuard Cloud for visibility to enable cloud-based monitoring and reporting.
WatchGuard Cloud uses log messages from the Firebox to automatically generate dashboards and reports.

Firebox logging to WatchGuard Cloud is controlled separately from the other logging settings. You can also configure
the Firebox to send log messages to Dimension Servers in addition to WatchGuard Cloud.

You can use these features in WatchGuard Cloud to monitor a Firebox. Most of these features are also available in
Dimension.

Logs
See and search Firebox log messages.

Dashboards
See summary information about traffic, threats, and activity for a Firebox.
n Executive Summary — A concise report of the attacks and traffic blocked by the Firebox. Available as a
PDF only from the Device Summary page.
n Executive Dashboard — A summary of traffic through the selected Firebox, cluster, or group.
n Security Dashboard — A summary of the top threats in each security area protected by your configured
subscription services.
n Subscription Dashboard — A high-level view of subscription services activity on your Firebox.
n Threat Map — A visual representation of source and destination locations for traffic through your Firebox.
n FireWatch — Real-time, aggregate information about the traffic through your Firebox. This is the same
tool that is available in Fireware Web UI and Dimension.
n Policy Map — An interactive report tool that aggregates the traffic through your Fireboxes and shows a
visualization of the traffic flows through interfaces and policies. This can help you identify which policies
are more heavily used.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 57

 Logging, Monitoring, and Reporting

Reports
Reports provide insight into the network activity on your devices. Reports display details of the traffic allowed
and denied by the device, the services that are enabled, and other device information. WatchGuard Cloud
automatically generates reports based on the log messages it receives from the Firebox.

To see reports in WatchGuard Cloud, you must enable logging for reports in your policies and
services.

You can also schedule reports to run for one or more Fireboxes. Each scheduled report can contain multiple
reports. WatchGuard Cloud sends scheduled reports as a zipped PDF email attachment to the recipients you
specify. Recently generated reports are also available for download in WatchGuard Cloud.

Live Status
With WatchGuard Cloud you can monitor the live status and usage of your locally-managed Fireboxes with
cloud reporting. When the Firebox is connected to cloud, you can use these pages to see live information on
the traffic that passes through your Firebox:
n Traffic Monitor — View real-time data on currently active connections and live logs.
n FireCluster — View a graph that shows cluster member availability for a period of time. View a list of
recent FireCluster events. Click an event to see detailed information and to download a .JSON file.
n Authentication — View information about the users that are authenticated to the Firebox and enable
diagnostics.
n Networks — View information on ARP, DHCP, and the routes that are configured on your Firebox.
n Geolocation — View connections allowed by Geolocation for each country.
n VPNs — View information about the Branch Office Virtual Private Networks (BOVPNs) and mobile VPNs
configured for your Firebox.
n Diagnostic Tools — Run network diagnostic tasks (Ping, TCP Dump, and DNS Lookup) and download a
diagnostic snapshot file.

Add a Firebox to WatchGuard Cloud

Before you can enable your Firebox to send log messages to WatchGuard Cloud, you must add
the device to your WatchGuard Cloud account.

To log in to WatchGuard Cloud, go to cloud.watchguard.com and use your WatchGuard portal user credentials to log
in. In your WatchGuard Cloud account, you can add any activated Firebox that has Standard Support, or a Total
Security or Basic Security Suite subscription. When you add a Firebox to WatchGuard Cloud, you might be required
to copy a Verification Code into the Firebox configuration to enable the Firebox to register with WatchGuard Cloud.
Fireboxes that have a TPM chip and run Fireware v12.5.3 or higher do not require the Verification Code.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 58

 Logging, Monitoring, and Reporting

Set Up Dimension for Firebox Logging

WatchGuard Dimension integrates with your Fireboxes and WatchGuard servers to provide a flexible, cloud-ready
logging, reporting, and management solution. From Dimension, you can manage your Fireboxes, review log
messages, and schedule, view, and run reports.

Install Dimension
Dimension must be installed as a virtual machine (VM) with a 64-bit OS. You can install Dimension on VMware or on
Hyper-V. After you install and start the virtual machine, you run the web-based WatchGuard Dimension Setup Wizard
to configure the basic settings for your new instance of Dimension.

To connect to Dimension, use the IP address assigned to your Dimension VM. For example, if the IP address
assigned to your instance of Dimension is 203.0.113.201, you connect to Dimension at https://203.0.113.201.

For complete instructions to install Dimension, see WatchGuard Help Center.

After you configure your Dimension server, configure your Fireboxes to send log messages to
Dimension, and enable logging in your policies to generate log messages for reports. For more
information on how to send log messages to Dimension, see Configure Firebox Logging to
Dimension.

Configure Dimension to Email Notifications and Reports

In Dimension, you can create scheduled reports and automatically email the reports to specific email addresses.

In the Dimension system settings, enable outgoing email and configure the address for the email server that
Dimension can use to send notifications and reports.

You can also configure Dimension to send notification alerts by email to specific email addresses. Email notification
of Firebox alerts is not enabled by default, and is configured separately from the email server settings.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 59

 Logging, Monitoring, and Reporting

Configure Firebox Logging to Dimension

You can configure each Firebox on your network to send log messages to one or more Dimension servers.

n You can send log messages to multiple servers at the same time, such as both a local
Dimension server and a Dimension server at a remote site.
n Make sure the authentication key you configure in the Firebox logging configuration is
the same as on your Dimension server.

To configure the Firebox to send log messages to a Dimension server, you need this server information:
n Server IP address
n Server authentication key

Your Firebox can send log messages to two Dimension servers at the same time. In the log server configuration, you
specify each server on a different tab.

If you want the Firebox to simultaneously send log messages to two Dimension servers, add the first server to the
Log Servers 1 tab, and the second server to the Log Servers 2 tab. You can also optionally add backup servers on
each tab. The Firebox sends log messages to a backup server only if it cannot connect to the primary server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 60

 Logging, Monitoring, and Reporting

Monitoring with Firebox System Manager

With Firebox System Manager (FSM), you can quickly see the real-time status of a single Firebox. This helps you to
identify unusual activity and take immediate action.

Firebox System Manager Front Panel tab

Firebox System Manager shows Firebox status and activity such as interface statistics, network connections, log
messages, and security service statistics.

n Traffic Monitor displays a continuous list of log messages. The messages refresh every
five seconds by default, which makes Traffic Monitor a good place to start
troubleshooting problems with your Firebox.
n From Firebox System Manager, you can use traceroute, ping, DNS lookup, and TCP
dump diagnostic tasks to help diagnose problems with the traffic on your network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 61

 Logging, Monitoring, and Reporting

Firebox log messages in the FSM Traffic Monitor tab

Firebox System Manager Overview

Firebox System Manager includes several methods to monitor your Firebox, each in a separate tab.

Tab Description

Front Panel Shows the status of Firebox interfaces, information about certificates, active VPN tunnels,
and subscription services, traffic for active connections, CPU load, and system details.

Traffic Monitor Shows a color-coded list of log messages sent from the Firebox. From this page, you can
also ping the source of a denied packet.

Bandwidth Meter Provides a real-time graphical display of bandwidth utilization for each interface.

Service Watch Shows a graph of the policies configured on a Firebox. The Y-axis (vertical) shows the
number of connections or bandwidth used for each policy. The X-axis (horizontal) shows
the time.

Status Report Shows statistics about Firebox status, traffic, and performance. You can use the report to
troubleshoot problems with your configuration. You can also download a support file that
contains log data, connection information, and other system information.

Before you contact WatchGuard technical support to troubleshoot a Firebox issue, save
the support log file for your Firebox.

Authentication List Identifies the IP addresses and user names of all users that are authenticated to the
Firebox. Includes a Summary section with the number of users authenticated for each
authentication type, and the total number of authenticated users.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 62

 Logging, Monitoring, and Reporting

Tab Description

Blocked Sites Shows all sites currently blocked by the Firebox. From this page, you can also add or
remove sites from the temporary blocked sites list.

Subscription Shows the status of Gateway AntiVirus, IntelligentAV, Intrusion Prevention Service,
Services Application Control, spamBlocker, WebBlocker, Botnet Detection, Tor Exit Node Blocking,
APT Blocker, Geolocation, Data Loss Prevention, and File Exceptions. From here, you
can also review the status and perform a manual update of the signature databases.

Gateway Wireless Shows the connection status and activity of WatchGuard APs managed by the Gateway
Controller Wireless Controller. You can also monitor and manage the client connections to your
WatchGuard APs.

SD-WAN Shows loss, latency, or jitter for selected external interfaces. Shows a list of all SD-WAN
actions and the multi-WAN mode, associated interfaces, and failback option for each SD-
WAN action.

Traffic Management Shows bandwidth statistics for the traffic managed by traffic management actions
configured on your Firebox. The statistics include details about which policies and
applications use each traffic management action.

User Quotas Shows which users with applied bandwidth and time quotas are connected to your
Firebox, and shows the quota information for each user.

Other Monitoring Tools

From the Firebox System Manager toolbar, you can also open these tools to monitor your Firebox:

Performance Console
Select performance counters to generate graphs about Firebox performance.

WatchGuard Cloud and Dimension provide better tools to monitor Firebox performance.

HostWatch
Shows the network connections between the selected networks.

FireWatch, available in Fireware Web UI, Dimension, and WatchGuard Cloud, is a better tool to
monitor network connections through the Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 63

 Logging, Monitoring, and Reporting

Subscription Service expiration warnings

If any of your subscription services have expired, an expired service warning appears for each expired service
on the Front Panel tab. To renew your subscription to the expired services, click Renew Now. You can also
choose to hide the expired service warnings.

Diagnostic Tasks
In Firebox System Manager, click Tools > Diagnostic Tasks to get access to several network diagnostic tools to
troubleshoot issues on your network:
n Ping — Ping the source or destination IP address.
n Traceroute — Trace the route to the source or destination IP address.
n DNS Lookup — Look up DNS information for an IP address.
n TCP Dump — See information about the packets transmitted across your network. You can use this tool to
perform packet captures and stream the packet capture to a local .pcap file. You can then use a third-party
tool to review the .pcap file, or send the file to WatchGuard Support for review.

To specify command arguments and see other options, select the Advanced Options check box.

The VPN tab includes diagnostic tasks that are useful for VPN troubleshooting. For more information, go to
Troubleshoot BOVPN Tunnels

Network Security Essentials for Locally-Managed Fireboxes Study Guide 64

 Logging, Monitoring, and Reporting

Monitoring with Fireware Web UI

Fireware Web UI includes many of the same monitoring tools that are available in Firebox System Manager, and
provides some additional tools. Each tool is on a different page in the Dashboard and System Status sections of
Fireware Web UI.

n FireWatch shows a graphical representation of real-time, aggregate information about

the traffic through your Firebox. It is available in Fireware Web UI, Dimension, and
WatchGuard Cloud.
n Diagnostic tools such as ping, traceroute, DNS lookup, and TCP dump are available in
the System Status > Diagnostics page.

Dashboard
From the Dashboard, you can see real-time information about your Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 65

 Logging, Monitoring, and Reporting

This table describes the monitoring tools available from the Dashboard:

Monitoring
Tool Description

Front Panel Shows basic information about your device, connected servers, your network, and network
traffic.

Subscription Shows the status of Gateway AntiVirus, IntelligentAV, Intrusion Prevention Service,
Services Application Control, spamBlocker, WebBlocker, Botnet Detection, Tor Exit Node Blocking,
APT Blocker, Geolocation, Data Loss Prevention, and File Exceptions.

FireWatch Shows real-time, aggregate information about the traffic through your Firebox.

Interfaces Shows the current bandwidth and detail information for the active interfaces on your device.
This includes wireless interfaces configured for your AP devices. You can also release or
renew the DHCP lease on an IP address for any external interface with DHCP enabled.

Traffic Monitor Shows log messages from your Firebox as they occur. This can be a useful tool for
troubleshooting network security problems and traffic flow issues.

Gateway Shows the connection status and activity of your WatchGuard APs managed by the Gateway
Wireless Wireless Controller. You can also monitor and manage the client connections to your
Controller WatchGuard APs.

Geolocation Shows the activity of network traffic by geographic location, as identified by the Geolocation
service.

Mobile Security Shows mobile devices that are connected to your network. You can see a list of connected
mobile devices, see detailed information for each device, and see group information for each
device.

Network Shows a tree map of all the devices on your network that are connected to the interfaces on
Discovery your Firebox. You can see detailed information for each connected device.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 66

 Logging, Monitoring, and Reporting

System Status
The System Status section of Fireware Web UI provides information similar to what is available in Firebox System
Manager. Many items from the Status Report in Firebox System Manager are available here and are easier to
examine.

Before you contact WatchGuard technical support to troubleshoot a Firebox issue, go to the
Diagnostics system status page and save the support log file for your Firebox.

The system status pages in Fireware Web UI are:

n ARP Table — List of devices that have responded to an ARP (Address Resolution Protocol) request from the
Firebox
n Authentication List — List of currently authenticated users
n Blocked Sites — List of blocked sites
n Checksum — Checksum of the operating system (OS) files currently installed on the Firebox
n Components List — List of the software components installed on the Firebox
n DHCP Leases — List of the active DHCP leases for the Firebox
n Diagnostics
o Diagnostics File — Download a diagnostic log file, for troubleshooting with WatchGuard technical support

o Network — Diagnostic tasks for network troubleshooting

o VPN — Generate the BOVPN diagnostic report
n Dynamic DNS — Dynamic DNS status information
n Hotspot Clients — List of clients connected to the Firebox hotspot
n Processes — List of processes that run on the Firebox
n Routes — Information about IPv4 and IPv6 routes
n Multicast Routes — Information about the multicast routes on the Firebox
n Server Connection — Test the connection to your Active Directory or LDAP authentication server
n SSO Agents — Information about SSO Agents
n Traffic Management — Bandwidth statistics for the traffic managed by traffic management actions
n Users and Roles — Information about the Device Management users who are connected to your Firebox
n Quotas — Quota information for users with applied bandwidth and time quotas
n VM Information — Virtual machine information (Firebox Cloud models only)
n VPN Statistics — Information about the Branch Office VPNs and Mobile VPNs
n SD-WAN Status — Information about the status of configured SD-WAN actions
n 4G LTE Modem — Information about the status of a 4G LTE modem.
n Rogue AP Detection — Scan for rogue access points (wireless Firebox models only)
n Wireless Statistics — Statistics about the Firebox wireless networks (wireless Firebox models only)

Network Security Essentials for Locally-Managed Fireboxes Study Guide 67

 Logging, Monitoring, and Reporting

Read Traffic Log Messages in Traffic Monitor

In Firebox System Manager and Fireware Web UI, you can use Traffic Monitor to see which policy allowed or denied
a connection and the reason why.

For more information on policy logging options, see Policy Logging and Notification in the Firewall Policies section of
this guide.

Each log message generated by your Firebox includes a string of data about the traffic on your Firebox. When you
review the log messages in Traffic Monitor, the different details in the data have different colors applied to them to
help visually distinguish each detail.

To show only log messages for Firebox traffic, select the Traffic Logs filter.

To customize the colors, right click in the Traffic Monitor tab and select Settings.

You can use the search box to find messages that contain specific text, such as a policy name or IP address. You can
also filter the search results and highlight items in the search results.

Here is an example of one traffic log message from Traffic Monitor:

2022-07-02 17:38:43 Member2 Allow 192.168.228.202 10.0.1.1 webcache/tcp 42973
8080 3-Trusted 1-WCI Allowed 60 63 (Outgoing-proxy-00) proc_id="firewall"
rc="100" src_ip_nat="203.0.113.99" tcp_info="offset 10 S 2982213793 win 2105"
msg_id="3000-0148"

When you read log messages, you can see details about when the connection for the traffic occurred, the source and
destination of the traffic, as well as the disposition of the connection, and other details.

Each log message includes these details:

Time Stamp
The log message line begins with a time stamp that includes the time and date that the log message was
created. The time stamp uses the time zone and current time from the Firebox.

This is the time stamp from the example log message above:
2022-07-02 17:38:43

FireCluster Member Information

If the log message is from a Firebox that is a member of a FireCluster, the log message includes the cluster
member number for the Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 68

 Logging, Monitoring, and Reporting

This is the FireCluster member information from the example log message above:
Member2

Disposition
Each log message indicates the disposition of the traffic: Allow or Deny. If the log message is for traffic that
was managed by a proxy policy instead of a packet filter policy, the traffic might be marked Allow even though
the proxy action stripped or altered the packet body.

This is the disposition from the example log message above:

Allow

Source and Destination Addresses

After the disposition, the log message shows the actual source and destination IP addresses of the traffic. If
NAT was applied to the traffic, the NAT addresses appear later in the log message.

These are the source and destination addresses from the example log message above:

192.168.228.202 and 10.0.1.1

Service and Protocol

The next entries in the log message are the service and protocol that managed the traffic. The service is
specified based on the protocol and port the traffic used, not the name of the policy that managed the traffic. If
the service cannot be determined, the port number appears instead.

These are the service and protocol from the example log message above:
webcache/tcp

Source and Destination Ports

The next details in the log message are the source and destination ports. The source port identifies the return
traffic. The destination port determines the Firebox policy used for the traffic.

These are the source and destination ports from the example log message above:

42973 and 8080

Source and Destination Interfaces

The source and destination interfaces appear after the destination port. These are the physical or virtual
interfaces that handle the connection for this traffic.

These are the source and destination interfaces from the example log message above:

3-Trusted and 1-WCI

Connection Action
This is the action applied to the traffic connection. For proxy actions, this indicates whether the contents of the
packet are allowed, dropped, or stripped.

This is the connection action from the example log message above:
Allowed

Network Security Essentials for Locally-Managed Fireboxes Study Guide 69

 Logging, Monitoring, and Reporting

Packet Length
The two packet length numbers indicate the packet length (in bytes) and the TTL (Time To Live) value. TTL is
a metric used to prevent network congestion by only allowing the packet to pass through a specific number of
routing devices before it is discarded.

These are the packet length numbers from the example log message above:

60 (packet length) and 63 (TTL)

Policy Name
This is the name of the policy on your Firebox that handles the traffic. The number (-00) is automatically
appended to policy names, and is part of the internal reference system on the Firebox.

This is the policy name from the example log message above:
(Outgoing-proxy-00)

Process
This section of the log message shows the process that handles the traffic.

This is the process from the example log message above:

proc_id="firewall"

Return Code
This is the return code for the packet, which is used in reports.

This is the return code from the example log message above:
rc="100"

NAT Address
This is the IP address that appears in place of the actual source IP address of the traffic after it leaves the
Firebox interface and the NAT rules have been applied. A destination NAT IP address can also be included.

This is the NAT address from the example log message above:
src_ip_nat="203.0.113.99"

Packet Size
The tcp_info detail includes values for the offset, sequence, and window size for the packet that initiates the
connection. The packet size details that are included depend on the protocol type.

This is the packet size from the example log message above:
tcp_info="offset 10 S 2982213793 win 2105"

Message Identification Number

Each type of log message includes a unique message identification number. When you review a log message
in Traffic Monitor, the message ID number can appear as the value for either the msg_id= detail or the id=
detail.

Log messages show which policies allow or deny traffic through the firewall. This traffic log message shows
information for an allowed packet:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 70

 Logging, Monitoring, and Reporting

The Firebox uses the source port to map response packets received from the destination IP address and port back to
the source IP address that originally initiated the connection.

For proxy policies, log messages show a lot of detail about why a policy allowed or denied a packet. This log message
shows that the HTTP-proxy policy denied an HTTP request because it matched a denied WebBlocker category.

The Firebox uses two hidden low precedence policies to deny packets that do not match any configured policy:
n Unhandled Internal Packet — Denies packets received on an internal interface
n Unhandled External Packet — Denies packets received on an external interface

For more information about hidden policies, see Hidden Policies.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 71

 Network Settings

Network Settings
In this section, you learn about the basic information you need to configure network settings on your Firebox. This
includes:
n Network routing modes
n DNS
n Interface types and aliases
n Network bridges
n Secondary networks
n VLANs
n Multi-WAN
n Static routing
n Dynamic NAT
n Static NAT
n 1-to-1 NAT

For a list of additional resources on these topics, go to Network Settings Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 72

 Network Settings

Network Routing Modes

You can configure a Firebox in Mixed Routing, Drop-In, or Bridge Mode.

The most common configuration method is Mixed Routing Mode. We use Mixed Routing to explain most of the
features and examples in this guide.

When you use the Web Setup Wizard to create your initial network configuration, the Firebox is automatically
configured in Mixed Routing Mode. When you use the Quick Setup Wizard in WatchGuard System Manager to create
your initial network configuration, you can choose to configure the Firebox in a Mixed Routing Mode or Drop-in Mode.

Mixed Routing Mode is the only mode that allows you to use all Firebox features. Other modes disable some features.
For example, you cannot configure a VPN in Bridge Mode. Before you select a mode other than Mixed Routing Mode,
make sure you understand the limitations of that mode.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 73

 Network Settings

Drop-In Mode and Bridge Mode are rarely used and have these characteristics:

Drop-In Mode Bridge Mode

All the Firebox interfaces are on the same All the Firebox interfaces are on the same network.
network and have the same IP address. You specify an IP address to use to manage the
Firebox.

The computers on the trusted or optional Traffic from all trusted or optional interfaces is
interfaces can have a public IP address. NAT is examined and sent to the external interface. You can
not necessary. specify a static IP address or use DHCP for the
Interface IP address. Traffic sent or received through
the Firebox appears to come from its original source.

In Bridge Mode, the Firebox does not handle Layer 2 or

Layer 3 information, which means you cannot
configure routing, NAT, or VLANs.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 74

 Network Settings

Interfaces
A firewall physically separates the networks on your local area network (LAN) from those on a wide area network
(WAN) like the Internet. One of the basic functions of a firewall is to move packets from one side of the firewall to the
other. This is known as routing. To route packets correctly, the firewall must know what networks are accessible
through each of its interfaces.

The Firebox provides additional functionality for some interfaces. You can configure external interfaces to work with
Dynamic DNS. You can configure trusted, optional, and custom interfaces to enable a DHCP (Dynamic Host
Configuration Protocol) server.

The Firebox has four types of network interfaces, which are also known as zones:

External Interfaces
An external interface connects your Firebox to a wide area network (WAN), such as the Internet, and can have
either a static or dynamic IP address. The Firebox gets a dynamic IP address for the external interface from
either a DHCP server or PPPoE (Point-to-Point Protocol over Ethernet) server.

With DHCP, the Firebox uses a DHCP server controlled by your Internet Service Provider (ISP) to get an IP
address for the external interface, a gateway IP address, and a subnet mask. With PPPoE, the Firebox
connects to your ISP’s PPPoE server to get the same information.

Modems are available as external interfaces on Fireboxes that support modems.

External interfaces are members of the Any-External alias. External interfaces always have a default route,
which is also known as a zero route (0.0.0.0/0).

Trusted Interfaces
A trusted interface connects your Firebox to the private local area network (LAN) or internal network that you
want to secure. User workstations and private servers which cannot be accessed from outside the network are
usually found in trusted networks. Trusted interfaces are members of the Any-Trusted alias.

Optional Interfaces
Optional interfaces connect your Firebox to your optional networks, which are mixed trust or DMZ
environments separated from your trusted networks. Public web, FTP, and mail servers are usually found in
optional networks. The settings for an optional interface are the same as for a trusted interface. The only
difference is that optional interfaces are members of the Any-Optional alias.

Custom Interfaces
A custom interface connects your Firebox to an internal network with a custom level of trust that is different
from trusted or optional. A custom interface is not a member of the built-in aliases (Any-Trusted, Any-Optional,
or Any-External), so traffic for a custom interface is not allowed through the Firebox unless you specifically
configure policies to allow it. A custom interface is included in the Any alias.

The only difference between trusted, optional, and custom interfaces is which aliases the interface is a member of. All
interfaces are part of the Any alias regardless of the interface type.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 75

 Network Settings

Most users configure at least one external and one trusted interface on their Firebox. You can
configure any interface as trusted, optional, external, or custom.

Trusted, optional, and custom interfaces are all internal interfaces, and all have the same configurable settings. The
IP address for an internal interface must be static. Usually, internal interfaces use private or reserved IP addresses
that conform to RFC 1918 and RFC 8190.

We recommend that you do not use public IP addresses that you do not own on your internal
network.

When you configure the IPv4 addresses for interfaces on a Firebox, you must use slash notation to denote the subnet
mask. For example, you specify the network range 192.168.0.0 with subnet mask 255.255.255.0 as 192.168.0.0/24.
A trusted interface with the IP address of 10.0.1.1/16 has a subnet mask of 255.255.0.0.

Interface Aliases
For each interface, the interface name is an alias used in policies to refer to traffic sent or received through that
interface. Each interface is also a member of one or more built-in aliases, which refer to network security zones.
When you select an interface type, the interface becomes a member of one or more of the built-in aliases that define
the different security zones.

The built-in aliases for interfaces are:

n Any-External — An alias for any network reachable through a Firebox interface configured as external
n Any-Trusted — An alias for any network reachable through a Firebox interface configured as trusted
n Any-Optional — An alias for any network reachable through a Firebox interface configured as optional
n Any — An alias for any address. This includes any IP address, interface, custom interface, tunnel, or user
group.

Requirements for Firebox Interfaces

Each Firebox interface can connect to a different network. The computers and servers protected by the Firebox can
use either private or public IP addresses. The Firebox uses network address translation (NAT) to route traffic from the
external network to computers on the trusted and optional networks.

In Mixed Routing Mode, all devices behind the trusted and optional interfaces must have an IP address from the
network assigned to that interface. To make this easy to remember, many administrators set the interface address to
the first or last IP address in the range used for that network. In the image below, for example, the IPv4 address of the
trusted interface could be 10.0.1.1/24 and the IPv4 address of optional interface could be 10.0.2.1/24.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 76

 Network Settings

About DHCP Server and DHCP Relay

You can configure the Firebox to assign IP addresses automatically through DHCP to devices on the trusted,
optional, or custom networks. When you enable the DHCP server, you specify a pool of IP addresses on the same
subnet as the interface IP address. The DHCP server assigns these addresses to devices that request DHCP leases.

Make sure to add enough IP addresses to the address pool to support the number of clients on your network. For
example, in the configuration shown here, the DHCP server can assign IP addresses to a maximum of 99
DHCP clients. When the 100th client requests an IP address, that request fails, and that client cannot connect.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 77

 Network Settings

You can also configure the Firebox for DHCP relay. When you use DHCP relay, computers behind the Firebox can
use a DHCP server on a different network to get IP addresses. The Firebox sends the DHCP request to a DHCP
server at a different location than the DHCP client. The Firebox sends the DHCP server reply to the computers on the
trusted, optional, or custom network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 78

 Network Settings

WINS/DNS in Mixed Routing Mode

To make sure that a DNS server is always available on your network, we recommend that you
configure at least two DNS servers on the Firebox: one for an internal DNS server, and another
for an external DNS server. We recommend that you list the internal DNS server first so it has
higher precedence. If you do not have an internal DNS server, we recommend that you specify
two external DNS servers from different providers for redundancy.

The Firebox uses DNS servers for:

n Network clients
n Mobile VPN clients
n Security services
n NTP
n Feature key updates
n CA certificate updates

You can configure different kinds of DNS servers and services on your Firebox. Each DNS server and service has a
different purpose and is configured in a different location in the Firebox settings. Some DNS servers take precedence
over others.

With the available DNS servers and services, you can:

n Configure DNS servers that apply to all interfaces and local Firebox processes, or only to specific interfaces.
n Configure conditional DNS Forwarding rules to send DNS queries for specific domains to different DNS
servers.
n Enable DNSWatch if you have a Total Security Suite subscription.
DNSWatch is a cloud-based service that monitors DNS requests through the Firebox to prevent connections
to known malicious domains. In some cases, DNSWatch DNS servers take precedence over some DNS
servers configured on your Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 79

 Network Settings

Network Bridges
A local area network bridge logically combines multiple physical interfaces to work as a single network, with a single
interface name and IP address. You configure the interface IP address and other interface settings in the bridge
configuration, and then configure interfaces as members of the bridge. A bridge must include at least one interface,
and can include any combination of physical, wireless, and link aggregation interfaces.

A bridge operates in the same way as any other network interface. It is technically an untagged VLAN network that
you assign to multiple interfaces.

You can configure a bridge in the trusted, optional, or custom security zone. The configuration settings for a bridge
are similar to the settings for any other trusted, optional, or custom network interface. For example, you can configure
DHCP to give IP addresses to clients on a bridge, or use the bridge name as an alias in firewall policies.

You can use a network bridge configuration if you want the Firebox to also function as a switch. You might do this on a
small network if you do not want to implement a network switch device.

For example, you can create a network bridge on the trusted network to combine two internal interfaces. In our
example, a network bridge named Trusted-Bridge has the IP address 10.0.100.1/24.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 80

 Network Settings

The interfaces Trusted-1 and Trusted-2 are part of the bridge configuration.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 81

 Network Settings

Do not change the interface that you currently use to connect to Fireware Web UI to a bridge
interface. This causes you to immediately lose the management connection to the Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 82

 Network Settings

Secondary Networks

A secondary network is a network that shares one of the same physical networks as one of the
Firebox interfaces.

When you add a secondary network, you add a second IP alias to the interface. This IP alias is the default gateway for
all the computers on the secondary network. Secondary networks can be used only in Mixed Routing or Drop-In
Mode.

Here are some examples of situations when secondary networks can be useful:

Network Consolidation
If you want to remove a router from your network, you can add the router IP address as a secondary IP
address on the firewall when the router is shut down. Any hosts or routers that are still sending traffic to the old
router IP address would then send traffic to the firewall.

Network Migration
Secondary addresses can help you avoid a network outage if you want to migrate your trusted network from
one subnet to another. For example, if you currently use 192.168.1.1/24 as the primary interface IP address,
and you change the interface IP address to 10.0.10.1/24, this could cause a network outage while the devices
that use DHCP get an IP address on the new subnet. Also, any devices that use a static IP address cannot
connect until you reconfigure them with an IP address on the new subnet. To avoid the outage, add the old IP
address as a secondary network, so that devices can still use IP addresses on the old subnet during the
migration.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 83

 Network Settings

When you configure a secondary network, the devices that use DHCP get an IP address on the new subnet
when they renew their DHCP lease, without an outage. Devices that use a static IP address can continue to
use the old subnet until you have time to update their IP addresses. After all devices have been migrated to the
new subnet, you can remove the secondary IP address from the interface.

You might want to migrate to a different local network range in these cases:
n You inherit a network that uses the 192.168.0.0/24 or 192.168.1.0/24 networks. Because these network
ranges conflict with many home network ranges, your mobile VPN users cannot access local resources
on your network.
n You have two sites with the same local network range, and you want to connect the sites with a BOVPN.

Static NAT to Multiple Servers

If your Firebox uses a static external IP address, you can add a secondary network IP address. You can then
configure static NAT rules to send traffic to the appropriate devices on that network.

For example, configure an external secondary network with a second public IP address if you have two public
web servers and you want to configure a static NAT rule for each server.

You can also add secondary networks to the external interface of a Firebox if the external interface is configured to
get its IP address through PPPoE or DHCP. You can add up to 2048 secondary networks for each interface.

Intra-Interface Traffic Inspection

By default, the Firebox inspects traffic that goes in and out of the same external interface and applies firewall policies
to that traffic. The Firebox does not inspect traffic that goes in and out of internal interfaces by default.

You can enable or disable intra-interface inspection on physical and link aggregation interfaces. If you enable this
setting, the Firebox applies firewall policies to intra-interface traffic for the specified interface. In Fireware v12.9 or
higher, you can enable or disable the setting from Fireware Web UI or Policy Manager.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 84

 Network Settings

Network Security Essentials for Locally-Managed Fireboxes Study Guide 85

 Network Settings

VLANS
A virtual local area network (VLAN) is a collection of computers on a LAN or LANs that are grouped together in a
single broadcast domain independent of their physical location.

With a VLAN, you can group devices according to function or traffic patterns instead of location
or IP address. Members of a VLAN can share resources as if they were connected to the same
LAN.

VLAN Benefits
VLANs provide three main benefits:
n Increased performance by restricting broadcasts — Each computer you add to a LAN increases the amount
of background (broadcast) traffic, which can reduce performance. With VLANs, you can restrict this traffic and
reduce the amount of bandwidth used by your network.
n Improved manageability and simplified network tuning — When you consolidate common resources into a
VLAN, you reduce the number of routing hops required for those devices to communicate. You can also
manage traffic from each functional group more easily when each group uses a different VLAN.
n Increased security options — By default, members of one VLAN cannot see the traffic from another VLAN.
You can apply separate security policies to VLANs. By contrast, a secondary network on a Firebox interface
gives no additional security because there is no separation of traffic. The Firebox does not filter traffic between
the primary network of an interface and a secondary network on that interface. It automatically routes traffic
between primary and secondary networks on the same physical interface with no access restrictions.

VLAN Terms and Concepts

VLAN Trunk Interface
The physical interface (switch interface or device interface) that connects a VLAN device to another VLAN
device. Some vendors use this term only for a switch interface that carries traffic for more than one VLAN. We
use this as a general term to indicate an Ethernet interface on a VLAN-capable device that connects the
device to another VLAN-capable device.

VLAN ID (VID)
A number from 1 to 4094 associated with the VLAN. Every VLAN you use has a unique number.

Tag
This term has one meaning when used as a verb, and another meaning when used as a noun:

Tag [noun] — Information that is added to the header of an Ethernet frame. The format of the tag is defined by
the IEEE 802.1Q standard.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 86

 Network Settings

Tag [verb] — To add a VLAN tag to a data frame’s Ethernet header. The tag is added by an 802.1Q-compliant
device such as an 802.1Q switch or router, or the Firebox.

Because the physical segment between two 802.1Q devices normally carries only tagged data packets, we
call it the tagged data segment.

Untag
To remove a VLAN tag from a frame’s Ethernet header. When an 802.1Q device must send data to a network
device that cannot understand 802.1Q VLAN tags, the data frames must be configured as untagged.

Because the physical segment between a VLAN device and a device that cannot understand VLAN tags
normally carries only untagged data packets, we call it the untagged data segment.

Clients are untagged by default. As a best practice, we recommend that you have one untagged VLAN for
direct management access. For example, you might want to physically connect to the Firebox to troubleshoot
an issue. Some third-party devices leave VLAN ID 1 untagged for management and troubleshooting.

Tagging and Untagging per Interface

When you assign VLAN membership for an Ethernet interface on an 802.1Q device, you also tell the interface
whether to send and accept tagged or untagged data frames. Some VLAN devices allow one Ethernet
interface to accept both tagged and untagged frames. This depends on which VLANs the interface is a
member of.

When you configure a Firebox Ethernet interface for VLAN, the interface accepts both tagged and untagged
data frames. A VLAN can have more than one physical interface member. An interface can simultaneously
belong to both an External and Internal (Trusted, Optional, or Custom) VLAN. A VLAN interface can send and
receive untagged traffic for an external VLAN.

Use these two rules to decide whether to configure a switch interface for Tag or Untag:
n If the interface connects to a device that can receive and understand 802.1Q VLAN tags, configure
the switch interface for Tag. Devices you connect to this interface are usually VLAN switches
(managed switches) or routers.
n If the interface connects to a device that cannot receive and understand 802.1Q VLAN tags,
configure the switch interface for Untag. Such devices will likely strip the VLAN tag from the
Ethernet header, or drop the frame altogether. Devices you connect to this interface are usually
computers or printers.

Switches and Routers

When you configure a Firebox Ethernet interface for VLAN, the switches and routers that you connect to the
device interface must be able to use VLAN tags as defined in IEEE 802.1Q.

A switch of this type is commonly called a managed switch or an 802.1Q switch.

VLAN Type
VLANs can use different parameters to assign membership. The Firebox uses 802.1Q VLANs. The Institute of
Electrical and Electronic Engineers (IEEE) publishes the 802.1Q standard to define the format of VLAN tags.
This standard lets you use VLANs with any vendor equipment that conforms to 802.1Q standards.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 87

 Network Settings

VLAN Requirements and Recommendations

Before you configure VLANs on your Firebox, consider these requirements and recommendations.

To use a VLAN with a Firebox:

n If your Firebox is configured in Drop-In Mode, you cannot use VLANs.
n If your Firebox is configured in Bridge Mode, you cannot configure VLANs.
o In bridge mode, the Firebox can pass VLAN tagged traffic between 802.1Q bridges or switches.

o You can configure a Firebox in Bridge Mode to be managed from a VLAN that has a specified VLAN tag.
o You can enable Spanning Tree Protocol in Bridge Mode.
n Multi-WAN configuration settings are applied to VLAN traffic. However, it can be easier to manage bandwidth
when you use only physical interfaces in a multi-WAN configuration.
n Your device model and license determine the number of VLANs you can create. To see the number of VLANs
you can add to your Firebox, open Policy Manager and select Setup > Feature Keys. Find the Total Number
of VLAN Interfaces row.
n We recommend that you do not create more than 10 VLANs that operate on external interfaces. Too many
VLANs on external interfaces affect performance.
n All network segments you want to add to a VLAN must have IP addresses on the VLAN network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 88

 Network Settings

VLAN Configuration Scenarios

These examples illustrate some of the different ways you can use VLANs to create logical networks for network
clients when the traffic goes through one or more Firebox interfaces.

Multiple VLANs From a Single Interface

USE CASE:

Use VLANs to create separate logical networks for two groups of devices that connect to a single
Firebox interface through a switch. Create a separate VLAN for the management computer.

For example, if you use VLANs to logically separate traffic for devices located in two departments, the network
diagram could look like this:

Firebox configuration:
n The VLAN interface that connects to the switch has one untagged VLAN and two tagged VLANs.

Switch port configuration:

n The port that the Firebox connects to has one untagged VLAN and two tagged VLANs, to match the
configuration of the VLAN port on the Firebox.
n Each port that a client connects to is configured with a single VLAN, which is untagged.

With this configuration, the switch adds and removes VLAN tags for network traffic between clients and the Firebox.
n All traffic for VLAN 10 and VLAN 20 is tagged between the Firebox and the switch.
n All traffic for VLAN 10 and VLAN 20 is not tagged between the switch and the network clients.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 89

 Network Settings

n The switch removes the tags for traffic sent from the Firebox to clients on those VLANs.
n The switch adds tags for traffic from clients on those VLANs to the Firebox.

Single VLAN Bridged Across Multiple Interfaces

USE CASE:

Use a VLAN to create a single logical network for devices that connect to two Firebox interfaces through
two different switches.

For example, if you use a VLAN to create a single logical network for devices located on two floors of a building, the
network diagram could look like this:

Firebox configuration:
n The VLAN interfaces that connect to both switches are configured as members of the same tagged VLAN.

Switch port configuration on both switches:

n The port that the Firebox connects to has one tagged VLAN.
n Each port that a client connects to is configured with the same VLAN, which is untagged.

With this configuration, the switch adds and removes VLAN tags for network traffic between clients and the Firebox.
n All traffic for VLAN 10 is tagged between the Firebox and the switches.
n All traffic for VLAN 10 is not tagged between the switches and the network clients.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 90

 Network Settings

n The switch removes the tags for traffic sent from the Firebox to clients on the VLAN.
n The switch adds tags for traffic from clients on that VLAN to the Firebox.

Segmented VLAN Switch Connected to Two Interfaces

USE CASE:

Use two Firebox interfaces to handle traffic for two separate VLANs configured on the same connected
switch. This use case does not require any VLAN configuration on the Firebox. To configure different
policies for each VLAN, specify the interface that connects to each VLAN on the switch.

For example, if your switch is configured with two VLANs for computers in two departments, and you use a different
Firebox interface for traffic from each VLAN, the network diagram could look like this:

In this configuration, the Firebox is not aware of the VLANs, and sees these as two separate networks.

Firebox configuration:
n Each interface connected to the switch is a trusted, optional, or custom interface.

Switch port configuration:

n Each port that connects to the Firebox is configured with a different untagged VLAN.
n Each port that a client connects to is configured with a single untagged VLAN.

With this configuration, the switch routes traffic for clients on each VLAN to a different Firebox interface.
n All traffic between VLAN 10 clients and the Firebox goes through one Firebox interface.
n All traffic between VLAN 20 clients and the Firebox goes through another Firebox interface.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 91

 Network Settings

Frequently Asked Questions

If I want to allow traffic to a VLAN from a device outside the VLAN, do I need a policy for it?
Yes. By default, the Firebox does not allow traffic to a device in any VLAN. To allow this traffic, add a policy for
it and include the VLAN’s alias name or subnet in the To section.

If I want to allow traffic that starts in a VLAN and leaves the VLAN, do I need a policy for it?
Yes. Traffic is not allowed to leave a network protected by the Firebox unless there is a policy to allow it.
However, the default configuration the Quick Setup Wizard creates for the Firebox includes the Outgoing
policy, which allows traffic from Any-Trusted or Any-Optional to Any-External.

You can configure the VLAN as a Trusted or Optional zone.

If your VLAN uses the Trusted or Optional security zone, any device in the VLAN can use the Outgoing policy
to send traffic to Any-External. This is because a VLAN that uses the Trusted security zone is included in the
Any-Trusted alias, and a VLAN that uses the Optional security zone is included in the Any-Optional alias.

If I want to allow traffic that starts in one VLAN and goes to another VLAN, do I need a policy for it?
Yes. By default, devices in one VLAN cannot see the traffic from another VLAN. You can apply separate
security policies to VLANs.

If I want to allow traffic that starts in a VLAN and goes to a device in the same VLAN, do I need a policy
for it?
No. If a computer connected to Switch A sends traffic to a computer connected to Switch B, and both
computers are in the same VLAN, the Firebox does not filter this traffic. In this setup, the Firebox serves as a
VLAN bridge between the two computers and the two switches. The two computers communicate as if they
were in the same physical LAN, not separated by the Firebox.

But, if you want to apply firewall policies to traffic between clients on two networks that are part of the same
VLAN, you can select the Apply firewall policies to intra-VLAN traffic check box in the VLAN configuration.
If you want to apply policies to intra-VLAN traffic, make sure that no alternate path exists between the source
and destination. The VLAN traffic must go through the Firebox for firewall policies to apply.

How many VLANs can I configure?

The number of VLANs you can add to your configuration depends on the Firebox model. To verify the number
of VLANs you can add to your device, look at the Total Number of VLAN Interfaces row in the feature key.

How many external VLANs can I configure?

The recommended maximum number of external VLANs is 10.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 92

 Network Settings

Static Routing
A route is the sequence of devices that network traffic must go through to get from its source to its destination. The
trip from one device to the next device is known as a hop.

A router, or a network device such as a Firebox, stores information about routes in a routing table. The device looks in
the routing table to find a route to send each received packet toward its destination.

Routes can be static or dynamic:

n Static route — A manually configured route to a specific network or host.
n Dynamic route — A route automatically learned and updated by a router, based on communication with
adjacent network routers.

Each hop in the route is isolated, which means routing issues are caused by point-to-point
connection problems between devices in the route.

About Static Routes

To have full control over how your Firebox routes traffic, you can add static routes.

Static routes can be appropriate in certain cases. For example, static routes can make sense on small networks,
when there are very few hops, or when you know the route will likely not change. Static routing can be used as
backup for dynamic routing. However, if the network structure changes or a connection fails, network traffic cannot
get to its destination.

To add a static route, from Policy Manager, select Network > Routes.

Each static route includes these attributes:

n Route Type — This is automatically set to Static Route. If you have configured a BOVPN virtual interface, you
can also select BOVPN Virtual Interface Route.
n Destination Type — Specifies whether the destination is an IPv4 or IPv6 network or host.
n Route To — The destination IP address.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 93

 Network Settings

n Gateway — The IP address to route the traffic through. This is the next hop in the route. The gateway IP
address must be part of a network included in the Firebox routing table. This is usually a subnet configured on
one of the Firebox interfaces.
n Metric or Distance — The distance sets the priority for the route. If the routing table includes more than one
route to the same destination, the Firebox uses the route that has the lower distance.
n Interface — For a route to an IPv6 destination, you can optionally select the IPv6-enabled interface to use for
the route. For a BOVPN Virtual Interface Route, you must select the BOVPN virtual interface to use for the
route.

See Network Routes

You can see the routes for your Firebox from Firebox System Manager on the Status Report tab.

The routing table includes:

n Routes to networks for all enabled Firebox interfaces and BOVPN virtual interfaces
n Static network routes or host routes you add to your configuration
n Routes the Firebox learns from dynamic routing processes that are enabled on the device
n The default route, which is used when a more specific route to a destination is not defined. This is the gateway
IP address you specify for your external interface.

Each route in the routing table has an associated metric. If the routing table includes more than one route to the same
destination, the Firebox uses the route that has the lower metric. For a static route, you manually set the distance
(metric) to control the priority of each route. If you use dynamic routing, the dynamic routing protocol automatically
sets the distance for each route.

A configured static route does not appear in the route table if there is no route to the gateway
specified in the static route.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 94

 Network Settings

Multi-WAN
Multi-WAN controls how outbound traffic through multiple external interfaces is sent to more than one Internet
Service Provider (ISP) simultaneously. This approach offers significant benefits in terms of redundancy, bandwidth
optimization, and failover capabilities.

Multiple external connections provide several benefits:

Redundancy
If the main Internet connection goes down, you can use a backup connection for outgoing connections.

More bandwidth available for outgoing connections

An additional connection to the Internet can reduce wait times for new connections and large downloads
initiated from behind the Firebox.

Dedicated access through a preferred connection

You can make mission-critical or bandwidth-heavy applications use a specified external interface.

With multi-WAN, you can configure multiple external interfaces, each on a different subnet. This
enables you to connect your Firebox to more than one Internet Service Provider (ISP). When
you configure two or more external interfaces, the multi-WAN feature is automatically enabled.

If your Firebox has multiple external interfaces, multi-WAN is the global routing option.

By default, multi-WAN is not enabled for modems. Multi-WAN does not impact BOVPNs or inbound traffic.

Multi-WAN Methods
Fireware supports these multi-WAN methods:

Failover (default)
The Failover method sends all outgoing connections to the primary interface. This algorithm sends outgoing
connections through a backup interface only if the primary interface is not available. When you enable multi-
WAN on the Firebox, Failover is the default multi-WAN method. For more information about Failover, go to
Failover in About Multi-WAN Methods in Fireware Help.

Routing Table
The Routing Table uses Equal-Cost Multi-Path Routing (ECMP) to distribute outgoing connections based on
the src/dst (source and destination) IP addresses. The Routing Table method attempts to equalize the number
of connections that go out of each interface. For detailed instructions on how to configure the Routing Table,
go to Configure the Routing Table Multi-WAN Method in Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 95

 Network Settings

Round-robin
Round-robin distributes outgoing connections based on the number of connections. If you set the weight for
each external interface to 1 in Round-robin mode, the algorithm attempts to equalize the number of
connections sent through each interface.

For light traffic loads, weighted Round-robin behaves like a connection-based Round-robin because the
weights you use tend to determine the number of connections through each external interface. When the traffic
load increases, weighted Round-robin behaves more like a load-based Round-robin because the weights you
assign tend to determine the load through each external interface. For more information about Round Robin,
go to Round-Robin in About Multi-WAN Methods in Fireware Help.

Interface Overflow
The Interface Overflow method enables you to set a bandwidth limit to restrict the amount of traffic sent over
each WAN interface. The algorithm sends outgoing connections to external interfaces in the order you specify.
After all interfaces reach their bandwidth limit, the Firebox uses the routing table to find the best path. For
information about Interface Overflow, go to Interface Overflow in About Multi-WAN Methods in Fireware Help.

When you enable multi-WAN, by default, Link Monitor is not enabled.

Failover/Failback
Failover occurs when an interface that was previously active becomes unable to send traffic to external networks.

Failback occurs when an interface that was previously not able to reach external locations becomes active again.

Failover on an External Interface

An external interface might go down because of a logical or physical failure. For example, if you disconnect the
Ethernet cable from a Firebox interface, a physical failure occurs. If a Link Monitor ping probe fails, a logical failure
occurs.

If an external interface goes down, the Firebox removes that external interface from all routing decisions. The action
the Firebox takes depends on the multi-WAN method currently in use. For information on how to configure failover, go
to Configure the Failover Multi-WAN Method in Fireware Help.

Failback
When you reconnect the interface or when Link Monitor probes determine that an interface is active again, the
Firebox makes the interface available again for outgoing traffic. You can set the action you want the Firebox to take
when a failover event occurs and after the primary external interface becomes active again. For information on how to
configure failback and select the action to take, go to Advanced Multi-WAN Settings in Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 96

 Network Settings

Link Monitor
Link Monitor is responsible for monitoring the status and availability of network links and connections. Its primary
purpose is to continuously check the health and availability of network links and provide information on the monitored
status. A Link Monitor operates by sending periodic network packets or messages, such as pings, to the target
devices or IP addresses associated with the links. It then waits for responses and analyzes them to determine the
link's status.

Link Monitor is vital for multi-WAN and all VPN types. You must configure Link Monitor correctly
for these features to work as expected.

The Firebox uses two methods to determine whether an interface is available to send and receive traffic:

Monitor the physical link state

The Firebox monitors the physical link by default. If the kernel-level drivers sense that the physical Ethernet
link is down, the Firebox immediately declares the interface down. New connections begin to flow through the
other external interfaces, depending on various multi-WAN and per-policy configuration options you set. If the
Firebox detects that the Ethernet connection is established again, the Firebox immediately considers the
interface active and available to send outbound traffic.

Monitor the logical link state

You can configure Link Monitor targets. Link Monitor sends ping, TCP, or DNS probes to targets to determine
whether the interface can connect to external locations. From Policy Manager, select Network >
Configuration > Link Monitor.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 97

 Network Settings

To monitor an interface with Link Monitor, you must click Add and manually add the interface to Link Monitor. You can
add these types of interfaces to Link Monitor:
n External
n Internal (Trusted, Optional, and Custom)
n Modem
n BOVPN virtual interface
To add a BOVPN virtual interface to Link Monitor, you must first configure a virtual peer IP address in the
BOVPN virtual interface settings. You must specify a peer IP address, not a netmask.

When you add an external or modem interface to Link Monitor, the target is the default gateway, which is the next hop
after the Firebox. For meaningful operational and performance data, we recommend that you replace the default
gateway target with a Link Monitor target that is farther upstream. For information about how to select an effective
target, see the next section.

To add a custom target, in the Monitored Interfaces list, click the interface you added, and then click Add. From the
Type drop-down list, select one of these options:
n Ping — Add an IP address or domain name for the Firebox to ping to check for interface status.
n TCP — Add the IP address or domain name where the Firebox sends a TCP SYN packet. Use the Port box to
set the port the Firebox uses when it sends the SYN packet. If the target sends an ACK in reply, the Firebox
knows it can reach the external target. The Firebox closes the connection with an RST packet when it gets an
ACK.
n DNS — Query a DNS server for a specified domain name. You must specify the IP address of the DNS server
you want to use and the domain name to query.

If you add an internal interface, you must add a next hop, a custom target, or both. The next hop IP address tells the
Firebox how to route Link Monitor traffic for the interface. If you do not specify a next hop IP address, the Firebox
routing table is used to route traffic.

If you add a BOVPN virtual interface, the Firebox automatically adds a ping target to the IP address of the peer. You
cannot edit or remove this target.

Multi-WAN does not require that you configure link monitor targets. However, we recommend that you configure link
monitor targets so the Firebox can:
n Determine whether an interface can send traffic
n Fail over properly to a different external interface

Recommendations for Targets

To make sure traffic fails over to a different interface when network issues occur, we recommend that you:
n Configure at least two Link Monitor targets for each external interface.
n Select an effective Link Monitor target. In most cases, we recommend that you select a Link Monitor target
other than the default gateway.
n Select targets that have a record of high uptime, such as servers hosted by your ISP.
n Specify different Link Monitor hosts for each external interface.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 98

 Network Settings

If you enable Link Monitor for an interface but do not configure a custom link monitor target, the Firebox pings the
interface default gateway to find the interface status. The default gateway is usually the Internet Service Provider
(ISP) modem or router. The default gateway is not a reliable target for these reasons:
n If ISP equipment just beyond the modem cannot connect to the Internet, but the default gateway still responds
to a ping, the Firebox does not detect the interface as inactive. This occurs because the gateway is the only
test of connectivity. In some multi-WAN modes, this can cause traffic loss because the Firebox continues to
send packets through an inactive interface that appears active because the connected modem or router
responds to a ping.
n Some ISP equipment might be configured to not respond to a ping.

Recommendations for Ping Targets

n To find a good Link Monitor target, you can run the traceroute command (tracert in Windows) to an
external IP address. We recommend a ping target on the ISP network that is two or three hops beyond the
modem or router. The DNS servers provided by your ISP might work well.
n If a remote site is critical to your business operations, such as a credit card processing site or business
partner, ask the site administrator if you can monitor a device at the site to verify connectivity.
n Ping an IP address, not a domain name. A ping to a domain name requires DNS. A DNS server issue can
cause a false indication of interface failure.
n Specify a different Link Monitor host for each external interface. If you specify the same IP address or
domain name for all external interfaces, a failure of that remote host causes all your external interfaces to
fail.

Recommendations for TCP Targets

n Do not specify a TCP Link Monitor target unless the company that hosts the target agrees. If you specify
TCP to monitor a link to a remote host, the company that manages the remote host might block traffic
from the Firebox. This can occur if the company considers the repeated TCP connections with no data as
a possible scan or attack.

Recommendations for DNS Targets

n Some DNS servers and ISP equipment block pings that continue for extended durations. To avoid this
issue, you can configure a DNS target instead of a ping target.

Probe Interval Settings

When you add Link Monitor targets, you must specify how often the Firebox attempts to probe the targets. The
Firebox uses the result of these probe attempts to determine whether the interface is active or inactive. If you select to
measure loss, latency, and jitter, the Firebox uses the probe results to calculate those metrics.

In Link Monitor, you configure these settings for each interface:

n Probe Interval — Number of seconds between each ping, TCP, or DNS probe attempt. The default value is 5.
n Deactivate After — Number of consecutive unsuccessful probes required to consider an interface inactive.
The default value is 3.
n Reactivate After — Number of consecutive successful probes required to consider an interface active. The
default value is 3.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 99

 Network Settings

These settings apply to all Link Monitor targets you configure for an interface. For example, if you configure a ping
target and a TCP target and specify a probe interval of five seconds, both targets use a probe interval of five seconds.

In certain cases, the Firebox disregards the Probe Interval, Deactivate After, and Reactivate After settings:
n Physical link disconnection or reconnection — If the interface cable is unplugged, for example, the Firebox
immediately considers the interface inactive. If the cable is plugged in again, the Firebox considers the
interface active after one successful probe.
n Link Monitor configuration change — If you change the IP address of a Link Monitor target, for example, the
Firebox immediately probes the target and updates the interface status as active or inactive.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 100

 Network Settings

Dynamic NAT
Dynamic NAT, also known as IP masquerading, changes the source IP address of each outgoing connection to
match the IP address of the Firebox interface that the connection goes out through. For traffic that goes to an external
network, packets go out through the Firebox external interface, so dynamic NAT changes the source IP address to
the Firebox external interface IP address. The Firebox tracks the private source IP address and destination address,
as well as other IP header information such as source and destination ports, and protocol.

Dynamic NAT enables clients on a private network to connect to servers on the Internet.

Dynamic NAT is normally applied to connections that start from behind the device. When dynamic NAT is applied to a
packet, the Firebox tries to always keep the same source port that the requesting client used. The source port is
changed only if necessary.

USE CASE:

In an example use case, two internal clients use the same source port to access the same web server.
However, the source IP address is always changed when dynamic NAT is applied. When the response
returns to the same Firebox interface from which the original connection exited, the Firebox examines its
connection state table and finds the original source IP address. It reverses the NAT process to send the
packet to the correct host.

Dynamic NAT is enabled by default on the Firebox. By default, dynamic NAT is applied to any connection that starts
from one of the private address ranges specified in RFC1918 and goes to an external network.

To see the default dynamic NAT rules in Policy Manager, select Network > NAT.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 101

 Network Settings

Dynamic NAT is also enabled by default in each policy you create. You can override the global dynamic NAT settings
in individual policies.

About Dynamic NAT Source IP Addresses

In the default dynamic NAT configuration, the Firebox changes the source IP address for traffic that goes out an
external interface to the primary IP address of the external interface the traffic leaves. You can optionally configure
dynamic NAT to use a different source IP address. You can set the dynamic NAT source IP address in a network NAT
rule or in the NAT settings for a policy. When you select a source IP address, dynamic NAT uses the specified source
IP address for any traffic that matches the dynamic NAT rule or policy.

Set the Dynamic NAT Source IP Address in a Network Dynamic NAT rule
If you want to set the source IP address for traffic that matches a dynamic NAT rule, regardless of any policies
that apply to the traffic, select Network > NAT, and add a network dynamic NAT rule that specifies the source
IP address. The source IP address you specify must be on the same subnet as the primary or secondary IP
address of the interface the traffic leaves. You can also specify IP addresses that are on the same subnet as
the primary or secondary IP address of the loopback interface.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 102

 Network Settings

Set the Dynamic NAT Source IP Address in a Policy

If you want to set the source IP address for traffic handled by a specific policy, configure the source IP address
in the network settings of the policy. The source IP address you specify must be on the same subnet as the
primary or secondary IP address of the interface you specified for outgoing traffic in the policy. You can also
specify IP addresses that are on the same subnet as the primary or secondary IP address of the loopback
interface.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 103

 Network Settings

Static NAT (SNAT)

Static NAT, also known as port forwarding, allows inbound connections on specific ports to one
or more public servers from a single external IP address. The Firebox changes the destination
IP address of the packets and forwards them based on the original destination port number. You
can also translate the original destination port to an alternative port on which the server is
listening.

Static NAT is typically used for public services such as websites and email. For example, you can use static NAT to
designate a specific internal server to receive all email. Then, when someone sends email to the device’s external IP
address, the device can forward the connection to the private IP address of the designated email (SMTP) server.

We recommend that you configure SNAT rather than 1-to-1 NAT, especially if you have a
small number of public IP addresses.

IP addresses used with SNAT can also be used for other Firebox features such as VPNs. SNAT is the only option if
you have only one public IP address.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 104

 Network Settings

About Static NAT Source IP Addresses

By default, a static NAT rule does not change the source IP address for inbound traffic. If you want to make the
incoming traffic appear to come from a different source IP address, you can set the source IP address in the static
NAT action.

About SNAT Actions

When you configure static NAT, the static NAT configuration is saved in a SNAT action. You can create or edit a
SNAT action when you create or edit a policy. Or you can select Setup > Actions > SNAT to add, edit, or delete
SNAT actions. After you have created a SNAT action, you can use the same action in one or more policies.

Server Load Balancing requires Fireware with a Pro upgrade and is not supported on Firebox
T10, Firebox T15, XTM 2 Series, and 3 Series devices.

There are two types of SNAT actions:

Static NAT
A static NAT action forwards inbound traffic addressed to one IP address to a different IP address and port
behind the firewall. You can specify an FQDN in a SNAT action in addition to an IP address.

Server Load Balancing

A server load balancing SNAT action forwards inbound traffic addressed to one IP address to one of several
servers behind the firewall. In the SNAT action, you select the load balancing algorithm to use. Optionally, you
can assign different weights to each server.

To use static NAT, you add a static NAT action to the To section of the policy that handles each type of inbound
traffic. To implement static NAT for the diagram above, you would add a different static NAT action to the FTP, SMTP,
and HTTP policies that handle the inbound traffic to each of the three servers.

You can combine SNAT with the Set Source IP option for dynamic NAT (DNAT) to perform the
same function as 1-to-1 NAT. With this configuration, you can still use the public IP address for
other purposes.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 105

 Network Settings

1-to-1 NAT
When you enable 1-to-1 NAT, your Firebox maps one or more private IP addresses to one or more public IP
addresses. This allows you to make internal network resources accessible on the Internet.

When to Use 1-to-1 NAT

1-to-1 NAT typically makes sense only for networks with many public IP addresses. If you have such a network, and
you want to dedicate a public IP address for a single purpose, 1-to-1 NAT is an option.

On most networks, we recommend that you configure SNAT rather than 1-to-1 NAT.

Do not enable 1-to-1 NAT if you have only one public IP address or a small number of public IP addresses. If you
have only one public IP address and configure 1-to-1 NAT, this configuration prevents all use of inbound Firebox
functions and the WatchGuard Support team cannot connect. If you have only a few public IP addresses, we
recommend SNAT to better utilize your public IP addresses.

If you configure 1-to-1 NAT, be aware that IP addresses used for 1-to-1 NAT cannot be used for
other purposes. For example, you cannot also use 1-to-1 IP addresses for inbound traffic or for
Firebox features such as VPNs, Access Portal, or Support Access.

Configuration Example
Consider a situation in which you fully dedicate public IP addresses to specific internal devices, but these public IP
addresses will not be available for any other Firebox functions. You can use 1-to-1 NAT to map public IP addresses to
the internal devices. You do not need to change the IP addresses of your internal devices.

This example explains how an administrator could configure 1-to-1 NAT:

A company has a group of three privately addressed servers behind the optional interface of the Firebox. These
addresses are:
10.0.2.11
10.0.2.12
10.0.2.13

The administrator selects three public IP addresses from the same network address as the external interface of the
device and creates DNS records for the servers to resolve to. These addresses are:
203.0.113.11
203.0.113.12

Network Security Essentials for Locally-Managed Fireboxes Study Guide 106

 Network Settings

203.0.113.13

Now the administrator configures a 1-to-1 NAT rule for the servers. The 1-to-1 NAT rule builds a static, bidirectional
relationship between the corresponding pairs of IP addresses. The relationship looks like this:
10.0.2.11 <--> 203.0.113.11
10.0.2.12 <--> 203.0.113.12
10.0.2.13 <--> 203.0.113.13
When the 1-to-1 NAT rule is applied, the Firebox creates the bidirectional routing and NAT relationship between the
pool of private IP addresses and the pool of public addresses.

To connect to a computer located on a different Firebox interface that uses 1-to-1 NAT, you can use the private (NAT
base) IP address for that computer. Or, you can create a 1-to-1 NAT mapping for the other interface.

Define a 1-to-1 NAT Rule

In each 1-to-1 NAT rule, you can configure a host, a range of hosts, or a subnet. A 1-to-1 NAT rule always has
precedence over dynamic NAT. In each rule, you specify:

Interface
The name of the device Ethernet interface on which 1-to-1 NAT is applied. The Firebox applies 1-to-1 NAT for
packets sent in to, and out of, the interface. In our example above, the rule is applied to the external interface.

Real base
The IP address assigned to the physical Ethernet interface of the computer to which you apply the 1-to-1 NAT
policy. When packets from a computer with a real base address go through the interface specified, the 1-to-1
action is applied. In our example above, the real base is 10.0.2.11.

NAT base
The IP address that the real base IP address changes to when 1-to-1 NAT is applied. In our example above,
the NAT base is 203.0.113.11.

Number of hosts to NAT (for ranges only)

The number of IP addresses in a range to which the 1-to-1 NAT rule applies. The first real base IP address is
translated to the first NAT base IP address when 1-to-1 NAT is applied. The second real base IP address in the
range is translated to the second NAT base IP address when 1-to-1 NAT is applied. This is repeated until the
Number of hosts to NAT is reached. In our example above, the number of hosts to apply NAT to is three.

Use 1-to-1 NAT with Branch Office VPNs

When you create a branch office VPN tunnel between two networks that use the same private IP address range, an
IP address conflict occurs. To prevent this, both networks must apply 1-to-1 NAT on the tunnel routes within the VPN
configuration. This makes the IP addresses on your computers appear to be different from their true IP addresses
when traffic goes through the VPN. You would also use 1-to-1 NAT through a VPN if the network to which you want to
make a VPN already has a VPN to a network that uses the same private IP addresses you use. For more information,
see the BOVPN and NAT section.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 107

 Network Settings

NAT Loopback
With NAT loopback, local network users can connect to an internal server with the public IP address or domain name
of that server. When the Firebox receives a local user request to connect to that server, the Firebox changes the
public IP address or domain name to the private IP address. The connection loops back to the internal network
instead of out to the Internet.

To map a public IP address to a private IP address, you must use static NAT (SNAT) or 1-to-1 NAT. In most cases,
we recommend SNAT.

For more information about these NAT methods, see the Static NAT (SNAT) and 1-to-1 NAT sections in this guide.

To configure NAT loopback with SNAT:

1. Create a SNAT action that maps the public IP address to the private IP address.
2. Create or edit a policy for traffic to the server.
3. In the From field, specify one or more aliases for users on your local network, such as Any-Trusted and Any-
Optional.
4. Add the SNAT action to the policy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 108

 Network Settings

Network Security Essentials for Locally-Managed Fireboxes Study Guide 109

 Firewall Policies

Firewall Policies
Firewall policies control what types of connections and content the Firebox allows.

In this section you learn about:

n Policy From and To fields
n Aliases
n Management policies
n Policy precedence
n Policy Checker
n Hidden policies
n Limiting policy scope
n Policy logging settings
n Policy schedules
n Packet filters and proxy policies

For a list of additional resources on these topics, see Firewall Policies Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 110

 Firewall Policies

Policy Source and Destination

In each policy, you specify the source and destination of connections the policy applies to. A connection must match
both the source and destination specified in the policy for the policy to apply to that traffic.

In each policy, you configure:

n A From list (or source) that specifies the source of connections that this policy applies to.
n A To list (or destination) that specifies the destination of connections that this policy applies to.

The members of the source and destination lists can be an IPv4 or IPv6 host IP address, host IP range, host name,
network address, user name, alias, VPN tunnel, FQDN, or any combination of these objects. A destination can also
be a static NAT action.

Aliases
An alias is a shortcut that identifies a group of hosts, networks, or interfaces. When you configure a policy, you can
use aliases in the From and To lists to specify the traffic sources and destinations the policy applies to.

There are four default aliases that group interfaces based on interface type, which are also known as zones:
n Any-Trusted — Any network you can get access to through Firebox interfaces configured as Trusted
n Any-Optional — Any network you can get access to through Firebox interfaces configured as Optional
n Any-External — Any network you can get access to through Firebox interfaces configured as External
n Any-BOVPN — All BOVPN (IPSec) virtual interfaces and tunnel routes

Each interface name is also an alias.

There is no alias for interfaces with the interface type of Custom.

Other default aliases include:

n Firebox — All primary and secondary IP addresses assigned to all Firebox interfaces
n Any — Any source or destination, including all users, groups, interfaces, addresses, tunnels, and custom
interfaces
n Microsoft365 — Domain names and IP addresses used by Microsoft 365 (automatically updated by
WatchGuard)

Alias members can include a combination of these types of addresses:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 111

 Firewall Policies

Alias Member Description

Host IP address A single IP address.

Network IP address A network IP address.

IP address range A range of host IP addresses.

Wildcard IPv4 An IP address pattern with wildcards in the netmask.

address

Host Name Performs a one-time DNS lookup on the host name and adds resolved IP addresses to
(DNS lookup) the alias.

FQDN (Fully Qualified Performs forward DNS resolution and analyzes DNS replies for the specified FQDN
Domain Name) (includes wildcard domains). Resolved IP addresses from the primary domain and any
subdomains are added to the alias.

Tunnel address Defined by a user or group, address, and name of the tunnel.

Custom address Defined by a user or group, address, and Firebox interface.

Another alias Any other alias.

User or group An authorized user or group.

FQDN
You can use FQDNs to specify a specific host domain (host.example.com) or a wildcard domain
(*.example.com). For example, the wildcard domain *.example.com includes:

a.example.com
b.example.com
a.b.example.com

You can also use subdomain wildcards, such as:

*.b.example.com
*.b.c.example.com
*.b.c.d.example.com

You can use FQDNs in:

n Source (From) and destination (To) lists in a policy
n Aliases
n Blocked sites and blocked site exceptions
n Quota exceptions

When you use an FQDN, your Firebox performs forward DNS resolution for the specified domain and stores the IP
mappings. For wildcard domains, the Firebox analyzes DNS replies that match the FQDN. As DNS traffic passes
through the Firebox, it stores the IP mapping responses for the domain and any subdomains. The Firebox stores up
to 255 IP addresses for each domain.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 112

 Firewall Policies

With FQDNs, you can allow traffic to software update sites or antivirus signature update sites, even though all other
traffic is blocked. This is especially useful when these sites are hosted on content networks (CDNs) that frequently
add and change IP addresses.

USE CASE:

To configure an HTTPS policy to allow connections to Windows update sites, specify these wildcard
FQDNs in the policy To list:
*.windowsupdate.com
*.microsoft.com
*.windows.com
officecdn.microsoft.com.edgesuite.net
officecdn.microsoft.edgesuite.net

Network Security Essentials for Locally-Managed Fireboxes Study Guide 113

 Firewall Policies

Management Policies

The WatchGuard and WatchGuard Web UI policies allow management connections to the
Firebox. It is important not to delete or disable these policies.

In the Firebox configuration, two management policies control management connections to the Firebox:

WatchGuard Web UI
This policy allows connections to the Fireware Web UI, hosted on the Firebox. This policy allows
TCP connections to the port used for Fireware Web UI (port 8080 is the default).

WatchGuard
This policy allows management connections to the Firebox from WatchGuard System Manager and the
Fireware Command Line Interface (CLI). This policy allows connections from WatchGuard System Manager
on TCP port 4117, and connections from the CLI on TCP port 4118.

Do not delete or disable these management policies. If you delete these policies you cannot
connect to the Firebox to manage it.

By default, these policies allow management connections from Any-Trusted and Any-Optional to the Firebox. This
means that an administrative user can connect from any computer on the trusted or optional network. You can edit
the From list to more explicitly control who can connect to the Firebox for management.

By default, FireboxV and Firebox Cloud allow management connections from Any-External. We
recommend that you remove the Any-External alias from the From list of the management
policies after initial setup.

We recommend that you do not add the Any-External alias to the From list of the management
policies. This allows anyone outside the network to try to log in to manage your Firebox. A
more secure way to enable remote management is for administrators to use a VPN to connect
to the trusted network and then connect to the Firebox. Or, in the policy From list, add the
specific public IP addresses from which you want to allow management connections. For
example, you could add the public IP address of your main office Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 114

 Firewall Policies

Limit Policy Scope

To limit connections allowed through the Firebox:

n Configure policies for the traffic you want to allow

n Specify the policy source and destination as narrowly as possible

n Disable the default Outgoing policy

The default policies provide a good starting point for your configuration. You can change the source and destination
of the policies and configure additional policies to further limit allowed traffic based on the connections and protocols
you want to allow, deny, or control.

We always recommend that you configure policies with the concept of "least privilege", which
means that you only allow traffic through specific ports necessary to conduct business-related
activities.

Before you edit the policy configuration, consider which connections and content types you want to allow, deny, or
control. It is important to configure policies with a limited scope to allow only the traffic that is necessary for your
users.

Here are some examples of things to consider:

n Web browsing — Do you want to control outbound web access from your network?
o Edit the default HTTP-proxy and HTTPS-proxy policies to configure proxy settings to enforce your

computer use policy.

n Mail server — Do you want to protect an SMTP server on the private network?
o Add an SMTP-proxy policy for incoming SMTP connections.

n Web server — Do you want to protect a public web server on the private network?
o Add HTTP-proxy and HTTPS-proxy policies to allow incoming connections to that server.

n Other resources — Do you have other servers or resources that must be accessible from outside your private
network?
o Add a policy that allows traffic with the required port and protocol to the server.

n Users and groups — Do you want to allow different access for different users or monitor user activity?
o Set up authentication and add different policies for each user group.

n Communication between internal networks — Do you want to allow internal hosts to connect to resources on
other internal networks?
o Edit the default HTTP-proxy and HTTPS-proxy policies to enable communication between internal

networks.

Examine the default policies and consider whether you can modify these to further control outbound connections from
your network.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 115

 Firewall Policies

Outgoing Policy
The default Outgoing policy is a TCP-UDP policy that allows all TCP and UDP connections from any trusted or
optional source on your network to any external network. Because it is a packet filter policy, not a proxy policy,
the Outgoing policy has limited filtering capabilities.

HTTP-proxy, HTTPS-proxy, and FTP-proxy policies

The default HTTP-proxy, HTTPS-proxy, and FTP-proxy policies allow outbound HTTP, HTTPS, and
FTP connections from any trusted or optional network to any external network. Because the proxy policies
have higher precedence than the default Outgoing policy, they allow and filter outbound HTTP, HTTPS, and
FTP connections.

You can add other proxy policies and services to filter and control other outgoing TCP and UDP connections.
However, there are some types of TCP and UDP connections (particularly on non-standard ports) that cannot have
all services applied.

For all policies, consider whether you can limit the sources and destinations for allowed connections.

If you want to remove the Outgoing policy, but you want to allow trusted users on your network to connect to web
sites, make sure the configuration includes an HTTP-proxy policy for port 80, an HTTPS-proxy policy for port 443,
and a DNS policy for port 53 to allow DNS query resolution.

When you create a DNS policy, we recommend that you add the specific IP addresses of the
DNS servers to the To list, instead of adding Any-External.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 116

 Firewall Policies

Policy Precedence

Only one policy applies to each connection. The Firebox uses the highest-precedence policy to
determine whether to allow or deny a connection. Network traffic that does not match any policy
is denied as an unhandled packet.

Precedence refers to the order in which the Firebox examines network traffic and applies a policy rule. The Firebox
sorts policies automatically, from the most specific to the most general. For example, a very specific policy might
match only traffic on TCP port 25 from one IP address, while a more general policy might match all traffic on UDP
ports 40,000 to 50,000. You can also set the precedence of each policy manually.

By default, the Firebox policies are configured in Auto-Order mode. In Auto-Order mode, the Firebox automatically
sorts policies from the most specific to the most general, based on a comparison of these policy properties:
n Policy (specificity)
n Ports and protocols
n Source and destination (From and To)
n Disposition (Firewall action)
n Schedule

In the policy list, the Order column shows the order of policy precedence.

Policies higher in the list have higher precedence. When the Firebox receives a packet, it applies the highest
precedence policy that matches the characteristics of the packet. When Auto-Order mode is enabled, if two policies
are equally specific, a proxy policy takes precedence over a packet filter policy. Only the highest precedence policy
that matches the port, protocol, source, and destination applies to a packet. You can also disable Auto-Order mode
and manually change the order of policies.

To allow different levels of access to network resources for different users, groups, or networks, you can add multiple
policies for the same port/protocol with different sources or destinations. For example, you could configure an HTTP-
proxy policy for a specific department to allow more limited or broader access to resources than the lower priority
default HTTP-Proxy policy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 117

 Firewall Policies

Set Precedence Manually

You can change to Manual-Order mode and set the policy precedence for your policies manually. This requires more
careful management, particularly if your configuration has a lot of policies.

We recommend that you use Auto-Order mode to set policy precedence until it does not work
for your specific situation. If you change to Manual-Order mode, make sure that you test the
order of policies carefully.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 118

 Firewall Policies

Policy Checker

To use Policy Checker to test the outcome of configured policies on the Firebox:
n Specify the source network interface

n Specify the protocol

n Specify the source and destination address for the test traffic

Policy checker is only available in Fireware Web UI.

In Fireware Web UI, you can use Policy Checker to see how your Firebox manages particular traffic so you can
troubleshoot issues with your policies. For example, you might run into issues where the Firebox allows or denies
traffic in a way you did not expect.

To determine how the traffic is processed by your policies with Policy Checker, you specify:
n An active source network interface — The interface you select is the source interface where the traffic
originates. For example, if you select the External interface, the Firebox will treat the connection as inbound.
n Protocol (Ping, TCP, or UDP)
n Source and Destination IP address
n Source and Destination Port (if the protocol is TCP or UDP)

A test packet is sent through the Firebox to see how it is handled.

n If the packet was managed by a policy, the policy details appear in the Results section.
n Policies that manage the traffic are highlighted in the Firewall Policies list.
n If the packet was not managed by a policy, but by another security feature (such as a blocked site match), the
information appears in the Results section, and no policy is highlighted in the Firewall Policies list.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 119

 Firewall Policies

Hidden Policies

The Firebox uses a high precedence hidden policy to allow traffic from the Firebox itself, and
two low precedence policies to deny unhandled packets received from internal and external
networks. It also has a hidden policy to allow IPSec VPN connections to the Firebox.

The Firebox has four hidden policies in addition to the firewall policies you configure. These policies do not appear in
the configuration, but do appear in the Service Watch tab in Firebox System Manager.

Unhandled Packets
The Firebox fails closed. This means that the Firebox denies all traffic that does not match the configured policies. To
do this, the Firebox uses hidden policies that have lower precedence than all the configured policies.

These two hidden policies drop unhandled packets:

Unhandled Internal Packet

This policy denies outgoing connections that are not explicitly allowed by another policy.

Unhandled External Packet

This policy denies incoming connections that are not explicitly allowed by another policy.

These policy names appear in log messages when the hidden policies deny unhandled traffic.

Traffic From the Firebox

There is also a hidden policy that allows traffic generated by the Firebox itself. This policy has a higher precedence
than all other policies, so that traffic from the Firebox is always allowed.

Any From Firebox

Allows connections from the Firebox itself to any network destination.

Examples of Firebox-generated traffic include:

n Signature updates for WatchGuard services such as Gateway AntiVirus, Intrusion Prevention Service,
Application Control, Data Loss Prevention, Botnet Detection, and Geolocation
n Queries to WatchGuard servers for services such as WebBlocker, spamBlocker, and APT Blocker
n VPN traffic for tunnels not tied to an interface, such as SSL management tunnels and BOVPN over TLS
tunnels
n Log traffic from the Firebox to a Dimension server or WatchGuard Cloud

If you want to see this policy in the policy list, and add other policies to control Firebox-generated traffic, you can
enable the Enable configuration of policies for traffic generated by the Firebox global setting.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 120

 Firewall Policies

Enable this setting with care. Incorrect configuration of policies for Firebox-generated traffic,
can cause serious problems. For example, a configuration error could prevent management
connections to the Firebox, prevent updates to Firebox services, and prevent Firebox
connections to a Management Server, Dimension, or WatchGuard Cloud.

Before you enable this setting, see Fireware Help for more information and configuration examples.

Built-In IPSec Policy

The Firebox has a built-in IPSec policy that allows IPSec-based VPNs (mobile and BOVPN) to terminate on the
Firebox.

Allow-IKE-to-Firebox
Allows IPSec VPN connections to the Firebox itself.

This hidden policy exists when the Enable the built-in IPSec Policy check box is selected in the global VPN
settings. This check box is selected by default. If you disable this setting, the hidden policy is removed and IPSec
VPN connections will fail.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 121

 Firewall Policies

Policy Logging and Notification

By default, policies send a log message when they deny a connection. You can also configure
policies to send a log message when they allow a connection. A separate log setting controls
whether policies send log messages used by Dimension and WatchGuard Cloud to generate
reports.

Policy Logging Settings

In the policy properties, you can configure logging settings. Policies have two different logging settings that control
two types of log messages the policy can send.

Send a log message

Sends a log message to the log file at the start of each connection. These log messages are useful for
monitoring and troubleshooting connection or policy issues. These are the log messages you see in Traffic
Monitor.

Policies that deny connections always send a log message when a connection is denied.

If you do not need to actively monitor allowed connections in the log file, we recommend you
do not select Send a log message for policies that allow traffic. This increases CPU load on
the Firebox and reduces log storage in Dimension.

Send a log message for reports

Sends a log message to Dimension or WatchGuard Cloud at the end of a connection. The log message
includes connection duration and bandwidth for reports only. The log messages do not appear in Traffic
Monitor for packet filters.

If you use Dimension or WatchGuard Cloud, make sure that you configure all policies to send a log message
for reports.

In packet filter policies that allow connections, you configure this setting in the policy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 122

 Firewall Policies

In proxy policies, you enable logging for reports in the proxy action on the General Settings tab. When you
select Enable logging for reports in a proxy action, the log messages for allowed traffic also appear in Traffic
Monitor.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 123

 Firewall Policies

Log Messages for Denied Traffic

Log messages for denied traffic show the name of the policy that denied the traffic as well as information about the
source, destination, port, and protocol. Most denied traffic log messages include the name of one of the two hidden
policies that deny unhandled traffic.

Because the Firebox denies all traffic from the external network by default, you will see traffic log messages that
contain Unhandled External Packet. For example:
2019-06-07 16:38:36 Deny 203.0.113.110 203.0.113.10 2055/udp 57233 2055 0-External Firebox Denied
1492 64 (Unhandled External Packet-00) proc_id="firewall" rc="101" msg_id="3000-0148" Traffic

A policy that denies traffic is configured by default to send a log message when it denies a connection.

Log Messages for Allowed Traffic

By default, policies do not generate a log message when they allow a connection. If you want to see log messages for
allowed traffic, you must enable logging in the policy.

View Policy Logs in Traffic Monitor

In Firebox System Manager and Fireware Web UI, you can use Traffic Monitor to see which policy allowed or denied
a connection and why.

For more information on how to see Policy logs in Traffic Monitor, see Read Traffic Log Messages in Traffic Monitor in
the Logging and Monitoring section of this guide.

Policy Notification Settings

For each policy, you can configure alarms in order to receive notifications. You can configure the policy to send
SNMP traps or notifications by email.

Send SNMP Trap

This option configures the policy to send an event notification to the SNMP management system. Simple
Network Management Protocol (SNMP) is a set of tools used to monitor and manage networks. An SNMP trap
is an event notification the device sends to the SNMP management system when a specified condition occurs.

Send Notification
This option configures the policy to send notifications about alarms.

When you enable notification, you specify a notification method. We recommend that you select the default
Email notification method. Dimension and WatchGuard Cloud cannot generate pop-up notifications.

Alarms trigger the notifications and appear on the Alarms report in Dimension and WatchGuard Cloud.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 124

 Firewall Policies

Policy Schedules

Policy schedules control which days and times a policy is operational.

You can configure policies to be operational only at the times you specify. A policy is always operational unless you
set a custom policy schedule in the policy advanced settings.

In the policy schedule you select the days of the week and the hours when the policy is operational. For example, you
could create a schedule that allows specific types of traffic only during business hours.

You can apply the same policy schedule to multiple policies. By default, all policies use the Always On predefined
policy schedule.

If two policies are otherwise the same, the policy with the more limited schedule has higher precedence.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 125

 Firewall Policies

Packet Filters and Proxy Policies

Fireware supports two types of policies:

n Packet Filter — examines only the IP header
n Proxy Policy — examines the IP header, and the protocols and data in the packets

Fireware supports two types of policies, packet filters and proxy policies. These policy types examine data at different
layers of the OSI model.

This table shows the types of information each policy type can examine:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 126

 Firewall Policies

Packet Filter Proxy and ALG

Source

IP Header Destination

Port(s)/Protocols

Packet body

Attachments/Files
Packet Content
RFC compliance

Commands

Packet filters are an easy way to allow or deny large amounts of traffic. Proxies can prevent potential threats from
reaching your network without blocking the entire connection. The Firebox configuration includes default sets of rules,
called proxy actions, for each type of proxy policy. You can use the default settings for each type of proxy action, or
you can customize them.

At a high level, this is how each type of policy operates:

Packet Filter Policy

n Examines the IP header of each packet at the network and transport protocol packet layers.
n If the packet header information is legitimate and the content of the packet header matches a packet filter
policy that allows traffic, the Firebox allows the packet.
n Otherwise, the Firebox drops the packet.

Proxy Policy or ALG (Application Layer Gateway)

n Examines both the IP header information and the content of each packet at the application layer to make sure
that connections are compliant with protocols.
n If the packet header information is legitimate, and the content of the packet matches the criteria set in the
proxy policy, then the Firebox allows the packet.
n If the content does not match the criteria set in the proxy policy, the proxy drops the packet or, in some cases,
allows the packet and removes disallowed content.
n An ALG completes the same functions as a proxy, but also provides transparent connection management.

In this guide, the term policies refers to both packet filters and proxies, unless otherwise
indicated.

Fireware supports these proxy policies:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 127

 Firewall Policies

n DNS
n Explicit Proxy
n FTP
n H323 (ALG)
n SIP (ALG)
n HTTP
n HTTPS
n SMTP
n POP3
n IMAP
n TCP-UDP (TCP and UDP on all ports)

The FTP packet filter and proxy policies do transparent connections management for the FTP
data channel. The FTP policy is configured for TCP port 21, which is used for the
FTP handshake. The FTP policy dynamically opens another negotiated port for data transfer.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 128

 Security Services

Security Services
Security services extend the built-in defenses of your Firebox to help you secure your network.

In this section you learn about:

n How security services work to protect your network
n Services in the Basic and Total Security Suites
n Services enabled in packet filters and proxy policies
n Security service signature updates
n Intrusion Prevention Service (IPS)
n Application Control

For a list of additional resources on these topics, see Security Services Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 129

 Security Services

Security Services Overview

WatchGuard offers powerful network security services that enable your Firebox to protect your networks and users
from attacks.

WatchGuard partners with third-party vendors to supply our services, so we can offer the industry’s best features and
protection.

You can enable and configure these security services on your device:

Access Portal
Clientless VPN solution that provides a central location for your users to connect to cloud-hosted applications
and internal resources.

Application Control
Monitors and controls the use of applications on your network. Application Control uses signatures that can
identify and deny over 1000 applications.

APT Blocker
Cloud-based service that uses emulation analysis to identify the characteristics and behavior of zero-day
malware.

Botnet Detection
Denies known botnet site IP addresses.

Data Loss Prevention (DLP)

Prevents the unauthorized transmission of confidential information outside your network.

DNSWatch
Detects and denies DNS requests to known malicious domains.

Gateway AntiVirus
Scans files to detect viruses in email messages and web or FTP traffic.

Geolocation
Denies connections to or from the countries you specify.

IntelligentAV
Uses artificial intelligence and machine learning to identify and deny known and unknown malware.

Intrusion Prevention Service (IPS)

Uses signatures to provide protection against known software vulnerabilities.

spamBlocker
Identifies and denies unwanted and dangerous spam email messages.

Tor Exit Node Blocking

Blocks known Tor exit node IP addresses.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 130

 Security Services

WebBlocker
Controls access to websites based on content categories.

If you do not want to scan a specific file with APT Blocker, Data Loss Prevention, Gateway
AntiVirus, and IntelligentAV, you can add the MD5 hash of the file to the File Exceptions list.

Security Services in Basic and Total Security Suites

To enable and configure security services on your device, you must first purchase a feature key. This table shows
which features and security services are licensed as part of Basic Security Suite and Total Security Suite
subscriptions:

Features and Services Basic Security Suite Total Security Suite

Access Portal1

Application Control

APT Blocker

Botnet Detection

Data Loss Prevention2

DNSWatch

EDR Core

Gateway AntiVirus

Geolocation

IntelligentAV1

Intrusion Prevention Service

Network Security Essentials for Locally-Managed Fireboxes Study Guide 131

 Security Services

Features and Services Basic Security Suite Total Security Suite

spamBlocker

Tor Exit Node Blocking

WebBlocker

Support Standard (24× 7) Gold (24×7)

1 Available on Firebox T40, T45, T80, and T85, Firebox M Series devices, Firebox Cloud, and FireboxV.
2 Not available on Firebox T20, T25, T40, T45, T80, T85, M290, M390, M590, M690, M4800, and M5800 devices.

WatchGuard EDR Core is included in the Firebox Total Security Suite and is a replacement for
the TDR Host Sensor. EDR Core includes a subset of the endpoint security features available
with WatchGuard EDR and supports XDR capabilities through ThreatSync.

Signature Updates
The Gateway AntiVirus, Intrusion Prevention Service, Application Control, Data Loss Prevention, Botnet Detection,
and Geolocation security services use a frequently-updated set of signatures to identify the latest viruses, threats,
and applications. IntelligentAV does not use signatures to identify viruses, but does need to download occasional
updates. You can manually get the latest signatures or updates for these services from the Subscription Services
tab in Firebox System Manager or Fireware Web UI.

Tor Exit Node Blocking uses a database of known Tor exit node IP addresses from Reputation Enabled Defense
(RED). You can manually get the latest updates for this service from the Subscription Services page in Fireware
Web UI.

If the signatures on the Firebox are not current, you are not protected from the latest viruses and intrusions. To make
sure that you always have the latest signature updates, configure all signature-based services to update signatures
automatically. To do this, click Update Server when you configure the service, then select the signatures you want to
update automatically.

To make sure that the Firebox can connect to the update server, you must add at least one DNS server to your
network configuration. The Firebox uses DNS to resolve the update server URL to an IP address.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 132

 Security Services

Policies and Security Services

The security services you use might determine which policies you need to configure on your device. You enable
some security services globally, but you must enable and configure most services in a policy.

You can enable these security services in any packet filter policy or proxy policy:
n Application Control
n Geolocation
n Intrusion Prevention Service
n Tor Exit Node Blocking

You can enable these security services in proxy policies only:

Security Service Supported Proxy Policies

APT Blocker HTTP, HTTPS, SMTP, POP3, IMAP, FTP

Data Loss Prevention HTTP, HTTPS, SMTP, FTP

Gateway AntiVirus/IntelligentAV HTTP, HTTPS, SMTP, POP3, IMAP, FTP, TCP-UDP

WebBlocker HTTP, HTTPS

To use all services except WebBlocker, Botnet Detection, Geolocation, and DNSWatch for
HTTPS traffic, you must configure the HTTPS proxy to use the Inspect action, and select the
HTTP proxy action that has the services enabled.

Intrusion Prevention Service and Application Control are enabled in the proxy policy, not in the
proxy action. They require content inspection to fully function. If you enable these services in an
HTTPS proxy policy, you must also enable Content Inspection in the HTTPS proxy action.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 133

 Security Services

Intrusion Prevention Service

The Intrusion Prevention Service (IPS) includes a set of signatures associated with specific commands that could be
harmful, as well as patterns for known software exploits. IPS compares traffic to these signatures to identify intrusion
attacks.

When a new intrusion threat appears on the Internet, the features that make the intrusion unique are recorded as a
signature. To make sure that you always have the latest IPS signatures, enable automatic signature updates.

You configure the Intrusion Prevention Service globally. When you enable IPS, it is enabled for
all policies by default. You can selectively disable it for specific policies, if needed. We
recommend that you disable IPS on default Firebox management policies, such as the
WatchGuard Web UI policy.

IPS Scan Modes

IPS can operate in one of two scan modes.

Full Scan
IPS scans all packets within connections handled by policies with IPS enabled. This mode is the most secure
because it catches evasion techniques, but there is a performance trade-off.

Fast Scan
IPS scans fewer packets within each connection to improve performance. This option greatly improves the
throughput for scanned traffic, but does not provide the comprehensive evasion coverage of Full Scan mode.

We recommend you use the Full Scan mode in most environments.

IPS Threat Levels and Actions

IPS groups signature threats into five threat levels: Critical, High, Medium, Low, and Information. When you enable
IPS, you can configure the action that the Firebox takes for content that matches IPS signatures at different threat
levels.

The actions IPS can take for each threat level are:
n Allow — Allows the content, even if it matches an IPS signature.
n Drop — Drops the content and drops the connection. No information is sent to the sender.
n Block — Blocks the packet, and adds the source IP address to the Blocked Sites list.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 134

 Security Services

By default, IPS drops and logs all traffic that matches an IPS signature at the Critical, High,
Medium, or Low threat level.

You can configure exceptions for specific signature IDs if IPS blocks content that you want to allow. Exceptions apply
to all policies that have IPS enabled.

IPS Deny Message

When IPS blocks HTTP content, the user who requested the content sees an IPS deny message in the browser. The
deny message says that the content was blocked. The message is not configurable. When IPS drops other types of
traffic, no deny message appears.

Get Information About IPS Signatures

To get additional information about IPS signatures and the threats they protect against, you can look up an IPS
signature in the WatchGuard Intrusion Prevention server (IPS) section of the WatchGuard Security Portal
(https://securityportal.watchguard.com/Threats).

Network Security Essentials for Locally-Managed Fireboxes Study Guide 135

 Security Services

Application Control
Application Control is a security service that enables you to monitor and control the use of web-based applications on
your network. Application Control uses over 1800 signatures that can identify and block traffic for over 1000
applications.

The Application Control signatures are updated frequently to identify new applications and to
stay current with changes to existing applications. To make sure that you always have the
latest signatures, enable automatic signature updates.

Application Control Actions

To configure Application Control, you add Application Control actions that specify which applications to allow or drop.

You can deny the use of specific applications or all applications in an application category. For example, you could
create an Application Control action to drop all applications in the Social Networks and Online Games categories.

For some applications, you can configure an Application Control action to selectively allow some application
behaviors (such as chat), but drop others (such as file transfer).

We recommend that you do not modify the predefined Global Application Control action.
Clone the action or create a new one.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 136

 Security Services

If you have configured Traffic Management actions, you can also use Traffic Management
actions in the Application Control action to control the bandwidth used for allowed application
traffic.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 137

 Security Services

Application Control and Policies

When you create an Application Control action, it is not automatically applied to your policies. You must enable
Application Control in the policy and specify which action to use.

USE CASE:

The flexibility offered by policy-based Application Control enables you to exercise granular control over
the use of applications on your corporate network. For example, you can:
n Block YouTube, Skype, and QQ
n Block P2P applications for users who are not part of the IT team
n Allow the marketing department to use social networking sites such as Facebook and Twitter
n Allow use of Windows Live Messenger for instant messaging, but disallow file transfers
n Limit the use of streaming media application to specific hours
n Limit the bandwidth used by certain applications with traffic management

Network Security Essentials for Locally-Managed Fireboxes Study Guide 138

 Security Services

Application Control Deny Message

When Application Control blocks HTTP content that matches an Application Control action, the user who requested
the content sees an Application Control deny message in the browser. The deny message says that the content was
blocked because the application was not allowed. The message is not configurable. When Application Control drops
other types of traffic, no deny message appears.

Get Information About Application Control Signatures

You can get more information about the Application Control signatures in the Application Control section of the
WatchGuard Security Portal (https://securityportal.watchguard.com/Applications).

Network Security Essentials for Locally-Managed Fireboxes Study Guide 139

 Proxies and Proxy-Based Services

Proxies and Proxy-Based Services

You can use proxy policies to protect servers and clients from threats. Proxy policies examine the contents of each
packet to determine whether network traffic is safe and adheres to your network security and acceptable use policies.
Security services that examine the content of packets are configured in proxy policies.

In this section, you learn about:

n Proxy policies and services that require proxy policies
n Proxy actions
n Gateway AntiVirus and IntelligentAV
n APT Blocker
n HTTP proxy actions and log messages
n HTTP proxy action settings for antivirus scans and WebBlocker
n HTTPS proxy actions and content inspection
n Routing actions and HTTP content actions

For a list of additional resources on these topics, see Proxies and Proxy-Based Services Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 140

 Proxies and Proxy-Based Services

Proxies and Proxy Actions

A proxy policy is similar to a packet filter policy, except that it contains a set of additional rules called a proxy action to
examine traffic. An Application Layer Gateway (ALG) is like a proxy policy, but it also enables the Firebox to manage
network connections needed for some Voice Over IP (VoIP) sessions to operate.

Proxies and ALGs provide a more secure method for moving traffic through a Firebox. Proxies open the packets,
inspect the data payload, manipulate data, repackage the data, and send the packets on. This gives you more
visibility and control over the traffic that passes through a connection.

Proxies and ALGs also pass traffic more slowly than packet filters, because the Firebox inspects and applies rules to
more than the IP headers. Proxies enforce specific RFC protocol compliance. If traffic is not compliant with the
protocol, the proxy denies it.

Because proxy policies scan all packets, proxies use more resources than packet filter policies.
Use proxies only when there is a specific need to do so. For example, use proxy policies when
you want to limit, scan, or filter certain kinds of traffic to enforce your company security policy.

Fireware supports eleven proxy policies and ALGs:

n DNS
n Explicit
n FTP
n H.323
n HTTP
n HTTPS
n IMAP
n POP3
n SIP
n SMTP
n TCP-UDP

Network Security Essentials for Locally-Managed Fireboxes Study Guide 141

 Proxies and Proxy-Based Services

Proxy Actions
A proxy action is a set of rules that determines whether the proxy policy allows, denies, or takes some other action for
the traffic it inspects. You configure many security service settings in proxy actions.

Predefined Proxy Actions

Fireware includes predefined proxy actions for each proxy type. Predefined proxy actions have settings to handle
incoming or outgoing traffic, or to protect clients or servers. You can think of the predefined proxy actions as
templates. You cannot edit predefined proxy actions, but you can clone a predefined proxy action and then edit the
clone.

Most proxy policies or ALGs have both a predefined client and a server proxy action with different configuration
options. The exceptions are the DNS-proxy, which has incoming and outgoing proxy actions, the Explicit-proxy,
which has only one proxy action, and the H.323-ALG and SIP-ALG, which only have client proxy actions.

In the proxy action list, the predefined proxy actions are in blue.

Proxy actions with names that include the suffix .Standard use settings recommended by WatchGuard. When you
add a new proxy policy, a .Standard proxy action is selected by default. Because different Fireboxes have different
licensed features, the predefined proxy actions do not enable or configure subscription-based security services.

Default Proxy Actions

Proxy actions with names that include the prefix Default- are created by the setup wizards and enable applicable
licensed services for each proxy policy.

If the Firebox does not have a feature key when you run the setup wizard, these proxy actions are not configured to
enable any subscription services.

You can edit the default proxy actions.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 142

 Proxies and Proxy-Based Services

If you add a new outgoing FTP, HTTP, or HTTPS policy, to make sure that licensed services
are enabled, use the Default-FTP-Client, Default-HTTP-Client, or Default-HTTPS-Client
proxy action instead of the .Standard predefined proxy actions.

Security Services and Proxy Actions

You can enable these security services only in a proxy action:
n Gateway AntiVirus and IntelligentAV
n Data Loss Prevention (DLP)
n APT Blocker
n spamBlocker
n WebBlocker

Network Security Essentials for Locally-Managed Fireboxes Study Guide 143

 Proxies and Proxy-Based Services

AntiVirus Scanning and Proxies

WatchGuard Gateway AntiVirus and IntelligentAV work together to scan content and identify
viruses. Select the AV Scan action to use Gateway AV and IntelligentAV to scan content.

The AV Scan Action

Proxy actions use Gateway AntiVirus to scan content only when you select the AV Scan action in the proxy action
rules.

For most content you want to allow, select the AV Scan action in your proxy action rules.
Select the Allow action only for content you want to allow without scanning.

The Default-FTP-Client, Default-HTTP-Client, and Default-HTTPS-Client proxy actions all enable the AV Scan
action in the proxy action rules. These default proxy actions are a good starting point because they enable
recommended scanning of FTP, HTTP, and HTTPS content.

The Default-FTP-Client proxy action Upload rules, with the AV Scan action selected

Network Security Essentials for Locally-Managed Fireboxes Study Guide 144

 Proxies and Proxy-Based Services

In addition to a Gateway AntiVirus scan, the AV Scan action also enables subsequent scans by IntelligentAV and
APT Blocker, if those services are enabled. These three services examine the content in different ways to provide
better detection of known viruses and other emerging threats.

The services scan content one at a time, in this order:

1. Gateway AntiVirus scans content when:

n The AV Scan action is configured in the proxy action rule.

2. IntelligentAV scans content only when:

n Gateway AntiVirus scan has completed with a clean result.

n Intelligent AV is enabled.
3. APT Blocker scans content only when:
n Gateway AntiVirus scan has completed with a clean result.

n IntelligentAV scan (if enabled) has completed with a clean result.

Gateway AntiVirus always scans content first. IntelligentAV and APT Blocker do not scan content when Gateway
AntiVirus is disabled. IntelligentAV is not a dependency for APT Blocker.

IntelligentAV is supported on these Firebox models:

n Hardware — Firebox T40, T45, T80, T85, and M Series (except M200/M300)
n Virtual — Firebox Cloud and FireboxV (VM must have 4GB RAM)

If Data Loss Prevention is enabled, DLP scans happen after all antivirus scans are complete.

IntelligentAV and APT Blocker are covered in more detail in these sections:
n IntelligentAV
n APT Blocker

Gateway AntiVirus and Proxies

Gateway AntiVirus scans different types of traffic for different proxies:
n Email — With the SMTP-proxy, IMAP-proxy, or POP3-proxy, Gateway AntiVirus finds viruses encoded with
frequently used email attachment methods. These include base64, binary, 7-bit, 8-bit encoding, and
uuencoding.
n FTP — With the FTP-proxy, Gateway AntiVirus finds viruses in uploaded and downloaded files.
n Web — With the HTTP-proxy or HTTPS-proxy, Gateway AntiVirus scans web pages and any uploaded or
downloaded files for viruses.

To enable Gateway AntiVirus to scan HTTPS content, you must enable content inspection in the HTTPS-proxy and
select an HTTP proxy action with Gateway AntiVirus configured, and the AV Scan option selected in the proxy action
rules.

Configure Gateway AntiVirus Actions

When you enable Gateway AntiVirus in a proxy action, you must specify the actions to take if a virus is found or a
scan error occurs.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 145

 Proxies and Proxy-Based Services

Gateway AntiVirus settings in an FTP-proxy action.

You can select from these Gateway AntiVirus actions:

Allow
Allows the packet to go to the recipient, even if the content contains a virus.

Deny (FTP and SMTP proxies only)

For the FTP proxy, denies the file and sends a deny message. For the SMTP proxy, this action denies delivery
of the message and sends an SMTP 554 Transaction Failed response to the sender with the reason the email
was denied.

Lock (SMTP, IMAP, and POP3 proxies only)

Locks the attachment. Users cannot open a locked file. Only the administrator can unlock the file. The
administrator can use a different antivirus tool to scan the file and examine the content of the attachment.

Quarantine (SMTP-proxy only)

Sends the email message with a virus or possible virus to the Quarantine Server.

Remove (SMTP, IMAP, and POP3 proxies only)

Removes the attachment and sends the rest of the message to the recipient. Replaces the removed
attachment with a text file that contains the deny message configured in the proxy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 146

 Proxies and Proxy-Based Services

Drop (not supported in IMAP or POP3 proxies)

Drops the packet and drops the connection. No information is sent to the source of the message.

Block (not supported in IMAP or POP3 proxies)

Blocks the packet and adds the IP address of the sender to the Blocked Sites list.

In addition, Gateway AntiVirus can scan traffic that matches rules in several categories in each proxy.

In the Proxy Action Configuration dialog box, in the Categories list, select one of these categories to get access to
the ruleset:

Proxy Categories

FTP-proxy Download

Upload

SMTP-proxy Attachments: Content Types

Attachments: Filenames

POP3-proxy Attachments: Content Types

Attachments: Filenames

HTTP-proxy HTTP Request: URL Paths

HTTP Response: Content Types

HTTP Response: Body Content Types

TCP-UDP-proxy (HTTP on dynamic ports) HTTP Request: URL Paths

HTTP Response: Content Types

HTTP Response: Body Content Types

Gateway AntiVirus Content Types and Compressed Files

Gateway AntiVirus scans the content types configured in the proxy action rules. Gateway AV and IntelligentAV can
scan many file types, such as Microsoft Office files and PDF files.

Gateway AV can also extract and scan files in a compressed archive, such as a Zip file. The number of compression
levels to scan in a compressed file depends on the amount of RAM the Firebox has. Firebox models with less than 2
GB RAM scan eight levels of compressed files. Firebox models with 2 GB or more RAM scan up to 16 levels of
compressed files.

The Firebox cannot scan encrypted files or files that use a type of compression that Gateway AntiVirus does not
support, such as password-protected Zip files. For a full list of compressed file types that Gateway AntiVirus can
scan, see Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 147

 Proxies and Proxy-Based Services

IntelligentAV

IntelligentAV only scans content that Gateway AV has scanned with a clean result.

The IntelligentAV subscription service uses artificial intelligence and machine learning to add another layer of
protection to Gateway AntiVirus. Before you can enable IntelligentAV, you must enable Gateway AntiVirus for one or
more active proxy policies. For a proxy policy to scan content with Gateway AntiVirus and IntelligentAV, you must
select the AV Scan action in the proxy action.

When IntelligentAV is enabled, Gateway AntiVirus uses two scan engines to detect malware. First, Gateway
AntiVirus scans the file. If Gateway AntiVirus does not detect a virus, IntelligentAV scans the file again. If
IntelligentAV identifies the file as a threat, the Firebox takes the action specified in the Gateway AntiVirus
configuration for the proxy.

IntelligentAV is available for Firebox T40, T45, T80, and T85, Firebox M Series (except M200/M300), Firebox Cloud,
and FireboxV. IntelligentAV does not scan files when Gateway AntiVirus is disabled or when the Gateway AntiVirus
feature key expires, even if IntelligentAV is enabled.

To use IntelligentAV with Firebox Cloud or FireboxV, the VM must have 4 GB or more RAM.

IntelligentAV Content Types

IntelligentAV can scan many file types, including Microsoft Office documents, PDF files, and Windows portable
executable (PE) files. For a full list of supported file types, see Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 148

 Proxies and Proxy-Based Services

APT Blocker

A proxy uses APT Blocker when both APT Blocker and Gateway AntiVirus are enabled and the
AV Scan action is configured in the proxy action. APT Blocker only scans files that have been
scanned and processed as clean by Gateway AntiVirus.

An Advanced Persistent Threat (APT) is a type of advanced malware that attacks your network to gain access to
networks and confidential data. APT malware is designed to reside and spread within a network for extended periods
of time and to evade detection.

Because APT attacks leverage the latest targeted malware techniques and zero-day exploits (flaws which software
vendors have not yet discovered or fixed), traditional signature-based scan techniques do not provide adequate
protection against these threats. To detect malware in files, APT Blocker performs threat analysis in a cloud-based
sandbox.

You can use APT Blocker with these proxies:

n Email — With the SMTP, POP3, or IMAP-proxy, APT Blocker finds advanced malware in email attachments.
n FTP — With the FTP-proxy, APT Blocker detects advanced malware in uploaded or downloaded files.
n Web — With the HTTP-proxy or HTTPS-proxy, APT Blocker scans web content and any uploaded or
downloaded files for advanced malware.

To enable APT Blocker to scan HTTPS content, you must enable content inspection in the HTTPS-proxy, and select
an HTTP proxy action with Gateway AntiVirus and APT Blocker configured, and the AV Scan option selected in the
proxy action rules.

APT Blocker, Gateway AntiVirus, and IntelligentAV

APT Blocker uses the same scan process as Gateway AntiVirus. You must enable Gateway AntiVirus in one or more
active proxy policies before you can enable APT Blocker. If a proxy policy is configured to enable Gateway AntiVirus
to scan traffic through the policy, you can also scan the traffic with APT Blocker. APT Blocker only scans files that
have been scanned and processed as clean by Gateway AntiVirus. If IntelligentAV is enabled, APT Blocker only
scans files that have been scanned and processed as clean or suspicious by IntelligentAV.

When the Firebox scans file with these services, it generates an MD5 hash for the file. This is used by Gateway
AntiVirus, IntelligentAV, APT Blocker, and Data Loss Prevention, in that order, to track the progress of the file through
the scan engines.

APT Blocker scans compatible file types if they are enabled in the Gateway AntiVirus configuration. For a proxy policy
to scan content with Gateway AntiVirus and APT Blocker, you must select the AV Scan action in the proxy action.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 149

 Proxies and Proxy-Based Services

APT Blocker Threat Levels

APT Blocker analyzes files for threats in a protected sandbox at an APT Blocker cloud-based data center. Based on
the analysis, APT Blocker assigns a threat level to each file, which indicates the severity of the threat:
n High
n Medium
n Low
n Clean

For each analyzed file, the data center stores the MD5 hash and threat level.

APT Blocker Scanning

The Firebox generates an MD5 hash for each file, and sends that value to the data center. If the MD5 value matches
a previously analyzed file, the data center immediately sends the analysis result for that file back to the Firebox. If the
result indicates that the file is malware, the Firebox can take immediate action to block, drop, or quarantine the file,
based on the threat level.

If the MD5 value of a file does not match a previously analyzed file, the Firebox uploads the entire file to the data
center for threat analysis. For proxies other than the SMTP and IMAP proxies, the Firebox allows the file while it waits
for the analysis result. When the Firebox receives the analysis result, if a threat was identified, the Firebox can
generate an alarm notification.

The Firebox stores APT Blocker results in a local cache so that if it encounters the same file again, the Firebox knows
the result and does not send the MD5 hash of the file to the data center.

The IMAP proxy always holds the message while it waits for an analysis result. For the SMTP proxy, an APT Blocker
setting in the SMTP proxy action controls whether the SMTP proxy releases messages when an attachment was sent
for APT Blocker analysis.

APT Blocker settings in an SMTP proxy action

Network Security Essentials for Locally-Managed Fireboxes Study Guide 150

 Proxies and Proxy-Based Services

Configure APT Blocker Actions

When you enable APT Blocker, you configure the action to take for each threat level.

APT Blocker actions.

The High, Medium, and Low threat levels indicate the severity of malware. The Clean threat level indicates the file
was scanned by the initial file hash check or by upload to the cloud data center, and was determined to be free of
malware. The Clean threat level helps you track the status of files that have been analyzed and are determined to not
contain malware.

We recommend you consider the High, Medium, and Low threat levels as malware and use
the default action of Drop.

For each threat level you can select one of these actions:

Allow
Allows and delivers the file or email attachment to the recipient, even if the content contains detected malware.

Drop
Drops the connection. No information is sent to the source of the message. For the SMTP-proxy and POP3-
proxy, the attachment is stripped before the message is delivered to the recipient.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 151

 Proxies and Proxy-Based Services

Block
Blocks the connection and adds the IP address of the sender to the Blocked Sites list. For the SMTP-proxy and
POP3-proxy, the attachment is stripped before the message is delivered to the recipient.

Quarantine (SMTP proxy only)

When you use the SMTP-proxy with APT Blocker, you can send email messages to the Quarantine Server.
The SMTP-proxy removes the part of the message that triggered APT Blocker and sends the modified
message to the recipient. The removed attachments are replaced with a text file that includes the deny
message that is configured in the proxy action settings.

For the HTTP-proxy and FTP-proxy, this action is converted to a Drop action. For the POP3-proxy, this action
is converted to a Strip action.

APT Blocker Notifications and Alarms

It is critical that you are aware of any advanced malware that enters your network. If a specific file has never been
seen before, APT Blocker sends it to the cloud service for advanced analysis. This analysis can take several minutes
to complete before the results return. During this time, the Firebox allows the file through to its destination.

When the scan results indicate that advanced malware is detected, you need to know immediately. To enable the
Firebox to send alarm notifications when APT Blocker detects a threat, in the APT Blocker notification settings,
enable notifications with the email notification method. The Firebox sends the alarm to WatchGuard Cloud or
Dimension. You can configure WatchGuard Cloud or Dimension to send email notifications for alerts received from
your Fireboxes.

Supported File Types

APT Blocker can analyze many file types, including Microsoft Office documents, RTF, PDF, and Windows portable
executable (PE) files. It can examine files within compressed archive files such as ZIP, GZIP, and TAR files.

For PDF files, you can specify whether APT Blocker submits unrecognized PDF files to the data center for analysis.

For a full list of supported file and archive types, see Fireware Help.

APT Blocker Scan Limits

The Gateway AntiVirus scan size limit also limits the maximum size of files that APT Blocker sends for analysis. The
default and maximum Gateway AntiVirus scan limits vary by device model. APT Blocker can analyze files up to 10
MB in size. If you set the Gateway AntiVirus scan limit to higher than 10 MB, APT Blocker does not upload files larger
than 10 MB for analysis.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 152

 Proxies and Proxy-Based Services

APT Blocker Server Settings

By default, the Firebox sends APT Blocker requests to the nearest cloud-based server. In the APT Blocker advanced
settings, you can configure APT Blocker to send requests to a server in a specific region, or to send requests to a
local on-premise server. You can also configure APT Blocker to use an HTTP proxy server to connect to the APT
Blocker cloud-based server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 153

 Proxies and Proxy-Based Services

HTTP-proxy Policies and Proxy Actions

An HTTP-proxy policy examines and filters HTTP traffic. The setup wizard automatically adds
an outgoing HTTP-proxy policy and configures the Default-HTTP-Client proxy action with
recommended services and settings.

HTTP (Hypertext Transfer Protocol) is a protocol used to send and display text, images, sound, video, and other
multimedia files on the Internet. The WatchGuard HTTP-proxy is a high-performance content filter. It examines web
traffic to identify suspicious content, such as malformed content, spyware, and other types of attacks. The HTTP-
proxy enforces RFC compliance with the HTTP protocol to prevent potential threats such as buffer overflow attacks.

Proxies for HTTP Traffic

There are two types of proxies for HTTP traffic, the HTTP-proxy and the Explicit-proxy.

HTTP-proxy
The HTTP-proxy operates between a web server and a client web browser. It processes each HTTP packet from the
server and checks for any potentially harmful content before it sends the packet to the client. The HTTP-proxy can
also act as a buffer between your web server and potentially harmful web clients.

Explicit-proxy
In a normal proxy configuration, the Firebox transparently proxies and inspects client connections to servers. In an
Explicit-proxy configuration, the Firebox accepts direct requests from clients, performs a DNS lookup and connects to
specified servers, and then retrieves the information on behalf of the client. In this configuration, the client is
specifically configured to use the Firebox as a proxy server. The Explicit-proxy also supports FTP and HTTPS.

Do not configure an Explicit-proxy for connections from Any-External. This creates an open proxy
accessible to the Internet, which makes it possible for someone to use your public IP address to
attack others.

For more information about using an explicit HTTP proxy, see Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 154

 Proxies and Proxy-Based Services

HTTP Proxy Actions

When you configure an HTTP-proxy policy, you must select a proxy action.

Select one of these default proxy actions for your policy:

HTTP-Client.Standard
Select this proxy action for an outbound HTTP-proxy. The HTTP-Client proxy action is configured to give
comprehensive protection to your network from the content your trusted users download from web servers.

Default-HTTP-Client
Select this proxy action for an outbound HTTP-proxy. This has the same settings as the HTTP-Client.Standard
proxy action, but also enables licensed services, such as WebBlocker. This proxy action is created by the Web
Setup Wizard or Quick Setup Wizard when you set up the Firebox.

If it exists in your configuration, we recommended that you use this proxy action for outbound HTTP proxies
because it enables security services.

HTTP-Server.Standard
Select this proxy action for an inbound HTTP-proxy. The HTTP-Server proxy action is configured to allow most
HTTP connections through to your public web server, but to stop any attempts to upload or delete files.

Do not select the proxy actions HTTP-Client or HTTP-Server. These proxy actions are
obsolete and do not enable all recommended settings. This can cause web browsing issues.

HTTP proxy actions are also available in the HTTPS-proxy when you select the Inspect action to decrypt and inspect
HTTPS content. For more information about HTTPS and content inspection, see HTTPS-proxy Policies.

In an HTTP-proxy, you can also select a content action, HTTP-Content.Standard. For information about when to use
a content action, see Content Actions and Routing Actions.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 155

 Proxies and Proxy-Based Services

Security Services
To further protect your network, you can enable these security services in the HTTP proxy action:

WebBlocker
Controls the websites trusted users are allowed to browse to. WebBlocker is available for the Default-HTTP-
Client, HTTP-Client.Standard and HTTPS.Client.Standard proxy actions, and any other proxy action you
configure for an outbound HTTP or HTTPS proxy.

Gateway AntiVirus and IntelligentAV

Scans HTTP traffic and can stop viruses before they can be downloaded to client computers and HTTP
servers on your network.

APT Blocker
Scans HTTP traffic and blocks APT (Advanced Persistent Threat) malware that takes advantage of zero-day
exploits to gain access to your network. APT Blocker uses full system emulation analysis to identify suspicious
characteristics and behavior of advanced malware and assign a threat score. For more information, see APT
Blocker.

The Web Setup Wizard and Quick Setup Wizard automatically enable these services (if licensed) in the HTTP-proxy
policy and configure the Default-HTTP-Client proxy action.

Control Outgoing HTTP Requests

The settings for HTTP-Client proxy actions give you complete control over the HTTP connections of your trusted
users. For example, you can:
n Configure URL Paths rules to control allowed content based on patterns in the URL path such as file names or
extensions.
n Configure Content Types rules to control allowed content based on the IANA media type specified in the
packet header.
n Configure Body Content Types rules to control allowed content based on a hexadecimal file signature, also
known as a magic number.

You configure these settings in the HTTP Request and HTTP Response categories in HTTP-Client proxy actions.

Protect Your Web Server

If you have a public web server, you must also make sure that people can still get access to it after you configure it to
protect against attacks. The HTTP-Server.Standard proxy action allows most types of connections through the
Firebox. To block the most common attacks you can enable security services, such as IPS and Gateway AntiVirus.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 156

 Proxies and Proxy-Based Services

HTTP Proxy Action Rulesets

The HTTP-Client and HTTP-Server proxy actions have the same sets of rules, but the default settings are different.
These rulesets appear in the Categories list in the HTTP Proxy Action Configuration dialog box.

HTTP Request

General Settings
Use this ruleset to control the idle timeout and maximum URL length HTTP parameters. If you set a value
to zero (0) bytes, the Firebox ignores the size of HTTP request headers. You can also enforce Safe
Search settings for web browser search engines.

You can configure the Firebox to send a log message with summary information for each HTTP
connection request. Make sure to select the Enable logging for reports check box if you want to see
usage information in Dimension and WatchGuard Cloud reports.

Request Methods
The Request Method ruleset lets you control the types of HTTP request methods allowed through the
Firebox as part of an HTTP request. Some applications, such as Google Desktop and Microsoft
FrontPage, require additional request methods. webDAV is used for collaborative online authoring and
has many additional request methods. The HTTP-proxy supports webDAV request method extensions by
default, according to the specifications in RFC 2518.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 157

 Proxies and Proxy-Based Services

Many web pages get information from site visitors, such as location, email address, and name.
If you disable the POST command, the Firebox denies all POST operations to web servers on
the external network. This feature can prevent your users from sending information to a website
on the external network.

URL Paths
Use this ruleset to filter the content of the host and path of a URL. For best results, use URL path filters
together with Content Types and Body Content Types rules. You can use this feature to restrict access
to specific domains, parts of a website, or specific files by file name or extension.

Usually, if you filter URLs with the HTTP request URL Paths ruleset, you must configure a
complex pattern that uses regular expression syntax configured in the Advanced View of a
ruleset. It is easier and better to filter by Content Types or Body Content Types than it is to filter
URL paths.

Header Fields
This ruleset supplies content filtering for the full HTTP header. By default, the HTTP-proxy allows all
headers. This ruleset matches the full header, not only the name.

Authorization
This ruleset sets the criteria for content filtering of HTTP request header authorization fields. When a web
server starts a WWW-Authenticate challenge, it sends information about which authentication methods it
can use. The proxy puts limits on the type of authentication sent in a request.

HTTP Response

General Settings
Use this ruleset to configure basic HTTP response parameters, including idle time out, maximum line
length, and maximum total length of an HTTP response header. If you set a value control to zero (0) bytes,
the Firebox ignores the size of HTTP response headers.

Header Fields
This ruleset controls which HTTP response header fields the Firebox allows. Response headers can be
used to specify cookies, supply modification dates for caching, instruct the browser to reload the page
after a specified time interval, and several other tasks.

Most websites require custom headers (X headers) to operate correctly, so the proxy action
allows them all by default.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 158

 Proxies and Proxy-Based Services

Content Types
This ruleset controls the IANA media types (formerly known as MIME types) allowed in HTTP response
headers. This is a common way to restrict the types of files that users can download from websites.

Cookies
Use this ruleset to control cookies included in HTTP responses. HTTP cookies are used to track and store
information about users who visit a website. The default ruleset allows all cookies.

Body Content Types

Use this ruleset to control the content in an HTTP response. The HTTP-Client.Standard proxy action is
configured to deny Windows EXE/DLL files by default.

This ruleset identifies a file based on a hexadecimal file signature (also known as a magic number or
magic byte). For example, the file signature for a Zip archive is the hexadecimal value 50 4b 03 04. Lists of
hexadecimal file signatures are widely available on the Internet.

Use Web Cache Server

If you have an existing HTTP caching proxy server on your network, you can forward HTTP requests from the
Firebox to your proxy server. For more information, see the Fireware Help.

HTTP Proxy Exceptions

All traffic in a domain listed in this ruleset bypasses HTTP proxy rules. The HTTP proxy continues to enforce
RFC compliance, even for sites on the exception list. You should only add exceptions for trusted sites that
supply needed files that would be denied by other rules in the HTTP-proxy.

Data Loss Prevention

If you have enabled the Data Loss Prevention service, you can configure the DLP sensor the HTTP-proxy
uses to examine allowed traffic.

WebBlocker
Select a WebBlocker action to restrict web access by website category. In a WebBlocker action you specify
what to do when users try to open websites in each content category. You can select from these options:
n Allow — The website opens.
n Deny — The website does not open and a notification page appears in the browser.
n Warn — The website does not open and a warning page appears in the browser. Users can select to
continue to the website or go back to the previous page.
For more information, see WebBlocker and the HTTP and HTTPS Proxies.

Gateway AV
This ruleset specifies the actions to take if Gateway AntiVirus finds a virus, a scan error occurs, or when
content is encrypted. You can also set the scan size limit, which defines the maximum file size to scan. For
more information about these settings, see AntiVirus Scanning and Proxies

Network Security Essentials for Locally-Managed Fireboxes Study Guide 159

 Proxies and Proxy-Based Services

Deny Message
Use this feature to customize the HTML deny message that your trusted users see if the Firebox denies HTTP
content. The deny message appears in the browser when content is blocked by a Deny action configured in
the HTTP proxy.

Proxy and AV Alarms

This ruleset lets you define the type of notification to send when an alarm is triggered by an HTTP-proxy
ruleset.

APT Blocker
If you have an APT Blocker subscription, use this ruleset to enable APT Blocker to analyze HTTP traffic for
advanced malware.

HTTP-proxy Log Messages

When the HTTP proxy action denies traffic based on the configured rules, it sends a log message. You can see the
log message in Traffic Monitor. The log message includes information about what was denied, and which rule in the
proxy action denied the content.

If the HTTP-proxy denies content you want to allow, you can look at the deny log messages to see why the content
was denied. The log messages help you to identify which proxy action settings you must adjust if you want to allow
the content. For more information about specific messages, see the WatchGuard Log Catalog.

Enable Logging for Reports

For visibility into the web traffic on your network, you can also run reports in Dimension and WatchGuard Cloud. To
make sure the Firebox sends log messages required for reports, in the General Settings category for the HTTP
proxy action, select the Enable logging for reports check box. This setting is enabled by default in the .Standard
and Default proxy actions in all recent versions of Fireware.

The Firebox creates a log message for each HTTP transaction. You can use Dimension or WatchGuard Cloud to
search log messages and run detailed reports.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 160

 Proxies and Proxy-Based Services

WebBlocker and the HTTP and HTTPS Proxies

Use WebBlocker with the HTTP and HTTPS-proxy policies to prevent connections to websites
in specific content categories. The Default-WebBlocker action, created by the setup wizards,
denies connections to websites in risky categories by default.

WebBlocker uses a database of websites, organized into categories based on their content. You configure
WebBlocker to control which website categories your users can connect to. When a user on your network browses
the Internet, the Firebox automatically checks the WebBlocker Server for the site category. If you configured
WebBlocker to deny the site category, the user receives a message that access to the site was denied.

You can configure your Firebox to use WebBlocker Cloud or an on-premises WebBlocker Server for database
lookups. Both servers support the same website category database. WebBlocker uses WebBlocker Cloud by default.

To use WebBlocker you must:

n Have an active WebBlocker license for your Firebox
n Configure HTTP-proxy and HTTPS-proxy policies to use WebBlocker

WebBlocker works with the HTTPS-proxy even without content inspection enabled, because the domain is not
encrypted. WebBlocker can use the domain to look up the website category.

With content inspection disabled, WebBlocker filters based only on the root domain. For more
accurate WebBlocker categorization we recommend you enable HTTPS content inspection.

WebBlocker Actions
If your Firebox has a WebBlocker subscription, the Web Setup Wizard or Quick Setup Wizard automatically enables
WebBlocker and adds an HTTP-proxy policy with an HTTP proxy action that denies the WebBlocker categories you
select in the wizard. The Default-WebBlocker action, created by the setup wizard, denies risky categories by default.

You can configure multiple WebBlocker actions. In a WebBlocker action you specify what to do when users try to
open websites in each content category. You can select from these options:
n Allow — The website opens.
n Deny — The website does not open and a notification page appears in the browser.
n Warn — The website does not open and a warning page appears in the browser. Users can select to continue
to the website or go back to the previous page.

You can use the same WebBlocker action in more than one proxy policy.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 161

 Proxies and Proxy-Based Services

Content Categories
In a WebBlocker action, you select the content categories you want WebBlocker to deny or warn users about. The
WebBlocker Cloud database contains content categories such as Adult Material, Drugs, Gambling, and Security.
Each category has multiple subcategories to give you more granular control over which content to deny.

WebBlocker Exceptions
You can add an exception to the WebBlocker categories to always allow or deny connections to a specific website.
WebBlocker compares a URL to the exception list before it considers other configured WebBlocker categories.

You can add exceptions based on IP addresses, a pattern based on a URL, or a regular expression.

To create a WebBlocker pattern match exception, you can use of any part of a URL. You can set a port number, path
name, or string that must be denied for a special website.

Regular expressions are more accurate and more efficient, in terms of CPU usage on the
Firebox, than pattern matches. If you add many WebBlocker exceptions, you can improve
performance by configuring your WebBlocker exceptions as regular expressions rather than
pattern matches. You can create a regular expression that is equivalent to a pattern match.
For example, the regular expression ^[0-9a-zA-Z\-\_]\.hostname\.com. is equivalent to the
pattern match *.hostname.com/*. For more information about regular expressions, see
Fireware Help.

You can add WebBlocker exceptions in two locations:

n WebBlocker action — Add exceptions that you want to apply to policies that use a specific WebBlocker action.
n WebBlocker global settings — Add exceptions that you want to apply to all policies that use WebBlocker.

If you add different WebBlocker actions for policies that apply to different groups or users, and you want to add the
same WebBlocker exceptions for everyone, add the exceptions in the WebBlocker global settings. This eliminates
the need to add the same exceptions to multiple WebBlocker actions.

In the WebBlocker exceptions list, below the list of exception rules, you can configure the action to occur if the URL
does not match the exceptions you configure. Select one of these options:

Use the WebBlocker category list to determine accessibility

Select this option to use the configured WebBlocker categories to determine accessibility.

Deny website access

Select this option to use exception rules to deny all sites that are not on the exception list. With this option
selected, the exception list is a whitelist.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 162

 Proxies and Proxy-Based Services

A more effective way to implement a URL whitelist is to configure HTTP Request URL Paths in
the HTTP-Proxy action settings, as described in HTTP-proxy Policies and Proxy Actions

WebBlocker Override
When your users browse the Internet, WebBlocker denies access to websites in content categories that you
configured the WebBlocker action to deny. If you want to allow users to get temporary access to a website that the
WebBlocker action denies, you can enable and configure WebBlocker override.

You can configure a WebBlocker action to use one of two override methods:
n Passphrase – Specify a passphrase that users type to override the WebBlocker settings and get access to
denied content.
n User Group – Select an existing Firebox-DB or Active Directory user group. Users who are members of the
selected group can type their credentials to override the WebBlocker settings and get access to denied
content.

When override is enabled, you can select which denied categories users can override.

This feature operates with the HTTP-proxy and Explicit-proxy policies, and with the HTTPS-proxy policy when
content inspection is enabled.

If you want to always allow specific users to have access to a different set of websites, a better
alternative is to require users to authenticate to the Firebox, and then create separate policies
for those users or groups, with a different WebBlocker action. For example, you could create
policies for your IT group that are less restrictive than policies that apply to other users.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 163

 Proxies and Proxy-Based Services

HTTPS-proxy Policies

To apply most security services to HTTPS content, you must enable content inspection in the
HTTPS proxy action. Content inspection causes browser errors on web clients by default.
Before you enable content inspection in an HTTPS-proxy:
n Make sure that all network clients trust the Proxy Authority CA Certificate on the Firebox.
n Test the policy with a limited set of clients before you enable it for everyone.

If possible, add a CA certificate from a local PKI as the Proxy Authority certificate on the
Firebox. This avoids the need to import certificates to many client devices. This also makes it
easier to replace your Firebox with a newer model, because clients already trust the
CA certificate.

Even without content inspection, the HTTPS-proxy supports domain name rules, routing
actions, and WebBlocker, and provides more control and security than an HTTPS packet filter
policy.

Hyper Text Transfer Protocol Secure (HTTPS) is a secure web protocol that encrypts the connection between a web
browser and a web server. HTTPS uses the Transport Layer Security (TLS) protocol to encrypt the communication
protocol and establish a secure communication channel. The HTTPS-proxy policy enables you to manage and filter
secure HTTP (HTTPS) traffic on TCP port 443. You can use the HTTPS-proxy to protect your network clients, or an
HTTPS server on your network.

HTTPS Proxy Actions

The HTTPS proxy actions contain rules that control whether the proxy allows an HTTPS request, and whether it
decrypts and inspects the content. There are different proxy actions for HTTPS-Client and HTTPS-Server proxies.
Configure the appropriate proxy action based on whether the HTTPS-proxy policy handles incoming or outgoing
traffic.
n Use HTTPS-Client proxy actions for an outgoing HTTPS proxy policy.
n Use HTTPS-Server proxy actions for an incoming HTTPS proxy policy.

It is important to select the correct proxy action for incoming or outgoing HTTPS connections so
that the proxy uses the appropriate certificate.
n HTTPS-Client proxy actions use the outbound Proxy Authority CA certificate.
n HTTPS-Server proxy actions use the Proxy Server web server certificate.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 164

 Proxies and Proxy-Based Services

HTTPS Proxy Action Rulesets

In an HTTPS proxy action, you can configure:
n Domain name rules to allow, deny, drop, block, or inspect content based on the domain name.
n Domain name rules to route incoming HTTPS requests to a specific server based on the domain name
(HTTPS-Server proxy actions only).
n WebBlocker categories with the Allow or Warn action to inspect (HTTPS-Client proxy actions only).

You can select the Inspect action if you want the HTTPS-proxy to decrypt, inspect, and re-encrypt the content. In the
HTTPS proxy action, the Domain Names rules and WebBlocker settings determine how and when content inspection
occurs. To inspect content, you select the Inspect action and specify an HTTP proxy action to use to inspect the
decrypted content.

Content inspection is a very resource-intensive feature, which can have a noticeable impact
on Firebox performance, particularly for smaller Firebox models. To limit the performance
impact, use the Inspect action for specific sites or content categories only, not for all content.

These rulesets appear in the Categories list of an HTTPS proxy action:

Content Inspection

TLS Profile
Select the Transport Layer Security (TLS) profile to use for content inspection. In a TLS profile you can
configure these security settings:
n Minimum Protocol Version — Specify the minimum TLS protocol version to allow. To meet the
requirements of the Payment Card Industry Data Security Standard (PCI DSS), set the minimum
protocol version to TLS v1.2.
n Allow only TLS-compliant traffic — Specify whether to enforce compliance to the TLS protocol. The
HTTPS-proxy is the only proxy where protocol enforcement is optional. This setting is disabled by
default.

Enabling the Allow only TLS-compliant traffic setting can interfere with applications that
send non-HTTPS traffic on port 443. It is more secure to enable this setting, because
malware can also use port 443, and the proxy drops the non-compliant traffic.

n Use OCSP to validate certificates — Specify whether to use Online Certificate Status Protocol
(OCSP) to check for revocation of web server certificates. This setting applies only for HTTPS-Client
proxy actions. OCSP can add some latency. To improve performance, disable this setting.
A preconfigured TLS profile is selected by default. The TLS profile settings appear in the content
inspection summary.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 165

 Proxies and Proxy-Based Services

Domain Name Rules

Specify domain names, and an action to take for HTTPS requests for each domain. You can also specify
the action to take for domains that do not match a configured rule. You can use wildcards to specify a
domain name pattern match, such as *.example.com.

Do not specify a URL in a domain name rule. For example, a domain name rule with a pattern
like example.com/* will not work. The slash indicates a URL path, which can never be
matched, because all URLs are encrypted in HTTPS.

For each domain name rule, you can specify one of these actions:
n Allow — Allows the HTTPS request through and does not decrypt it.
n Inspect — Decrypts the connection and uses an HTTP proxy action to inspect the content.
n Deny — Denies the specific request but keeps the connection if possible. Sends a response to the
client.
n Drop — Denies the request, drops the connection, and sends a response to the client.
n Block — Denies the request, drops the connection, adds the site to the temporary blocked sites list,
and sends a response to the client.
All HTTPS-Client proxy actions include predefined domain name rules that allow HTTPS requests to
servers required by WatchGuard products and services.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 166

 Proxies and Proxy-Based Services

Content inspection settings in the HTTPS-Client.Standard proxy action

For an HTTPS-Server proxy action, when you select the Allow or Inspect action in a domain name rule,
you can configure a routing action and port to send the request to a different destination than what is
specified in the policy. This enables the Firebox to route incoming HTTPS requests originally sent to the
same public IP address to different internal IP addresses or ports based on the domain pattern.

Do not specify a URL in a domain name rule. The URL is encrypted and cannot be used for
matching in a domain name rule. To route inbound traffic based on a URL path, choose the
Inspect action, and then select an HTTP Content Action with URLs/paths defined. For more
information, see Content Actions and Routing Actions.

WebBlocker (HTTPS-Client proxy actions only)

WebBlocker action
Select a WebBlocker action. The WebBlocker action specifies the action to take when users try to open
websites in each content category, either Allow, Warn, or Deny.

WebBlocker categories for inspection

For content categories in the WebBlocker action that have the Allow or Warn action, select whether to
inspect the content. You also specify an HTTP-Client proxy action to use for inspection.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 167

 Proxies and Proxy-Based Services

WebBlocker can allow and deny most HTTPS content even without content inspection enabled
because the client-requested domain is often not encrypted. For connections that use TLS 1.3,
the domain is encrypted and WebBlocker content filtering is more limited. With TLS 1.3, the only
domain information that WebBlocker can use for filtering might be the CN in the website
certificate if the SNI is encrypted.

WebBlocker settings in an HTTPS-Client proxy action

General Settings
Configure settings for alarms and logging. If you use reports in Dimension or WatchGuard Cloud, make sure
the Enable logging for reports check box is selected. This option is enabled by default.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 168

 Proxies and Proxy-Based Services

Content Inspection Summary

The Content Inspection Summary section in the HTTPS proxy action shows:
n Inspection status for Domain Name Rules and WebBlocker (On or Off).
n A summary of the TLS Profile settings.

Content Inspection Exceptions

Content inspection can interfere with some well-known services. To avoid problems, WatchGuard maintains a list of
domain names associated with these services. The HTTPS-proxy does not inspect content for domains in the
Content Inspection Exceptions list by default. Click Manage Exceptions to see the list and disable or enable rules.

You cannot add rules to the Content Inspection Exceptions list. If you want to add a custom exception, you must add
a rule to the Domain Names rules list.

Content Inspection and the HTTP Proxy Action

When you select the Inspect action, you specify the HTTP proxy action to use for inspection of the decrypted content.
The HTTP proxy action contains the rules that specify how to inspect the content and what content to allow or deny.

The HTTP proxy action you use for content inspection can be the same one you use for the HTTP-proxy.

The Default-HTTP-Client proxy action created by the setup wizards enables licensed
security services and is a good choice unless you have configured another custom proxy
action.

You can enable these services in an HTTP proxy action:

n APT Blocker
n Data Loss Prevention
n Gateway AntiVirus (also required for IntelligentAV)

These other services require HTTPS content inspection to be effective:

n Application Control
n Intrusion Prevention Service

Network Security Essentials for Locally-Managed Fireboxes Study Guide 169

 Proxies and Proxy-Based Services

HTTPS Content Inspection Order of Operations

With HTTPS content inspection enabled, many settings affect whether the HTTPS-Proxy allows or denies a
connection. The HTTPS-proxy evaluates the proxy action settings in this order:

1. Domain names: Domain name rules

2. Content inspection exceptions
3. Domain names: Action to take if no rule action is matched, if set to Inspect.
4. WebBlocker exceptions
5. WebBlocker categories
6. WebBlocker settings in the HTTP proxy action used for content inspection

When you configure the HTTPS proxy action, consider all of these settings.

An HTTPS proxy action with the order of operations for content inspection

Network Security Essentials for Locally-Managed Fireboxes Study Guide 170

 Proxies and Proxy-Based Services

Content Inspection and Certificate Errors

With content inspection enabled, the HTTPS proxy action:

1. Decrypts the HTTPS traffic.

2. Applies settings in the selected HTTP proxy action to inspect the traffic.
3. Encrypts allowed traffic with a new certificate.

When the Firebox re-encrypts the inspected traffic, it uses the Proxy Authority certificate on the Firebox to sign the
website certificates. Because the default Proxy Authority certificate is a self-signed CA certificate, it is not trusted by
clients on your network. This causes certificate warnings to appear in the web browser of all clients.

Firebox Proxy Authority Certificate

To avoid certificate errors for your users, the clients must trust the Proxy Authority certificate on the Firebox.

There are two ways to achieve this:

Import a trusted CA certificate to the Firebox (strongly recommended)

If your organization already has a PKI (Public Key Infrastructure) set up with a trusted CA, you can import a CA
certificate that is signed by your organization's internal CA to your Firebox. If you do not use Active Directory,
you can use free PKI software to set up a local certificate authority.

To create a proxy authority certificate for use with the HTTPS-proxy content inspection feature, you must
create a CA certificate that can re-sign other certificates. For example, you could generate a subordinate CA
certificate for the Firebox to use as the Proxy Authority certificate. To do this, you can create a Certificate
Signing Request (CSR) with Firebox System Manager, Fireware Web UI, or from OpenSSL, and have your
internal CA server sign that certificate. Then, import the CA certificate and the subordinate CA certificate to the
Firebox. For more details, see Create a Certificate CSR in Help Center.

WatchGuard recommends that you use a certificate signed by your own internal CA.

Import the default self-signed Proxy Authority certificate to clients

Another option is to export the default self-signed Proxy Authority certificate from the Firebox and import it to
all clients as a trusted certificate. This is not the preferred method, because the default self-signed certificate
will be lost if the Firebox fails, is reset to factory-default settings, or is replaced with a newer model.

Public CA providers will not provide a CA certificate with permission to sign other certificates.
We recommend that you use a certificate signed by your own internal CA.

To view, import, and export certificates from the Firebox, in Firebox System Manager, select View > Certificates.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 171

 Proxies and Proxy-Based Services

Firebox Certificate Portal

The Firebox also hosts a certificate portal, where users can download the Proxy Authority certificate.

To download the Proxy Authority certificate from the Certificate Portal on the Firebox, go to:

http://<Firebox IP address>:4126/certportal

The certificate portal is a good option for guest users, or non-domain computers that do not trust your local Active
Directory or PKI server.

HTTPS Content Inspection and SSL VPN

If your Firebox allows other traffic that uses the HTTPS port, such as SSL VPN traffic, we
recommend that you test and evaluate the content inspection feature carefully.

If your Firebox allows outbound SSL VPN traffic, make sure that HTTPS content inspection does not interfere with
those connections. To do this, you can add an HTTPS packet filter policy to allow port 443 connections to the
destination IP addresses or domains the VPN clients connect to. Make sure the HTTPS packet filter policy is higher in
the policy list than the HTTPS-proxy policy that performs content inspection.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 172

 Proxies and Proxy-Based Services

Content Actions and Routing Actions

An HTTP content action can apply to incoming HTTP or decrypted HTTPS traffic. In an
HTTP content action, you specify content rules. Each content rule defines where to route the
request (the routing action) and specifies the HTTP proxy action to use for content inspection.

The main use cases for an HTTP content action are:

n Host Header Redirect
n SSL/TLS Offloading

You can also use routing actions in domain name rules to redirect HTTPS requests based on
the domain name without content inspection.

If you use the same public IP address for inbound connections to multiple public web servers protected by the
Firebox, you can configure routing actions or HTTP content actions to route incoming requests to the correct web
server.

Routing Actions
A routing action specifies the IP address and port of a server. To redirect HTTPS requests based on the domain
name without content inspection, specify a routing action in a domain name rule in the HTTPS-Server proxy action.

Do not specify a URL in a domain name rule. The URL is encrypted and cannot be used for
matching in a domain name rule. To route inbound traffic based on a URL path, select the
Inspect action, and then select an HTTP content action with URLs/paths defined.

You can use the policy default destination and port, or you can configure custom settings for each rule.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 173

 Proxies and Proxy-Based Services

You can also specify a routing action in an HTTP content action:

n For the Routing Action, select Use Policy Default to route to the destination specified in the To field of the
policy. Or, select Use and specify a different destination IP address.
n For the Port, select Use Policy Default to use the port specified in the policy. Or select Use and specify a
different destination port.

HTTP Content Actions

HTTP content actions have two main functions:

Host Header Redirect

Routes inbound HTTP requests (or decrypted HTTPS requests) to different servers based on the URL path or
domain name in the request. You can also specify a different HTTP proxy action for each URL path or domain.

TLS/SSL Offloading
TLS/SSL Offload reduces the CPU load on the Firebox and removes the burden of TLS/SSL encryption and
decryption from your internal web server. Traffic is encrypted (HTTPS) between external clients and the
Firebox. Traffic is clear-text (HTTP) between the Firebox and the internal server.

To route inbound HTTP requests to multiple servers based on the URL path or domain name in the HTTP request,
use an HTTP content action. In an HTTP content action, you configure rules that specify:
n A pattern to match a domain name, URL path, or both
n A routing action (IP address and port)
n An HTTP proxy action

You can select an HTTP content action instead of a proxy action in:
n Inbound HTTP-proxy policies
n HTTPS-Server proxy actions in domain name rules with content inspection

Network Security Essentials for Locally-Managed Fireboxes Study Guide 174

 Proxies and Proxy-Based Services

Content Rules
In an HTTP content action, you configure:
n Content rules for patterns to match against HTTP requests
n The action to take if a no content rule is matched

Example HTTP content action with one content rule

Each HTTP content rule specifies a pattern to match in the HTTP host header and HTTP request. The pattern in a
content rule can match a domain, a path, or both.

Here are some examples of each pattern type:

Domain only *.example.com

example.com

mail.example.com

Path */blog/*

*/audio/*

Domain and path example.com/*

blog.example.com/resource/*

*.example.com/docs/*

Network Security Essentials for Locally-Managed Fireboxes Study Guide 175

 Proxies and Proxy-Based Services

Rule Actions
Rule actions control where to route requests and which proxy action to use when the domain and path of an HTTP
request matches a specified pattern.

Rule action settings include:

Proxy Action
Select the HTTP proxy action to use for connections to the internal server.

Routing Action
Specify the IP address of an internal server, or route to the default destination in the proxy policy.

Routes specified in the content action override the destinations configured in the policy. When you configure a
proxy policy to use a content action, the destinations configured in the policy To field are not used unless you
specify Use Policy Default in the content action.

HTTP Port and HTTPS Port

Specify the HTTP and HTTPS ports to use for connections to the internal server. If you choose Use Policy
Default, the action uses the port specified in the policy properties.

The HTTPS port is used only when the content action is used in an HTTPS-proxy policy with content
inspection enabled.

TLS/SSL Offload
When you enable the TLS/SSL Offload option, HTTPS is used for traffic between external clients and the
Firebox. HTTP is used for traffic between the Firebox and the internal server.

You also configure actions to take when no rule is matched.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 176

 Authentication

Authentication
When you require users to authenticate through the Firebox, you can create policies for traffic from specific users and
groups. You can also see user names in log messages and reports, which gives you information about user traffic on
your network.

Authentication is important when you use dynamic IP addressing (DHCP) for computers on trusted or optional
networks. It is also important if you must identify your users before you let them connect to resources on the external
network or other internal networks.

In this section, you learn about:

n Firebox authentication
n AuthPoint authentication server
n Supported third-party authentication servers
n Benefits and drawbacks of each supported authentication type
n User and group configuration in policies
n Firebox authentication portal

For a list of additional resources on these topics, see Mobile VPN Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 177

 Authentication

Authentication Servers
You can configure these types of authentication servers on your Firebox:
n Firebox Authentication (also known as Firebox-DB)
n AuthPoint
n Third-party authentication servers (Active Directory, LDAP, RADIUS, SAML, and SecurID)

To configure authentication servers, select Setup > Authentication > Authentication Servers. Select a tab to
configure that type of server.

You can configure more than one authentication server type on the Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 178

 Authentication

Firebox Authentication
When you configure the Firebox as an authentication server, the Firebox stores user accounts that you create to give
users access to your network.

Firebox authentication is often used by organizations that do not have a third-party authentication server and do not
need to manage user accounts centrally for multiple applications. Firebox authentication works with policies, all VPN
types, management access, and all other Firebox features that authenticate users.

To prepare your Firebox as an authentication server:

n Divide your company into groups based on the tasks people do and information they need
n Create users for the groups
n Assign groups and users to policies

To make sure user credentials stored on the Firebox are secure, the Firebox encrypts user passphrases with an NT
hash in the device configuration file. If the configuration file is exported to a clear text file, the Firebox encrypts the
passphrase with an AES key wrap. This protects user passphrases, for example, when a configuration file is exported
to a clear text file for communication between the Firebox and a Fireware device configuration management tool.

When you configure Firebox authentication, you can:

n Specify whether user names are case-sensitive.
n Specify the minimum number of characters required for passwords. The minimum number must be between 8
and 32 characters. The maximum passphrase length is 32 characters and cannot be changed.
n Enable Account Lockout to prevent brute force attempts to guess user account passwords.

For networks with many users, we recommend a third-party authentication server rather than
Firebox authentication. With Firebox authentication, an administrator must log in to the
Firebox to specify and reset user passwords. Users cannot specify or change their own
passwords.

How Firebox User Authentication Works

A dedicated HTTPS server operates on the Firebox to accept authentication requests. This server is known as the
authentication portal.

Firebox user authentication happens in this order:

1. The user connects to the authentication portal at https://[Firebox interface IP address]:4100.

In most cases, the Firebox interface IP address is a trusted or optional interface.
You can also specify the IP address of an external Firebox interface. You might do this to require
authentication for inbound connections such as RDP and SSH. However, be aware that this exposes the user
login page to the Internet. We recommend that you configure a VPN instead.
2. The user types a user name and password.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 179

 Authentication

3. The authentication page sends the user name and password to the selected authentication server using
Password Authentication Protocol (PAP). PAP is unencrypted. Passwords are hashed.
4. If the authentication server responds that the user is authenticated, the user can connect to approved network
resources.
5. The user can close the browser window after authentication is complete.

The user stays authenticated for the amount of time specified in the global or user timeout settings. The user can click
Logout on the authentication web page to close the session before the timeout period elapses. If the web page was
previously closed, the user must open it again and click Logout to disconnect.

You can also require your users to authenticate to the authentication portal before they can get access to the Internet.
You can choose to automatically send users to the portal, which applies only to HTTP and HTTPS connections. Or,
you can require users to manually go to the portal.

This diagram shows the basic authentication sequence for Firebox Authentication.

To prevent a user from authenticating, you must disable the user account on the authentication
server.

Use Authentication through a Gateway Firebox to Another

Device
The first time you add a user or group to the From field of any policy, the Firebox automatically adds the WatchGuard
Authentication policy. The policy has this configuration:
n From — Any-Trusted, Any-Optional
n To — Firebox

Network Security Essentials for Locally-Managed Fireboxes Study Guide 180

 Authentication

To send an authentication request through a gateway Firebox to a different Firebox, the WatchGuard Authentication
policy must allow this traffic. On the gateway Firebox, edit the WatchGuard Authentication policy so it allows traffic to
the IP address of the destination Firebox.

About Authentication Timeouts

You can specify timeout values for users and servers.

User Timeouts
To control how long Firebox-DB users remain authenticated, you can specify timeout values that apply globally or
only to specified users. The Firebox uses the global setting only if no timeout value is specified in the Firebox-DB user
settings.

To configure global timeout settings, select Setup > Authentication > Authentication Settings. By default, the
Session Timeout is 0 and the Idle Timeout is 2 hours.

To configure timeout settings for a user account, select Setup > Authentication > Authentication Servers >
Firebox-DB > Users > Add. By default, the Session Timeout is 8 hours and the Idle Timeout is 30 minutes.

For users authenticated by third-party servers, the timeout values configured on those servers override the global
authentication timeouts.

Server Timeouts
On the Firebox, you can configure these timers for authentication server communication:
n Timeout — How long the Firebox waits for a response from the server before it closes the connection and tries
to connect again.
n Retries — How many times the Firebox attempts to contact the server before it marks the server as inactive.
This setting applies only to RADIUS servers.
n Dead Time — The time after which an inactive server is marked as active again.

Login Limits
You can limit your users to a specific number of authenticated sessions. If you select this option, you can specify the
number of times users can type the same credentials to log in to one authentication server from different IP
addresses.

You can specify what happens when an authenticated user tries to authenticate again. Select one of these options:
n Allow subsequent login attempts and log off the first session
n Reject subsequent login attempts

You can configure these settings at Setup > Authentication > Users and Groups when you Add or Edit a user or
group.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 181

 Authentication

Multi-User Systems
The Firebox associates a user name to an IP address. This means that the Firebox authenticates one user for each
computer.

Your network might include multi-user systems such as a Terminal Server or Citrix server. If your users log in to a
Terminal Server or Citrix server, we recommend that you install WatchGuard Terminal Services Agent on those
servers. The Terminal Services Agent is also known as the TO (Traffic Owner) Agent.

The TO Agent monitors traffic generated by individual users and reports the user session ID to the Firebox for each
traffic flow generated by a Terminal Server or Citrix server client. The Firebox can then correctly identify each user
and apply the correct security policies to the traffic for each user, based on user or group names.

Block Failed Logins

To help prevent brute force attacks against the login pages of a locally-managed Firebox, you can enable the Block IP
Addresses with Consecutive Failed Logins feature. This feature blocks an IP address that makes consecutive failed
login attempts to these login pages on the locally-managed Firebox:
n Fireware Web UI
n Mobile VPN with SSL client download page
n Access Portal
n Authentication Portal

In Fireware v12.11 and higher, the Mobile VPN with SSL client download page is removed from
the Firebox.

This feature is supported in Fireware v12.10.4 and higher. In Fireware v12.10.4, this feature is
disabled by default. In Fireware v12.11 and higher, this feature is enabled by default.

When you enable Block IP Addresses with Consecutive Failed Logins, the Firebox temporarily blocks an IP address
after a specified number of consecutive failed authentication attempts within a specified time period. The Firebox
automatically adds the blocked IP address to the Blocked Sites list with a Reason of block failed logins.

The number of consecutive failed authentication attempts you enter is used for the total number of failed attempts to
all login pages on the Firebox.

This feature does not block failed login attempts for:

n Fireware Web UI login page when the account user name is not admin or status
n AuthPoint authentication

Network Security Essentials for Locally-Managed Fireboxes Study Guide 182

 Authentication

AuthPoint Authentication Server

Fireboxes include an AuthPoint authentication server. AuthPoint is the WatchGuard multi-factor authentication (MFA)
service.

You can use the AuthPoint authentication server on your Firebox to configure multi-factor authentication for:
n Mobile VPN with SSL
n Mobile VPN with IKEv2
n Firebox Web UI
n Firebox Authentication Portal

The AuthPoint authentication server on the Firebox is disabled by default. To enable the AuthPoint authentication
server on a Firebox, you must configure a Firebox resource in AuthPoint. In AuthPoint, resources are the applications
and services that your users connect to, such as a VPN or your Firebox.

After you configure the Firebox resource in AuthPoint, the AuthPoint authentication server is enabled on the Firebox.

AuthPoint Configuration
To configure AuthPoint and enable the AuthPoint authentication server on a Firebox, you must:
n Register and connect the Firebox to WatchGuard Cloud as a locally-managed Firebox.
n Add a Firebox resource in AuthPoint.
n Add users and groups in AuthPoint.
n Add authentication policies in AuthPoint to specify which resources AuthPoint users can authenticate to and
which authentication methods they can use.

Firebox Configuration
To require that users authenticate with multi-factor authentication, you must configure the Firebox to use the
AuthPoint authentication server.
n Mobile VPN with SSL — In Fireware, configure AuthPoint as the primary authentication server for your Mobile
VPN with SSL configuration.
n Mobile VPN with IKEv2— In Fireware, configure AuthPoint as the primary authentication server for your
Mobile VPN with IKEv2 configuration.
n Firebox Authentication Portal — In Fireware, specify AuthPoint as the authentication server for users and
groups.
n Fireware Web UI — In Fireware, go to System > Users and Roles and add Device Management users with
AuthPoint as the authentication server.

When you configure the Firebox to use the AuthPoint authentication server:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 183

 Authentication

1. The Firebox forwards user authentication requests directly to AuthPoint.

2. AuthPoint coordinates multi-factor authentication (MFA):
n Local users —AuthPoint validates the first factor (password) and the second factor (push or one-time

password).
n LDAP users — AuthPoint tells the Firebox to contact Active Directory to validate the first factor (password).
AuthPoint validates the second factor (push or one-time password).
3. The Firebox prompts the user to select an authentication option:
n If the user selects the push option, AuthPoint sends a push request to the user’s phone.

n If the user selects the one-time password option, the Firebox prompts the user to specify a one-time
password (OTP).

Network Security Essentials for Locally-Managed Fireboxes Study Guide 184

 Authentication

Third-Party Authentication Servers

You can specify third-party authentication servers in your Firebox configuration. Fireware supports these third-party
authentication servers:
n Active Directory
n LDAP
n RADIUS
n SAML
n SecurID — Enable the SecurID option in the RADIUS server configuration. The Authentication Servers page
does not have a separate SecurID configuration.

You can add multiple Active Directory and RADIUS servers to the Firebox configuration. For example, you could add
three primary Active Directory servers and specify a backup Active Directory server for each primary server.

When you configure a third-party authentication server on the Firebox, you must specify these settings:
n Active Directory — Server IP address and search base. The text you specify in the first Domain Name text box
is used only for Firebox log messages.
n LDAP — Server IP address, search base, and group attribute. In most cases, you must also specify the DN of a
searching user.
n SAML — FQDN that resolves to the Firebox external interface and an IdP metadata URL.
n RADIUS and SecurID — Server IP address and shared secret.

Backup Authentication Server

For redundancy, you can configure a backup authentication server for each primary server. If the primary
authentication server does not respond, the Firebox attempts to contact the backup server.

For example, you configure a primary and backup authentication server. The Firebox attempts to contact the primary
authentication server for the amount of time specified by the Timeout value. By default, this is 10 seconds.

If the primary authentication server does not respond:

1. The Firebox marks the primary authentication server as inactive.

2. The Firebox attempts to contact the backup authentication server for the amount of time specified by the
Timeout value.
3. If the backup authentication server does not respond:
a. The Firebox marks the backup authentication server as inactive.
b. The Firebox generates a log message.
c. The Firebox waits for the amount of time specified by the Default Dead Time value before it tries the
primary authentication server again.
4. The Firebox attempts to contact the primary authentication server.
5. The Firebox repeats this process indefinitely.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 185

 Authentication

If a primary or secondary RADIUS authentication server does not respond after the Timeout
interval elapses, the Firebox attempts to contact the server again. If the server does not
respond after the number of attempts specified in the Retries value, the Firebox marks the
server as inactive.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 186

 Authentication

Users and Groups in Policies

You can define policies that only allow connections for authenticated users, or you can limit
connections to specific users.

An authenticated user can send traffic through the Firebox only if the traffic is allowed by a Firebox policy. After you
add a user or group to a policy, the Firebox automatically adds the WatchGuard Authentication policy. This policy
controls access to the Authentication Portal web page.

You can configure authentication differently for each policy. For example, you can force some users to authenticate
before they connect to an FTP server, but allow them to browse the Internet before they authenticate.

The user or group name must use the same capitalization on the Firebox and your third-party authentication server.

Add Groups and Users

When you add a group or user on the Firebox, you specify which servers should authenticate users. The default
option is Any, which allows users to authenticate to any server specified on the Firebox. The user accounts must also
exist on those authentication servers.

When you add a group or user, you have these Authentication Server options:
n Any — Works for any type of authentication server configuration on the Firebox. As a best practice, to avoid
unintended access to certain authentication servers, only select this option if it is acceptable for the group or
user to authenticate to any server.
n [Server name] — Restricts authentication to only this server. You can also use this option to later add policies
for groups or users who authenticate to a specific server.

To allow authentication to more than one, but not all, servers, add the group or user multiple times. For example, you
can specify these authentication servers on your Firebox:
n example.net (RADIUS)
n example.test (RADIUS)
n example.com (Active Directory)
n example.org (Active Directory)

To allow the Accounting group to authenticate to both Active Directory servers, but not the RADIUS servers, add the
Accounting group twice — once for example.com, and again for example.org. To allow the Marketing group to
authenticate to the RADIUS servers, but not the Active Directory servers, add the Marketing group twice — once for
example.net, and again for example.test. To allow the IT group to authenticate to all servers, select Any.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 187

 Authentication

Policies
The first time you add a user or group to the From field of any policy, the Firebox automatically adds a policy named
WatchGuard Authentication (WG-Auth). The policy has this configuration:
n From — Any-Trusted, Any-Optional
n To — Firebox

The WatchGuard Authentication policy gives your users the ability to authenticate to the Firebox.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 188

 Authentication

If you see the message Decrypted traffic does not match any policy, make sure
that the user is in a group with the same name as your Mobile VPN group. Or,

Login Limits
For both individual users and user groups, you can enable login limits. When you enable unlimited concurrent logins
for a user or group, you allow more than one user or member of a group to authenticate with the same user
credentials at the same time, to each authentication server.

The other option you can select for user and group login limits is to limit your users or members of a group to a single
authenticated session. If you select this option, your users cannot log in to one authentication server from different IP
addresses with the same credentials. When a user is already authenticated and tries to authenticate again, you can
select whether to terminate the first user session when the additional session is authenticated, or reject the additional
session.

You can also configure global login limits in the Fireware Authentication settings. By default, the Firebox allows
unlimited concurrent logins from the same account.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 189

 Mobile VPN

Mobile VPN
A Mobile VPN (Virtual Private Network) enables trusted mobile or remote users to connect and log on from an
external network. Fireware supports four types of mobile VPNs: Mobile VPN with IKEv2, Mobile VPN with SSL,
Mobile VPN with L2TP, and Mobile VPN with IPSec.

In this section you learn about:

n How to select a mobile VPN type for your network
n How to configure the Firebox and clients for mobile VPN

For a list of additional resources on these topics, go to Mobile VPN Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 190

 Mobile VPN

Mobile VPN Introduction

A VPN tunnel is a secure connection between a mobile user and resources on your network. A
VPN client on the remote user’s computer sends traffic for your network through the VPN
tunnel. When your Firebox receives traffic through a VPN tunnel, it forwards that traffic to the
correct destination.

A mobile VPN provides these benefits:

n Data privacy and confidentiality — Data is encrypted so only the sender and the recipient of the traffic can
read it.
n Data integrity — Data is not changed after it is sent.
n Data authentication — Data comes from one of the two VPN endpoints and not from an attacker on the
Internet.
n Direct communication between private addresses — Computers at two sites communicate as if they were not
behind devices configured with Network Address Translation (NAT). The data tunnels through NAT for a
transparent connection between the devices.

To use a mobile VPN, you must first configure mobile VPN on your Firebox. You must also configure VPN settings for
each user or group of users. Mobile VPN users authenticate either to the Firebox authentication server or to an
external authentication server.

Topology
This diagram shows a common mobile VPN topology.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 191

 Mobile VPN

Mobile VPN Types

Fireware supports four types of mobile VPNs.
n Mobile VPN with IKEv2
n Mobile VPN with SSL
n Mobile VPN with L2TP
n Mobile VPN with IPSec

Each mobile VPN type uses different ports, protocols, and encryption algorithms to establish a connection. The
required ports and protocols must be open between the mobile device and your Firebox for the mobile VPN to
function.

You can configure all mobile VPN types on your Firebox and use them simultaneously. You can also configure client
computers to use one or more mobile VPN types.

Mobile VPN with IPSec uses the IKEv1 Aggressive Mode protocol. Because of a known
vulnerability with the IKEv1 Aggressive Mode protocol, we recommend that you consider any
mobile VPN option other than Mobile VPN with IPSec. In this guide, we do not cover Mobile
VPN with IPSec. For more information about Mobile VPN with IPSec, go to Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 192

 Mobile VPN

Select a Mobile VPN Type

Some mobile VPN types are more secure or faster than others, or use fewer network resources. Before you make a
decision, review the specifications described in this section for each mobile VPN type:
n Encryption support
n Authentication server compatibility
n VPN tunnel capacity
n Client OS support for each VPN type

Encryption Support
Encryption algorithms protect the data so it cannot be read by a third party while in transit through the VPN. Each
VPN type supports different encryption algorithms. Larger encryption key sizes are more secure. AES is the most
secure encryption algorithm, and is supported by all VPN types.

Authentication Server Compatibility

Authentication server support differs by VPN type:

Firebox
(Firebox-DB)
Mobile Active Local
VPN 1 Directory LDAP RADIUS SecurID SAML Authentication
Authpoint
Mobile Yes Yes2 No Yes No No Yes
VPN with
IKEv2

Mobile Yes Yes2 No Yes No No Yes

VPN with
L2TP

Mobile Yes Yes Yes Yes Yes Yes Yes

VPN with
SSL

1. AuthPoint is the cloud-based multi-factor authentication (MFA) solution from WatchGuard.

2. Active Directory authentication for IKEv2 and L2TP is supported only through a RADIUS server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 193

 Mobile VPN

VPN Tunnel Capacity

The tunnel capacity of your Firebox determines the number of mobile VPN users that can connect at the same time.
The maximum number of mobile VPN tunnels for each mobile VPN type depends on the device model. You can see
the current mobile VPN tunnel capacity of your device in the device feature key.

The IPSec VPN Users value in the feature key is a combined limit for Mobile VPN with IKEv2 and Mobile VPN with
IPSec. For example, if a feature key allows 250 IPSec VPN user connections and 200 Mobile VPN with IPSec users
are connected, 50 Mobile VPN with IKEv2 users can connect.

The SSL VPN Users value in the feature key is a combined limit for Mobile VPN with SSL and BOVPN over TLS.

To see the feature key for your device in Policy Manager, select Setup > Feature Keys.

Client OS Support and VPN Client Installation

The operating system on user computers and devices determines whether your users should install a VPN client or
use the native VPN client.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 194

 Mobile VPN

VPN
Type Windows macOS Android and iOS

L2TP Users manually configure Users manually configure the Users manually configure the native
the native VPN client or native VPN client or any VPN client.
any L2TPv2 client that L2TPv2 client that complies
complies with RFC 2661. with RFC 2661.

SSL Users authenticate to the Users authenticate to the Users must install an OpenVPN
Firebox to download and Firebox to download and install client. Users can authenticate to the
install the client the client configuration file. Firebox to download the Mobile VPN
configuration file. with SSL client configuration file to
The client computer must
import to the OpenVPN client.
The client computer must support TLS 1.1 or higher.
support TLS 1.1 or
higher.

IKEv2 Firebox administrators Firebox administrators can Android

can download a .bat download a .mobileconfig
User must install the third-party
script from the Firebox to configuration profile from the
strongSwan app. Firebox
automatically configure Firebox to automatically
administrators can download a
the native IKEv2 VPN configure the native IKEv2
.sswan file from the Firebox to
client.* VPN client.
automatically configure the
IPSec Mobile VPN strongSwan app.
Client
iOS
WatchGuard IPSec
Firebox administrators can download
Mobile VPN for Windows
a .mobileconfig configuration profile
client users can import a
from the Firebox to automatically
profile configuration file.
configure the native IKEv2 VPN
client.

*For computers with Windows 7, you must manually configure the native IKEv2 VPN client. The .bat script is not
supported.

For detailed instructions on how to configure native VPN clients and strongSwan, go to Fireware Help.

Other Considerations
Mobile VPN with IKEv2 offers the highest level of security, best performance, and easiest deployment. This VPN type
has certificate-based client authentication instead of a pre-shared key. Mobile VPN with IKEv2 supports MOBIKE, a
mobility protocol that makes sure your remote workers remain connected to the VPN even if they move to a different
network.

Mobile VPN with IKEv2 and Mobile VPN with SSL support full tunnel and split tunnel configurations.

Mobile VPN with IKEv2 and L2TP work only when the required ports and protocols are allowed on the remote
networks. This means these mobile VPN types might not work on all remote networks.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 195

 Mobile VPN

Mobile VPN with IKEv2

We recommend Mobile VPN with IKEv2 in most cases because it is more secure, faster, and easier to deploy than
other mobile VPN types.

Mobile VPN with IKEv2 supports full tunnel and split tunnel configurations.

Security
Mobile VPN with IKEv2 uses certificates for endpoint verification. For authentication, Mobile VPN with IKEv2 uses
EAP and MS-CHAPv2.

This type of mobile VPN supports local authentication on the Firebox (Firebox-DB), RADIUS, and AuthPoint
authentication servers.

Performance
Mobile VPN with IKEv2 performs better than Mobile VPN with L2TP and Mobile VPN with SSL.

Compatibility and Client Installation

Users can connect with native Windows, macOS, or iOS clients. Android users can download and install strongSwan,
a free, open-source VPN client. WatchGuard IPSec Mobile VPN for Windows client users can import a configuration
file.

Connection Settings
Mobile VPN with IKEv2 uses these ports, protocols, and encryption algorithms to establish a connection:

Required ports ESP and UDP 500; UDP 500 and 4500 for NAT-T

Transport and authentication protocols IKEv2 (Internet Key Exchange Tunneling Protocol v2)

IPSec (Internet Protocol Security)

IKE (Internet Key Exchange)

ESP (Encapsulating Security Payload)

Authentication: MD5, SHA-1, SHA2-256, SHA2-384, SHA2-512

Encryption protocols DES, 3DES, AES, and AES-GCM

Encryption strength DES and 3DES: 56-bit and 168-bit

AES: 128-bit, 192-bit, or 256-bit

Network Security Essentials for Locally-Managed Fireboxes Study Guide 196

 Mobile VPN

AES-GCM: 128-bit, 192-bit, or 256-bit

Network Security Essentials for Locally-Managed Fireboxes Study Guide 197

 Mobile VPN

Mobile VPN with SSL

We recommend Mobile VPN with SSL when IKEv2 IPSec traffic is not allowed on the remote network.

Mobile VPN with SSL supports full tunnel and split tunnel configurations.

Fireware v12.11 expands support for SAML authentication and includes Firebox authentication. The Mobile VPN with
SSL v12.11 client for Windows, and the Mobile VPN with SSL v12.11.2 client for macOS, support SAML
authentication.

By default, Mobile VPN with SSL uses TCP 443 for tunnel traffic. This makes Mobile VPN with SSL portable to almost
any environment that allows outbound HTTPS and does not decrypt the traffic. In the Mobile VPN with SSL
configuration, you configure these channels:

Data channel
The data channel is used to send data after a VPN connection is established.

If you change the data channel to a port other than 443, users must manually type this port in the Mobile VPN
with SSL connection dialog box. For example, if you change the data channel port to 444, and the Firebox IP
address is 203.0.113.2, users must type 203.0.113.2:444.

Configuration channel

In Fireware v12.11 and higher, the Mobile VPN with SSL client download page is removed from
the Firebox.

The configuration channel specifies where Mobile VPN with SSL users can download SSL client software. For
example, if the Firebox IP address is 203.0.113.2, and the port is 443, users can connect to
https://203.0.113.2/sslvpn.html to download client software.

If the data channel protocol is TCP, the configuration channel automatically uses the same port and protocol.

If you set the data channel protocol to UDP, you can specify a different port than the data channel. For
example, if you specify port 444 for the configuration channel, users can connect to
https://203.0.113.2:444/sslvpn.html to download client software.

Although Mobile VPN with SSL usually works on most networks, it can fail because of firewall restrictions:
n Content inspection — If a network device decrypts HTTPS traffic to inspect it for malicious content, Mobile
VPN with SSL fails.
n Protocol enforcement — If you enable the Allow only TLS-compliant traffic option on your Firebox, Mobile
VPN with SSL might fail.
n Application control — If an application control service blocks the open-source OpenVPN software, Mobile
VPN with SSL fails.

Other software vendors might have different names for these settings and services. However, if these settings and
services work as described here, Mobile VPN with SSL fails.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 198

 Mobile VPN

Security
Mobile VPN with SSL is a secure mobile VPN option, but it is less secure than IPSec-based VPNs because:
n It does not support multi-layer encryption.
n An attacker needs to know only the Firebox IP address and client login credentials to connect.

Mobile VPN with SSL uses both TLS and certificates for encryption.

It works with any combination of authentication servers available through the Firebox.

Performance
Mobile VPN with SSL is slower than other mobile VPN types. It is not the best option for latency-sensitive traffic such
as VoIP or high-bandwidth file transfers. However, you can improve Mobile VPN with SSL performance if you select
UDP for the data channel and use AES-GCM ciphers.

Compatibility and Client Installation

This type of mobile VPN uses OpenVPN technology and supports the OpenVPN client on all platforms. Windows and
macOS users can download a client from the WatchGuard website. When you direct users to the WatchGuard
website, you can be sure they always download the latest version.

Android and iOS users download a profile from the Firebox portal for use with an OpenVPN client.

Connection Settings
Mobile VPN with SSL uses these ports, protocols, and encryption algorithms to establish a connection:

Configuration port and data port TCP 443 (default; recommended)

UDP 53 (recommended for the data channel if increased performance is a

goal)

Other TCP and UDP ports are less likely to be allowed by remote
networks

Transport and authentication TLS (Transport Layer Security) — requires TLS 1.1 or higher
protocols
Authentication: SHA-1, SHA-256, SHA-512

Encryption protocols AES and AES-GCM (recommended); 3DES

Encryption strength AES: 128-bit, 192-bit, or 256-bit

AES-GCM: 128-bit, 192-bit, or 256-bit

3DES: 168-bit

Network Security Essentials for Locally-Managed Fireboxes Study Guide 199

 Mobile VPN

Setup Overview

For each mobile VPN type, you can use a Setup Wizard or manually configure the settings. We
recommend the wizard because it simplifies configuration.

Wizard Configuration
The Setup Wizards help you to configure these settings:

Domain name or IP address

To connect to the VPN, users specify this domain name or IP address in the VPN client settings.

IP address range
This is a pool of IP addresses reserved for mobile VPN users. When a mobile user connects to the VPN, the
Firebox assigns the user's device an IP address from this pool.

To avoid IP address conflicts, make sure the pool does not overlap with other networks.

Authentication servers
Select an authentication server. The list includes all authentication servers you previously specified in the
Firebox configuration.

Users and groups

Specify which users and groups can connect to the VPN. Each VPN type has a default user group:
n IKEv2-Users
n L2TP-Users
n SSLVPN-Users
You can use the default group, or you can add the names of users and groups that exist on your authentication
server.

If you specify a default Firebox group:

n For RADIUS, LDAP, and Active Directory authentication, you must manually add the group to your
authentication server. You must also add VPN users to that group.
n For RADIUS and SecurID authentication, the RADIUS or SecurID server must return a Filter-Id attribute
where the value of the attribute matches the name of the group.
If you specify a non-default group:
n The groups and users you add to the Firebox must exist on your authentication server. You must specify
the exact same spelling and capitalization. Group and user names are case-sensitive.
n For each group or user, select the authentication server on which the group exists. Or, select Any if the
group or user exists on more than one authentication server.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 200

 Mobile VPN

n Non-default group names do not appear in the list of groups on the Firebox. However, the mobile VPN
policy applies to all users and groups specified in the mobile VPN configuration.

Pre-shared key or certificate

Mobile VPN with IKEv2 and Mobile VPN with SSL use certificates only.

When a Mobile VPN with L2TP tunnel is created, the identity of each endpoint must be verified with a key. This
key can be a:
n Passphrase or pre-shared key known by both endpoints.
n Third-party certificate or self-signed certificate.
n Certificate from the Management Server.

After the wizard completes, you can edit the configuration to change these and other settings. Settings that do not
appear in the wizard are set to default values.

Manual Configuration
To manually configure mobile VPN settings for the first time, select to skip the wizard.

On the manual configuration page, you have access to settings that do not appear in the wizard.

Networking
By default, all traffic from VPN clients goes through the VPN tunnel and your Firebox policies. This includes traffic
destined for the Internet and your internal network. This option provides consistent security but reduced performance.
This option is known as full tunneling.

To send only some traffic from VPN clients through the VPN tunnel, you can specify allowed resources. Only traffic
destined for selected networks goes through the VPN tunnel. This option is also known as split tunneling.

All mobile VPN types support full tunneling. In the Mobile VPN with IKEv2 and Mobile VPN with SSL configurations,
you can also configure settings for split tunneling. You cannot configure settings for split tunneling in the Mobile VPN
with L2TP configuration.

For more information about these options, go to the Mobile VPN Routing Options section.

Authentication and Encryption

You can change the default authentication, encryption, and Diffie-Hellman settings. For all VPN types, the default
values for these settings are:
n Authentication — SHA256
n Encryption — AES256
n Diffie-Hellman group — 14

The Diffie-Hellman setting applies to all mobile VPN types except Mobile VPN with SSL.

In most cases, you can keep these default values. For better VPN performance, we recommend AES-GCM
encryption for mobile VPN types that support this option.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 201

 Mobile VPN

Make sure the settings you configure on the Firebox are the same as the settings on the VPN client.

DNS
In the configuration for each mobile VPN type, you can specify which domain name, DNS servers, and WINS servers
that VPN clients use. Select one of these options:
n Assign the Network (global) DNS/WINS settings to mobile clients — VPN clients use the global name
resolution settings that you specify in the Firebox configuration at Network > Interfaces > DNS/WINS. This
includes settings for the domain name suffix, DNS servers, and WINS servers. This is the default setting for
new mobile VPN configurations.
n Do not assign DNS or WINS settings to mobile clients — VPN clients do not use name resolution settings
from the Firebox. You must specify domain name suffix, DNS server, and WINS server settings on the client.
n Assign these settings to mobile clients — VPN clients use the settings that you specify here. For Mobile VPN
with L2TP, you can specify DNS servers. For Mobile VPN with IKEv2, you can specify DNS servers, WINS
servers, and a domain name suffix (Fireware v12.9.2 or higher). For Mobile VPN with SSL, you can specify
DNS servers, WINS servers, and a domain name suffix.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 202

 Mobile VPN

Policies
When you configure a mobile VPN, the Firebox automatically adds two policies:
n A policy that allows VPN connections to terminate on the Firebox
n A policy that allows all traffic from users in the group to the resources available through the tunnel

Although the mobile VPN connection is secure, you might want to edit the default policies or create custom policies to
limit the types of traffic allowed through the tunnel.

Mobile VPN with IKEv2 Firewall Policies

When you enable Mobile VPN with IKEv2, the Firebox creates these policies:
n Allow-IKE-to-Firebox — A hidden IPSec policy that allows VPN connections to terminate on the Firebox.
n Allow IKEv2 Users — An Any policy that allows the groups and users you configured for IKEv2
authentication to get access to resources on your network.
To control traffic, you can also add other policies for the IKEv2-Users group.

Mobile VPN with SSL Firewall Policies

When you enable Mobile VPN with SSL, the Firebox creates two policies:
n WatchGuard SSLVPN — An SSLVPN policy that allows connections from an SSL VPN client on the port
and protocol you specified (TCP port 443 by default).
n Allow SSLVPN Users — An Any policy that allows the groups and users you configure for SSL
authentication to get access to resources on your network.
To restrict VPN user traffic by port and protocol, you can disable or delete the automatically generated Allow
SSLVPN Users Any policy and create new policies that enable more limited access.

For more information about hidden policies, go to the Hidden Policies section of this guide.

Client Configuration
After you configure the Firebox, you must configure the mobile VPN clients, as specified in the next section.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 203

 Mobile VPN

Client Configuration Files

For some mobile VPN types, you can download client configuration files. These files contain the
settings necessary for VPN clients to connect.

Mobile VPN with IKEv2

After you configure Mobile VPN with IKEv2 and save the configuration to the Firebox, you can download a set of client
configuration files and instructions from the Firebox. The file you download is a compressed .TGZ file that contains:
n Configuration files — WG IKEv2.mobileconfig (macOS and iOS), WG IKEv2.bat (Windows), WG
IKEv2.sswan (Android), and <client-profile-name>.ini (IPSec Mobile VPN client)
n Certificates — <client-profile-name>.crt and <client-profile-name>.pem files
n Instructions — README.txt files for each operating system

You can use these files to easily configure VPN profiles on user computers.

Windows devices
Run the .bat script on the user's computer, which automatically configures the native IKEv2 VPN client.

If you have a large number of users, consider Group Policy for automated deployment. For example, you can
configure Group Policy to automatically push the WG IKEv2.bat script to users each time they log in to the
domain. Group Policy deployment has several benefits:
n Save time with zero-touch deployment.
n Avoid connection issues caused by users who specify incorrect settings in the VPN client.
n Automatically push VPN client configuration updates when users log in to the domain.
For information about Group Policy, go to the Microsoft documentation.

macOS and iOS devices

Import the configuration file in the native IKEv2 VPN client.

Android devices
Import the configuration file in the third-party strongSwan VPN app.

WatchGuard IPSec Mobile VPN client

Import the configuration file in the WatchGuard IPSec Mobile VPN for Windows client.

For computers with Windows 7, you must manually configure the native IKEv2 client. The
automatic configuration script is not supported.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 204

 Mobile VPN

Mobile VPN with SSL

In Fireware v12.11 and higher, the Mobile VPN with SSL client download page is removed from
the Firebox. To download the .OVPN file, go to VPN > Mobile VPN on the Firebox.

When you configure Mobile VPN with SSL, a client configuration file is automatically created and saved on the
Firebox. The client automatically gets the configuration file from the Firebox each time it connects to the Firebox.

Users with the open-source OpenVPN client can also download a Mobile VPN with SSL client profile (.ovpn file) from
your Firebox.

To download the Mobile VPN with SSL client or the .ovpn configuration file, go to:
https://[external interface IP address]/sslvpn.html

For example, if your device has an external IP address of 203.0.113.20, type

https://203.0.113.20/sslvpn.html.

Select one of these download options:

n Mobile VPN with SSL client software for Windows
n Mobile VPN with SSL client software for Mac
n Mobile VPN with SSL client profile
This is the .ovpn profile. To import this profile, you can use any SSL VPN client that supports .ovpn files.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 205

 Mobile VPN

Mobile VPN Routing Options

There are two ways a mobile VPN client can route traffic to the Internet for mobile VPN users:

Default Route (Full Tunnel)

Default-route is the most secure option because it routes all Internet traffic from a remote user through the
VPN tunnel to the Firebox. Then, the traffic is sent back out to the Internet. With this configuration, the Firebox
can examine all traffic and provide increased security. Be aware that this option requires more processing
power and bandwidth.

Default route is the default option for all mobile VPN types. Default route is usually the default setting on all
operating systems.

If you manually configure the client in Windows 10, you might need to change the IPv4 adapter
properties for the IKEv2 VPN connection so that Use default gateway on remote network is
selected. This is the default-route (full tunnel) option.

Split tunnel
With split tunnel, users can browse the Internet, but their Internet traffic is not sent through the VPN tunnel. A
split tunnel VPN has better network performance than a default route VPN. However, split tunneling decreases
security because the Firebox policies you create are not applied to the Internet traffic.

These mobile VPN types support split tunnel:

n Mobile VPN with IKEv2
n Mobile VPN with SSL
To configure a split tunnel for Mobile VPN with IKEV2, from Fireware Web UI or Policy Manager:
n In the Mobile VPN with IKEv2 configuration, select Specify allowed resources.
n Add a host or network IP addresses. Mobile VPN with IKEv2 users can connect to only these specified
resources on your internal networks.
To configure a split tunnel for Mobile VPN with SSL, from Fireware Web UI or Policy Manager:
n In the Mobile VPN with SSL configuration, select Allow access to all Trusted, Optional, and Custom
networks or Specify allowed resources.
n If you selected to allow resources, add a host or network IP address. Mobile VPN with SSL users can
connect to only these specified resources on your internal networks.
n For BOVPN access through the SSL VPN, specify tunnel routes. This configuration is another type of split
tunneling.
The Firebox supports connections from Mobile VPN with L2TP clients configured for split tunneling. However,
you must manually configure L2TP clients for split tunneling. For example, you must manually add routes on
the client computer for each remote network that you require access to. We do not provide customer support
for split tunnel configurations on L2TP clients. See the documentation provided by your VPN client vendor.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 206

 Mobile VPN

For both default route and split tunnel, we recommend that each client computer has security
software. For example, anti-virus software and WatchGuard Endpoint Security on the client
computer can protect the client from malicious software. This can help protect your corporate
network from malicious traffic that might arrive from the client through the VPN.

Virtual IP Address Pool

When you configure mobile VPN on the Firebox, you define a pool of virtual IP addresses. The Firebox assigns an IP
address from the virtual IP address pool to each mobile VPN user until all addresses are in use. When a user closes a
VPN session, the IP address used by that session becomes available again.

Follow these guidelines when you assign a virtual IP address pool:

n Use a private IP address range that is not used for anything else on your network. The virtual IP addresses do
not have to be on the same subnet as the trusted network.
n If you configure Mobile VPN with SSL to bridge VPN traffic to a bridge interface, the virtual IP addresses must
be on the same subnet as the bridge interface.
If you configure split tunneling with this bridge configuration, you can only access the single bridge subnet.
Other internal networks are not accessible. We recommend this configuration only for legacy software that
works on only one subnet.
n To enable the maximum number of concurrent VPN connections, make sure the virtual IP address pool
contains the same number of IP addresses as the maximum number of VPN connections your Firebox
supports. If you specify an IP address pool with more IP addresses than the maximum number supported by
your Firebox, the Firebox does not use the additional IP addresses.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 207

 Branch Office VPN

Branch Office VPN

A branch office Virtual Private Network (BOVPN) enables secure, encrypted connections between networks at
geographically separated locations.

In this section you learn about:

n Different BOVPN types
n Algorithms, protocols, and negotiations
n Policies
n BOVPN and BOVPN virtual interface configuration
n NAT
n Dynamic public IP addresses
n Topologies

For a list of additional resources on these topics, go to BOVPN Additional Resources.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 208

 Branch Office VPN

BOVPN Introduction

A branch office VPN (BOVPN) is an encrypted and authenticated connection between two
networks. Companies use a BOVPN to securely send data through an untrusted network such
as the Internet. A BOVPN connection is also known as a site-to-site tunnel.

The Firebox can build an IPSec VPN tunnel to another Firebox or to any 3rd-party IPSec-compliant VPN endpoint.
When an IPSec tunnel is created, the two tunnel endpoints authenticate with each other to send and receive
encrypted data.

A BOVPN provides these benefits:

n Data privacy and confidentiality — Data is encrypted so only the sender and the recipient of the traffic can
read it.
n Data integrity — Data cannot be changed after it is sent.
n Data authentication — Data comes from one of the two endpoints of the VPN and not from an attacker on the
Internet.
n Direct private IP address to private IP address communication — Computers at the two offices communicate
as if they were not behind devices configured with Network Address Translation (NAT). The data tunnels
through NAT for a transparent connection between the devices.

The Firebox examines traffic to and from computers on the network it protects. It uses the source and destination IP
address of the traffic and the VPN settings to decide what traffic to encrypt and send to the remote VPN gateway.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 209

 Branch Office VPN

Topology
This diagram shows a Firebox and a third-party endpoint as the BOVPN gateway endpoints. Third-party endpoints
must support site-to-site tunnels. You can also create a VPN between two Fireboxes.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 210

 Branch Office VPN

Fireware BOVPN Types

Fireware supports four types of BOVPNs:

Manual BOVPN gateway and associated tunnels

You can manually create a BOVPN gateway and associated tunnels. When you configure a manual BOVPN
gateway, you can use a second Firebox as the other BOVPN gateway or use a third-party VPN device that
supports IKEv1 or IKEv2.

When you add a BOVPN gateway and tunnels to configure a BOVPN, you set both the source and destination
for the traffic you want to send through the tunnel. The device routes a packet through the BOVPN tunnel if the
source and destination of the packet match a configured VPN tunnel route.

This type of BOVPN works with all Fireboxes and most third-party devices (except cloud services). Manual
BOVPN does not support dynamic routing or static routes with metrics.

BOVPN virtual interface

A BOVPN virtual interface (VIF) offers a more flexible configuration because the Firebox decides whether to
route a packet through the virtual interface tunnel based on the outgoing interface specified for the packet. You
can specify a BOVPN virtual interface when you configure static routes, dynamic routing, and SD-WAN. You
can select any internal or external interface as the gateway endpoint for a BOVPN virtual interface.

This type of BOVPN works with any third-party device that supports Cisco VTI or GRE over IPSec. BOVPN
virtual interfaces support VPN connections to cloud-based endpoints such as Microsoft Azure and Amazon
AWS.

Managed VPN tunnel

A managed VPN tunnel is a BOVPN tunnel that you create between two centrally managed Fireboxes. From
your WatchGuard Management Server, you can drag and drop one managed Firebox onto another managed
Firebox to quickly configure a VPN tunnel between the two devices based on templates and VPN resources
defined on the Management Server. You can also use the hub-and-spoke method to create a managed VPN
tunnel between two Fireboxes managed by Dimension.

You cannot use the Management Server to configure a BOVPN virtual interface.

Managed VPN tunnels are not discussed in detail in this guide but use the same security settings and
protocols as a manual VPN tunnel. For more information about managed VPN tunnels, go to Fireware Help.

BOVPN over TLS

You can configure a BOVPN tunnel that uses TLS for secure communication between Fireboxes. Third-party
endpoints are not supported. Fireboxes configured for BOVPN over TLS send VPN tunnel traffic over port 443,
which is usually open on most networks.

We recommend BOVPN over TLS only when your network cannot pass IPSec traffic. For a full or partial mesh
VPN configuration on a network that allows IPSec traffic, we recommend that you configure an IPSec BOVPN
tunnel. An IPSec BOVPN tunnel is better suited for environments that require high VPN performance.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 211

 Branch Office VPN

Select a VPN Type

How do you decide which VPN type to use? Here are some guidelines to consider:

VPN Type When to Use It

Manual With a manual BOVPN, traffic is always routed through the tunnel if the source and destination IP
BOVPN addresses match a tunnel route in the VPN configuration.

Use this type of VPN for:

n A VPN tunnel between a Firebox and a third-party device that does not support GRE over
IPSec.
n A VPN tunnel between any two Fireboxes.

BOVPN With a BOVPN virtual interface, traffic is routed through the VPN if the VPN route has the route
Virtual distance with the highest priority to the destination. You assign a route distance from 1 to 254 to
Interface each BOVPN virtual interface route. A route distance of 1 has highest priority.

You can use this type of tunnel in many different network routing scenarios, such as SD-WAN,
metric-based failover and failback, dynamic routing, and routing of IPv6 traffic through an IPv4
tunnel.

Use this type of VPN for:

n A VPN tunnel between two Fireboxes.
n A VPN tunnel between a Firebox and a third-party device that supports GRE over IPSec.
n A VPN tunnel between a Firebox and a third-party device that supports IPSec without
GRE, and wildcard traffic selectors.

Use this type of VPN if you want to separate the routing from the VPN security association. The
VPN security association is the secure, authenticated channel between two gateway endpoints.

Managed Managed BOVPN tunnels are useful if you want to create and manage a large number of tunnels
BOVPN between Fireboxes that are managed by a WatchGuard Management Server. On the
Management Server, you can create Security Templates and VPN Firewall Policy Templates that
can be used for one or more managed VPN tunnels. The templates make it easier to configure a
large number of VPN tunnels with consistent settings.

Use this type of VPN for VPN tunnels between Fireboxes managed by a WatchGuard
Management Server.

BOVPN If your network does not allow IPSec traffic, BOVPN over TLS tunnels are useful because they
over TLS send traffic over port 443, which is usually open on most networks. Manual BOVPN tunnels and
BOVPN Virtual Interfaces use IPSec.

Because this is the slowest type of VPN, we recommend it only when these conditions are true:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 212

 Branch Office VPN

VPN Type When to Use It

n Your network cannot pass IPSec traffic. For example, some ISPs might not allow IPSec
traffic, and some older NAT devices might drop packets related to IPSec traffic. Or, your
business operates in a location where you do not have full control of the network and
cannot open ports required for an IPSec BOVPN.
n You do not require a full mesh VPN.

Manual BOVPN tunnels, BOVPN virtual interfaces, and managed BOVPN tunnels use the same IKEv1 protocols and
tunnel negotiation procedure. Manual BOVPN and BOVPN virtual interfaces also support IKEv2. In this section, we
focus on what you must know to configure and monitor manual BOVPN gateways and tunnels.

VPN Tunnel Capacity

The maximum number of active VPN tunnels your Firebox supports depends on the Firebox model. You can go to the
maximum number of tunnels in the feature key for your device.

The value in the feature key limits the number of security associations (SAs) that can be active at the same time. A
BOVPN tunnel route counts as one SA. A BOVPN virtual interface counts as one SA, regardless of the number of
tunnel routes.

The feature key does not limit the number of tunnel routes you can configure for BOVPNs.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 213

 Branch Office VPN

IPSec VPN Algorithms and Protocols

IPSec is a collection of cryptography-based services and security protocols that protect communication between
devices that send traffic through an untrusted network. You can create an IPSec VPN between your Firebox and
many other devices that support these standard protocols.

When two IPSec gateway devices attempt to establish a VPN connection, they exchange a series of messages about
encryption and authentication, and agree on many different parameters. This process of agreeing on the VPN
parameters is called VPN negotiations.

VPN negotiations happen in two distinct phases:

Phase 1
The main purpose of Phase 1 is to set up a secure authenticated channel through which the two devices can
negotiate Phase 2. Phase 1 communication occurs between the external interfaces of the VPN peers. If Phase
1 fails, the devices cannot begin Phase 2.

Phase 2
The purpose of Phase 2 negotiations is for the two VPN gateways to agree on a set of parameters that define
what traffic can go through the VPN tunnel, and how to encrypt and authenticate the traffic. This agreement is
called a Security Association.

For detailed information about what happens during Phase 1 and Phase 2, go to the VPN Negotiations section.

Both VPN gateway devices must use the same Phase 1 and Phase 2 settings to negotiate a VPN tunnel. For
example, if you configure an endpoint for IKEv1, the other endpoint must use IKEv1. The next sections discuss Phase
1 and 2 settings.

IKEv1
IKE is a protocol used to set up security associations for IPSec. Security associations establish shared session
secrets. Keys are derived from security associations and used to encrypt data in the IPSec tunnel. IKE is also used to
authenticate the two IPSec peers.

Fireware supports IKEv1 and IKEv2 for BOVPN and BOVPN virtual interface configurations. Fireware does not
support for IKEv2 for managed BOVPNs.

IKEv1 has multiple modes:

Main Mode
Main mode is more secure. This mode uses three separate message exchanges, six messages total, for
Phase 1. The first two messages negotiate policy, the next two exchange Diffie-Hellman data, and the last two
authenticate the Diffie-Hellman exchange. This mode allows you to use multiple transforms.

Use Main Mode when both VPN peers have static IP addresses.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 214

 Branch Office VPN

Aggressive Mode
This mode is faster because it uses only three messages to exchange data and identify the two VPN
endpoints. The identification of the VPN endpoints makes Aggressive Mode less secure. Also, the IKEv1
Aggressive Mode vulnerability described in CVE-2002-1623 means that Aggressive Mode is less secure than
Main Mode unless you configure a certificate. IKEv2 is a better option than IKEv1 and easier than certificate
configuration.

When you use Aggressive Mode, the endpoints exchange only three messages for Phase 1, which is half as
many as Main Mode. The exchange relies mainly on the ID types used in the exchange by both appliances.
Aggressive Mode does not ensure the identity of the peer. Main Mode ensures the identity of both peers, but
can only be used if both sides have a static IP address. If your device has a dynamic IP address, you should
use Aggressive Mode for Phase 1.

Main Fallback to Aggressive

The Firebox attempts Phase 1 exchange with Main Mode. If the negotiation fails, it uses Aggressive Mode.

For IKEv1, Phase 1 sends six to nine messages, depending on the mode. Phase 2 sends only
three messages.

IKEv2
IKEv2 does not have multiple modes. It differs from IKEv1 in several other ways:
n IKEv2 has a simpler Phase 1 message exchange.
n IKEv2 requires only four messages to establish a tunnel.
n IKEv2 is more reliable than IKEv1:
n Better logging when a settings mismatch occurs
n Cryptographic enhancements
n Payload enhancements
n IKEv2 interoperates with third-party gateways that use IKEv2
n IKEv2 does not support the obsolete IKE Keep-Alive setting.
n NAT Traversal is always enabled.
n Dead Peer Detection (DPD) is always enabled.
n Dead Peer Detection can be Traffic-Based or Timer-Based.
n IKEv2 uses shared Phase 1 settings for all BOVPN gateways that have a peer with a dynamic IP address.

We recommend IKEv2 because it is fast, it is the most secure option, and it works with static or
dynamic endpoints. We recommend IKEv2 unless the remote device does not support it.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 215

 Branch Office VPN

Encryption Algorithms
Encryption algorithms protect data so it cannot be read by a third-party while in transit. Longer encryption keys are
more secure. Fireware BOVPNs support these encryption algorithms:
n AES (Advanced Encryption Standard) — AES is the strongest encryption algorithm available. Fireware can
use AES encryption keys of these lengths: 128, 192, or 256 bits.
n 3DES (Triple-DES) — An encryption algorithm based on DES that uses the DES cipher algorithm three times
to encrypt the data. The encryption key is 168-bit. 3DES is slower than AES. The Sweet32 vulnerability affects
3DES.
n DES (Data Encryption Standard) — Uses an encryption key that is 56 bits long. DES is the weakest of the
three algorithms, and it is considered to be insecure.

In the Phase 2 settings, you can also specify AES-GCM. GCM is an authenticated encryption algorithm known for its
security, efficiency, and performance. For increased performance, we recommend AES-GCM. With AES-GCM,
authentication and encryption occur simultaneously, which eliminates the need for an additional hashing algorithm
calculation. Fireware can use AES-GCM encryption keys of these lengths: 128, 192, or 256 bits.

We strongly recommend that you select an AES or AES-GCM variant. DES and 3DES are
weaker than AES and are considered to be insecure.

Authentication Algorithms
Authentication algorithms verify that data packets are complete and not sent by a third-party. Each algorithm
produces a message digest, also called a hash, which represents a set of data packets. When the data packets are
received by the other BOVPN gateway, that device can use the same authentication algorithm to verify the data.
Longer hashes are more secure.

SHA-2 (Secure Hash Algorithm 2)

SHA-2 is the only secure authentication algorithm supported. It is also the most computationally intensive
algorithm. Fireware supports these types of SHA-2:

SHA2-256 — Produces a 256-bit (32 byte) message digest

SHA2-384 — Produces a 384-bit (48 byte) message digest

SHA2-512 — Produces a 512-bit (64 byte) message digest

SHA-2 is not supported on most XTM series devices. The hardware cryptographic acceleration
in those models does not support SHA-2. All T Series and M Series Fireboxes support SHA-2.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 216

 Branch Office VPN

SHA-1 (Secure Hash Algorithm 1)

SHA-1 produces a 160-bit (20 byte) message digest. SHA-1 is considered to be mostly insecure because of a
vulnerability.

MD5 (Message Digest Algorithm 5)

MD5 produces a 128-bit (16 byte) message digest, which makes it faster than SHA-1 or SHA-2. MD5 is
considered to be insecure.

Diffie-Hellman Key Exchange Algorithms

Fireware v12.10 and higher supports Diffie-Hellman Group 21.

The Diffie-Hellman (DH) key exchange algorithm is a method for two VPN gateways to share an encryption key
without sending the key itself as unencrypted information. When the key exchange is complete, both VPN gateways
can use the same key to encrypt VPN data.

A Diffie-Hellman key group is a group of integers used for the Diffie-Hellman key exchange. Fireware supports these
Modular Exponential (MODP) and Elliptic Curve Cryptography (ECC) groups:

MODP — 1, 2, 5, 14, and 15. For MODP, higher group numbers are more secure but require additional time to
compute the key. Group 14 is the lowest Diffie-Hellman group considered to be secure.

ECC — 19, 20, and 21. These groups are faster and more secure than MODP groups.

We recommend Group 14 or higher. For even better security and performance, we recommend
Group 19, 20 or 21.

For more information about Diffie-Hellman Groups, go to RFC 8247.

AH (Authentication Header)
Defined in RFC 2402, AH is a protocol that you can use in manual BOVPN Phase 2 VPN negotiations. To provide
security, AH adds authentication information to the VPN data. While AH provides protection against spoofed packets,
most VPN tunnels do not use AH because it does not provide encryption.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 217

 Branch Office VPN

ESP (Encapsulating Security Payload)

Defined in RFC 2406, ESP provides authentication and encryption of data. ESP takes the original payload of a data
packet and replaces it with encrypted data. It adds integrity checks to make sure that the data is not altered in transit.
We recommend that you use ESP in BOVPN Phase 2 negotiations because ESP is more secure than AH.

Performance Impact
The Phase 2 settings that you select impact BOVPN throughput. Stronger algorithms offer greater security but impact
performance more. The elliptic curve Diffie-Hellman groups (19, 20, and 21) usually offer better performance and
security than MODP Diffie-Hellman groups. WatchGuard supports MODP groups 15 or lower.

In the Phase 2 settings, AES-GCM(128-bit) with Diffie-Hellman 19 offer good performance.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 218

 Branch Office VPN

Policies and VPN Traffic

Fireware allows traffic to and from your network only if the configuration file includes a policy to allow the traffic. In this
section, we examine methods you can use to add policies that allow traffic over your Branch Office VPNs.

Automatically Add Policies That Allow All Traffic

When you add a BOVPN tunnel, Policy Manager automatically adds two Any policies to your configuration to allow all
traffic through the VPN. If you do not want the tunnel to use these policies, clear the Add this tunnel to the BOVPN-
Allow policies check box in the branch office tunnel configuration.

If you do not add the tunnel to the default BOVPN policies, you must create a custom VPN policy to allow the types of
traffic you want to allow. You can also use the default BOVPN policies and configure additional BOVPN policies for
other types of traffic such as HTTP traffic.

Use the BOVPN Policy Wizard

In Policy Manager, you can use the BOVPN Policy Wizard to create a pair of VPN policies to allow traffic to pass
through a branch office VPN tunnel. The BOVPN Policy Wizard is not available in Fireware Web UI

The BOVPN Policy Wizard adds two policies of the type you select. For example, if you select HTTP in the BOVPN
Policy Wizard, it creates two policies, one for inbound HTTP traffic through the tunnel, and one for outbound HTTP
traffic through the tunnel. You can also add aliases which identify the names of the BOVPN or BOVPNs you selected
in the wizard.

To run the BOVPN Policy Wizard, in Policy Manager, select VPN > Create BOVPN Policy.

Manually Add Policies

You can add your own policies to allow connections from the remote VPN network.
n From — Specific addresses on the other side of the VPN, or a BOVPN virtual interface name
n To — Specific addresses behind your Firebox

You can also add your own policies to allow connections to the remote VPN network.
n From — Specific addresses behind your Firebox
n To — Specific addresses on the other side of the VPN, or a BOVPN virtual interface name

You can also specify a tunnel name in a policy. For example, in the policy, click Add > Add Other > Choose Type >
Tunnel Address. From the Tunnel drop-down list, select a tunnel name or select an alias created by the BOVPN
Policy Wizard.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 219

 Branch Office VPN

Network Security Essentials for Locally-Managed Fireboxes Study Guide 220

 Branch Office VPN

VPN Negotiations

What Happens in Phase 1 Negotiations?

In Phase 1 negotiations, the two VPN gateway devices exchange credentials. The devices identify each other and
negotiate to find a common set of Phase 1 settings to use. When Phase 1 negotiations are completed, the two
devices have a Phase 1 Security Association (SA). This SA is valid for a specified amount of time. If the two VPN
gateways do not complete Phase 2 negotiations before the Phase 1 SA expires, then they must complete Phase 1
negotiations again.

The Phase 1 negotiation process depends on which version of IKE the gateway endpoints use. IKE authenticates
IPSec peers and negotiates IKE SAs during this phase, setting up a secure communications channel for negotiating
IPSec SAs in Phase 2.

Phase 1 negotiations include these steps:

1. The devices agree on the IKE version to use (IKEv1 or IKEv2). Each device can use IKEv1 or IKEv2. The IKE
version for both devices must match.
2. The devices exchange credentials.

The credentials can be a certificate or a pre-shared key. Both gateway endpoints must use the same
credential method, and the credentials must match.

3. The devices identify each other.

Each device provides a Phase 1 identifier, which can be an IP address, domain name, domain information, or
an X500 name. The VPN configuration on each device specifies the Phase 1 identifier of the local and the
remote device. The configurations must match.

4. For IKEv1, the VPN gateways decide whether to use Main Mode or Aggressive Mode for Phase 1
negotiations.

The VPN gateway that starts the IKE negotiations sends either a Main Mode proposal or an Aggressive Mode
proposal. The other VPN gateway can reject the proposal if it is not configured to use that mode.
n Main Mode ensures the identity of both VPN gateways, but can be used only if both devices have a static
IP address. Main Mode validates the IP address and gateway ID.
n Aggressive Mode is faster but less secure than Main Mode because it requires fewer exchanges between
two VPN gateways. In Aggressive Mode, the exchange relies mainly on the ID types used in the
exchange by both VPN gateways. Aggressive Mode does not ensure the identity of the VPN gateway.
The IKEv1 Aggressive Mode vulnerability described in CVE-2002-1623 means that Aggressive Mode is
less secure than Main Mode unless you configure a certificate.
5. The VPN gateways agree on Phase 1 parameters.
n Whether to use NAT traversal
n Whether to use IKE Keep-Alive (between Fireboxes only)
n Whether to use Dead Peer Detection (RFC 3706)
IKE Keep-Alive is an obsolete setting. We recommend DPD instead.
For IKEv2, NAT Traversal and DPD are always enabled, and IKE Keep-Alive is not supported.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 221

 Branch Office VPN

6. The VPN gateways agree on Phase 1 Transform settings. The settings in the Phase 1 transform on each
IPSec device must exactly match, or IKE negotiations fail.
The items you can set in the Phase 1 transform are:
n Authentication — The type of authentication (SHA-2, SHA-1, or MD5)
n Encryption — The type of encryption algorithm (DES, 3DES, or AES) and key length
n SA Life — The amount of time until the Phase 1 Security Association expires
n Key Group — The Diffie-Hellman key group

Network Security Essentials for Locally-Managed Fireboxes Study Guide 222

 Branch Office VPN

What Happens in Phase 2 Negotiations?

After the two IPSec VPN gateways successfully complete Phase 1 negotiations, Phase 2 negotiations begin. The
purpose of Phase 2 negotiations is to establish the Phase 2 SA (sometimes called the IPSec SA). The IPSec SA is a
set of traffic specifications that tell the device what traffic to send over the VPN, and how to encrypt and authenticate
that traffic.

Phase 2 negotiations include these steps:

1. The VPN gateways use the Phase 1 SA to secure Phase 2 negotiations. The VPN gateways agree on whether
to use Perfect Forward Secrecy (PFS).

VPN encryption keys are changed at the interval specified by the Force Key Expiration setting. The interval
is eight hours by default. To prevent SAs from using Phase 1 keys for Phase 2, PFS forces the DH calculation
to happen a second time. This means that Phase 1 and Phase 2 always have different keys, which is harder to
break unless you select a DH group lower than 14.
We recommend that you use PFS to keep your data secure. If you want to use PFS, it must be enabled on both
VPN gateways, and both gateways must use the same Diffie-Hellman key groups.

2. The VPN gateways agree on a Phase 2 proposal.

The Phase 2 proposal includes the algorithm to use to authenticate data, the algorithm to use to encrypt data,
and how often to make new Phase 2 encryption keys.

The items you can set in a Phase 2 proposal include:

n Type — For a manual BOVPN, you can select the type of protocol to use: Authentication Header (AH) or
Encapsulating Security Payload (ESP). AH adds authentication information to the VPN data and protects
against spoofing, but it does provide encryption. ESP encrypts the data and protects against spoofing and
packet manipulation (replay detection). We recommend that you use ESP, because you can protect
against spoofing in other ways. Managed BOVPNs, Mobile VPN with IKEv2, Mobile VPN with IPSec, and
Mobile VPN with L2TP always use ESP.
n Authentication — Authentication makes sure that the information received is exactly the same as the
information sent. You can use SHA-1, SHA-2, or MD5 as the algorithm the VPN gateways use to
authenticate IKE messages from each other. SHA-2 is the only secure option.
n Encryption — Encryption keeps the data confidential. You can select DES, 3DES, or AES, or AES-GCM.
AES and AES-GCM variants are the only secure options.
n Force Key Expiration — To make sure Phase 2 encryption keys change periodically, specify a key
expiration interval. The default setting is 8 hours. The longer a Phase 2 encryption key is in use, the more
data an attacker can collect to use to mount an attack on the key. We recommend that you do not select
the Traffic option because it causes high Firebox load, throughput issues, packet loss, and frequent,
random outages. The Traffic option does not work with most third-party devices.

3. The VPN gateways exchange Phase 2 traffic selectors (tunnel routes).

You can specify the Phase 2 traffic selectors for the local and remote VPN gateway as a host IP address, a
network IP address, or an IP address range. Phase 2 traffic selectors are always sent as a pair in a Phase 2
proposal: one indicates which IP addresses behind the local device can send traffic over the VPN, and the
other indicates which IP addresses behind the remote device can send traffic over the VPN. This is also known
as a tunnel route.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 223

 Branch Office VPN

Phase 1 Setting IKEv1 IKEv2

Modes Main or Only one mode

Aggressive

NAT Traversal Can be Always enabled

enabled or
disabled

IKE Keep-Alive* Supported Not supported

Dead Peer Can be Always enabled

Detection (DPD) enabled or
Can be traffic-based or time-based (as described in RFC 3706):
disabled
n Traffic-Based — the Firebox sends a DPD message only if no traffic
Always traffic-
is received from the remote gateway for a specified length of time
based
and a packet is waiting to be sent to the remote gateway. This is the
default option, and we recommend it because it is more efficient
and scales better as you add gateway endpoints.
n Timer-Based — the Firebox sends a DPD message at a specified
interval, regardless of any other traffic received from the remote
gateway.

Shared Settings None Transform settings are shared for all dynamic endpoints and Mobile VPN
with IKEv2. Shared settings include:
n NAT Traversal Keep-Alive interval
n Phase 1 transforms

*This is an obsolete setting. We recommend DPD in all cases for reliability, performance, and scalability.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 224

 Branch Office VPN

BOVPN Configuration
You can configure these types of BOVPNs on the Firebox:
n Manual BOVPN
n BOVPN virtual interface
n BOVPN over TLS
n Managed BOVPN

At least one of the VPN devices needs to have a known public IP address or FQDN. This is required so that at least
one of the VPN peers knows how to initiate VPN communications.

In this section, we show you two examples:

n Example 1 — Basic settings required for a BOVPN
n Example 2 — BOVPN failover

For information about BOVPN settings not covered in this guide, go to Fireware Help.

Example 1 — Basic Settings

In our example configuration, a BOVPN connects two VPN peers: a Firebox at Site A and a Firebox or third-party
device at Site B. To configure the BOVPN, you add gateway endpoints and tunnels on the local and remote devices.

For this example, the BOVPN endpoints have these IP addresses:

Site A Firebox IP addresses

External interface: 203.0.113.10

Trusted network: 10.0.10.0/24

Site B Firebox IP addresses:

External interface IP address: 192.0.2.20

Trusted network: 10.0.20.0/24

The example configuration settings below define a tunnel between the trusted networks at Site A and Site B.

Configuration (Site A)
Gateway
To configure a BOVPN gateway, specify these settings:

General Settings
Address family — IPv4 or IPv6. In the gateway and tunnel settings, the IP addresses you specify must be
from the same family. For example, if you specify the IPv4 Addresses family, you can only specify IPv4
addresses in the gateway and tunnel settings.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 225

 Branch Office VPN

Credential method — Pre-shared key or an IPSec Firebox certificate.

In our example, the Site A Firebox has these general settings:

n Address family: IPv4
n Credential method: Pre-shared key

IP Address Settings
In this part of the BOVPN configuration, you specify the location of the local and remote gateways.

In our example, the Site A Firebox has these IP address settings:

n External Interface — External
Any external interface can be a gateway endpoint. If you have multiple external interfaces on your
Firebox, you can configure BOVPN failover if you add additional BOVPN gateway endpoints. Go to
Example 2 in this section.
n Interface IP address — Primary interface IPv4 address.
This is the primary IP address of the External Interface you selected. Or, you can select a secondary IP
address that is already configured on the selected external interface.
n Local Gateway IP Address — 203.0.113.10
n Local Gateway ID — 203.0.113.10.
The Gateway ID is for identification purposes only and is not involved in routing.
n Remote Gateway IP Address — 192.0.2.20
n Remote Gateway ID — 192.0.2.20

You must know whether the IP address assigned to the other VPN device is static or dynamic. If the other VPN device
has a dynamic IP address and uses dynamic DNS, you can specify the domain name of that device. If the other
device does not use dynamic DNS, that device can send any non-resolvable domain string if it is the initiator.

For dynamic endpoints, you must use either IKEv1 Aggressive Mode or IKEv2 (recommended).

Network Security Essentials for Locally-Managed Fireboxes Study Guide 226

 Branch Office VPN

Phase 1 settings
In Phase 1, the VPN peers establish a secure, authenticated channel for communication. This is known as the
Security Association (SA). The Phase 1 SA creates a secure channel for Phase 2 negotiations. You configure
Phase 2 settings later when you add the BOVPN tunnel.

We recommend that you select strong Phase 1 encryption options. Phase 1 does not directly affect the file
transfer speed on the BOVPN. This means that strong Phase 1 encryption options do not affect performance.

We recommend these Phase 1 settings:

n Version — IKEv2
We recommend that you select IKEv2 if the peer VPN supports it. IKEv2 establishes and rebuilds more
quickly than IKEv1.
n Transform — SHA2-256-AES (256-bit)

Network Security Essentials for Locally-Managed Fireboxes Study Guide 227

 Branch Office VPN

Tunnel
After you add a BOVPN gateway, you configure a BOVPN tunnel.

In the tunnel configuration, you specify these settings:

n Gateway — A BOVPN gateway already configured on your Firebox.
n Addresses (Tunnel Routes) — The local and remote IP addresses for the route. The IP address you specify
must be of the same address family (IPv4 or IPv6) as the gateway.
n Phase 2 — Perfect Forward Secrecy (PFS), Diffie-Hellman group, and IPSec proposals. By default, the PFS
and Diffie-Hellman Group 14 options are enabled. The default IPSec proposal is ESP-AES256-SHA256.

Phase 2 settings affect BOVPN performance. However, we recommend that you specify strong
ciphers for security reasons. Diffie-Hellman Group 14 is the lowest Diffie-Hellman group
considered to be secure. We recommend that you select Diffie-Hellman Group 14 or higher.

Addresses (Tunnel Routes)

On the Addresses tab, you specify tunnel routes, which are the local networks behind the Fireboxes or third-
party endpoints.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 228

 Branch Office VPN

In our example, the Site A Firebox has these tunnel route settings:
n Local — 10.0.10.0/24
n Remote — 10.0.20.0/24

Phase 2
The Site A Firebox uses the default Phase 2 settings:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 229

 Branch Office VPN

Configuration (Site B)
The configuration at Site B is exactly the same as at Site A with these exceptions:
n Local and remote gateway IP addresses are reversed
n Local and remote tunnel addresses are reversed

For example, the Site B Firebox or third-party device has this configuration.

Gateway
n Local Gateway IP Address — 192.0.2.20
n Local Gateway ID — 192.0.2.20
n Remote Gateway IP Address — 203.0.113.10
n Remote Gateway ID — 203.0.113.10

Tunnel
n Local — 10.0.20.0/24
n Remote — 10.0.10.0/24

Network Security Essentials for Locally-Managed Fireboxes Study Guide 230

 Branch Office VPN

Zero Route
You can force all traffic over a BOVPN to push Internet-bound traffic through the main location. This also helps to
make tunnel switching easier in hub and spoke deployments.

For more information, go to BOVPN Topologies.

Example 2 — Failover
To help ensure BOVPN availability, you can configure BOVPN failover between two Fireboxes. BOVPN failover is not
supported for third-party endpoints.

VPN failover occurs if the Firebox detects any of these events:

n Physical or logical link failure — The Firebox uses Link Monitor to determine whether a link is active.
n Inactive VPN peer — The Firebox uses dead peer detection (DPD) to determine whether a peer is active.

Keep DPD enabled. If you disable DPD, the Firebox cannot detect when a peer becomes
inactive, and the Firebox continues to send traffic to the inactive peer.

Requirements for BOVPN failover:

n The Firebox must have at least two external interfaces.
n You must configure Link Monitor targets for the external interfaces.
n On the remote Firebox, you must add a second gateway endpoint for the backup external interface on the
local Firebox.

You can configure partial or full gateway endpoint redundancy:

n Partial redundancy — Only one Firebox has redundant external interfaces and gateway endpoints.
n Full redundancy — Both Fireboxes have redundant external interfaces and gateway endpoints.

In this example, we configure the Fireboxes at both sites for full gateway endpoint redundancy.

The Firebox at Site A has these external interfaces:

n External-1 — 203.0.113.2
n External-2 — 192.0.2.1

The Firebox at Site B has these external interfaces:

n External-1 — 198.51.100.2
n External-2 — 192.0.3.1

On both Fireboxes, configure at least two external interfaces and add the external interfaces to Link Monitor. We
recommend that you specify a target other than the default gateway. For more information about Link Monitor, go to
the Link Monitor section of this guide.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 231

 Branch Office VPN

In the BOVPN configuration on the Site A Firebox, configure these gateway endpoints:

In the BOVPN configuration at Site B, configure the same gateway endpoint settings, but in reverse.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 232

 Branch Office VPN

Each gateway address pair must be listed in the same order in the Gateway Endpoints list on both Fireboxes.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 233

 Branch Office VPN

BOVPN Virtual Interface Configuration

In this section, we explain how a BOVPN virtual interface differs from a manual BOVPN. We also show example use
cases for BOVPN virtual interfaces.

You can configure a BOVPN virtual interface tunnel between two Fireboxes, or between a Firebox and a third-party
endpoint. If you configure a VPN as a BOVPN virtual interface, the VPN on the remote VPN gateway must also be
configured as a BOVPN virtual interface.

When you configure a BOVPN virtual interface, you add a new interface to the Firebox. The interface is virtual
(logical) rather than a physical, hardware-based interface.

BOVPN virtual interfaces can help you with advanced routing needs. For example, with a BOVPN virtual interface,
you can configure:
n Metric-based failover
n Dynamic routing

BOVPN virtual interfaces make sure that replies to Firebox-generated traffic use the VPN tunnel. Examples of
Firebox-generated traffic include DNS and DHCP traffic, Dimension, syslog, SNMP, NTP, authentication (Active
Directory, LDAP, and RADIUS), and other connections established by the Firebox to resources through the tunnel.

Failover is not supported for third-party endpoints.

Configuration
The BOVPN virtual interface configuration is similar to the manual BOVPN configuration. For example, manual
BOVPNs and BOVPN virtual interfaces have many of the same Phase 1 and 2 options. VPN Routes in the
BOVPN virtual interface configuration is the main difference.

For a BOVPN virtual interface, the Firebox uses its routing table to determine whether to send traffic through the VPN
tunnel. You do not explicitly configure the local and remote addresses for each tunnel route. Instead, for each BOVPN
virtual interface, you can configure static routes that use this BOVPN virtual interface as a gateway.

You configure these routes on the VPN Routes tab. For each route, you specify a destination and a metric:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 234

 Branch Office VPN

Static routes that you add to the VPN Routes list also appear in the static routes list for the Firebox. This is different
than a manual BOVPN, which uses a separate IPSec routing table.

Because of the general similarities between manual BOVPN and BOVPN virtual interface settings, this guide does
not include complete configuration procedures for BOVPN virtual interfaces. For step-by-step instructions, go to
Fireware Help.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 235

 Branch Office VPN

Examples
In this section, we briefly describe common uses for BOVPN virtual interfaces. For detailed configuration examples,
go to Fireware Help.

Failover
You can configure failover between a physical Firebox interface and a BOVPN virtual interface. Or, you can configure
failover between two BOVPN virtual interfaces.

It is important to understand that routes with lower metrics have higher priority. Routes with
higher metrics have lower priority. For example, a route with a distance of 10 has a higher
priority than a route with a distance of 100.

In this example, two sites are connected by a leased line (an MPLS link). For redundancy, you also have a BOVPN
virtual interface between the sites.

To make sure the BOVPN virtual interface is the secondary (backup) link between the two sites, specify a distance
with a higher number for the route. This means the BOVPN virtual interface route has lower priority than the MPLS
link. Firebox uses the MPLS link (the primary route) when it is available instead of the BOVPN virtual interface.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 236

 Branch Office VPN

If the MPLS link is not available, the primary route is either removed from the routing table or it is assigned a distance
with a higher number than the BOVPN virtual interface route. The Firebox then uses the route for the secondary
BOVPN virtual interface because it has the lowest route distance (which means it has higher priority). When the
MPLS route is available again, the Firebox automatically fails back to use the MPLS route because it has a lower
distance (which means it has higher priority).

Dynamic Routing
With a BOVPN virtual interface, you can enable dynamic routing between two sites over a secure VPN. With this
configuration, you do not have to manually add and maintain explicitly configured routes between all the private
networks at each site.

On the VPN Routes tab, you configure virtual IP addresses. Virtual IP addresses must not exist within any other
physical or BOVPN networks. In the dynamic routing configuration on the Firebox, you specify OSPF or BGP
commands to:
n Use the virtual IP addresses as the peer network IP addresses
n Configure which local networks each device propagates routes for

Network Security Essentials for Locally-Managed Fireboxes Study Guide 237

 Branch Office VPN

BOVPN and NAT

If the private IP addresses at two sites use the same or overlapping IP addresses, you can use NAT in the BOVPN
configuration to avoid IP address conflicts.

We do not recommend 1-to-1 NAT to resolve an issue with sites that have overlapping
IP addresses. 1-to-1 NAT introduces scalability and management challenges. Instead, we
recommend that you change the IP addressing on one of the sites so the IP addresses do not
overlap. To learn how to configure secondary networks for this purpose, go to the Secondary
Networks section of this guide. However, if you cannot reconfigure IP addressing because you
do not own one of the sites, you could consider 1-to-1 NAT to resolve the issue.

1-to-1 NAT over BOVPN

1-to-1 NAT is a form of network address translation. When you enable 1-to-1 NAT, the Firebox changes and routes all
incoming and outgoing packets sent from one range of addresses to a different range of addresses.

You might configure 1-to-1 NAT over BOVPN for these reasons:
n To hide the true subnet addresses from the remote peer
n To avoid IP address conflicts when the sites have subnets that overlap (recommended only when you do not
own the other site)

For example, Site A and Site B use the same subnet for their trusted networks, 10.0.200.0/24. To create a VPN
tunnel between these networks, you can use 1-to-1 NAT in the tunnel configuration to translate these addresses to
different subnets: 192.168.200.0/24 and 192.168.150.0/24.

Site A (headquarters) configuration:

n Local — 10.0.200.0/24
n Remote — 192.168.150.0/24
n 1:1 NAT — 192.168.200.0/24
n Direction — Bi-directional

This rewrites the 10.0.200.0/24 subnet to 192.168.200.0/24.

Site B (remote) configuration:

n Local — 10.0.200.0/24
n Remote — 192.168.200.0/24
n 1:1 NAT — 192.168.150.0/24
n Direction — Bi-directional

This rewrites the 10.0.200.0/24 subnet to 192.168.150.0/24. For example, a computer with the IP address
10.0.200.7 is part of the Site B network. Before traffic from this computer goes through the tunnel, the Firebox
rewrites the IP address to 192.168.150.7. The Firebox rewrites only the first three octets because of the /24 mask.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 238

 Branch Office VPN

With these configurations at both sites, 1-to-1 NAT occurs in both directions.

Dynamic NAT over BOVPN

With dynamic network address translation (DNAT), you can masquerade a subnet as a single host IP address. You
can only configure this for a uni-directional tunnel, which is a tunnel that has traffic in only one direction.

DNAT over BOVPN is most commonly used for connections to a remote network that you do not control, and the
admin of the remote network wants your connection to appear as a certain address. The administrator might do this
because the company does not allow other private subnets on their network or because the administrator wants to
track your network usage with a single IP address.

For example, your local network at site A is 10.0.1.0/24. The remote local network is 10.0.200.0/24. To make
your local network traffic appear as the IP address 5.5.5.5 on the remote network, specify these settings:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 239

 Branch Office VPN

BOVPN and Dynamic Public IP Addresses

One or both of your BOVPN gateway endpoints might use an interface with a dynamic public IP address. A dynamic
public IP address might change at any time, which can disrupt VPN communication.

For example, Site A connects to Site B through a BOVPN. At Site B, the firewall has an external interface with a
dynamic IP address. If the IP address changes at Site B, Site A no longer knows how to connect to Site B and must
wait for Site B to reconnect.

To make sure Site A can always connect to Site B, you can use one of these methods to specify a gateway ID:
n Specify a Fully Qualified Domain Name (FQDN) for a site with dynamic DNS
n Specify a text string that matches in both device configurations

FQDN and Dynamic DNS

If Site B uses a dynamic DNS service, you can specify an FQDN in the Site A configuration. A dynamic DNS service
makes sure that the IP address attached to the domain name changes when the ISP assigns a new IP address.

In the Site A gateway endpoint configuration, you specify an FQDN for the remote gateway ID. In our example, the
FQDN is test.example.com:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 240

 Branch Office VPN

Text String
In this example, Site B has a dynamic IP address but does not use dynamic DNS.

You can specify a different type of gateway ID in the Site A configuration. Rather than specify an FQDN as the
Domain Name, specify a text string that is not a resolvable domain name. You can specify any text string, but it must
be the same in the Site A and Site B configurations. In our example, the text string is testID. Keep the Attempt to
Resolve check box clear.

In this configuration, the site with the dynamic IP address (Site B) must initiate the tunnel.

For example, in the Site A configuration:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 241

 Branch Office VPN

Network Security Essentials for Locally-Managed Fireboxes Study Guide 242

 Branch Office VPN

In the Site B configuration, specify testID as the local gateway ID:

Network Security Essentials for Locally-Managed Fireboxes Study Guide 243

 Branch Office VPN

Network Security Essentials for Locally-Managed Fireboxes Study Guide 244

 Branch Office VPN

BOVPN Topologies
When you link multiple sites together with BOVPN tunnels, there are several different VPN topologies you could use.

Centralized (Hub and Spoke)

All VPN tunnels converge at one site (the hub). All other sites are spokes. The VPN builds from the remote sites back
to the hub device. The central location receives all data transferred between sites. If the central location receives
traffic that is not intended for a resource at the central location, the device at the central location redirects the traffic to
the tunnel for the correct destination. This is known as tunnel switching.

Decentralized (Full Mesh)

All sites communicate directly with each other without a hub device.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 245

 Branch Office VPN

Hybrid (Partial Mesh)

Some sites are interconnected directly to each other (a mesh configuration), while other sites connect to a central
location (hub and spoke).

Mobile VPN over BOVPN

In this example, a mobile VPN user generates traffic destined for Site B, which goes through the mobile VPN tunnel to
Site A. The Site A Firebox sends the traffic through the BOVPN tunnel to Site B.

When you configure a mobile VPN, you assign a virtual IP address pool to mobile VPN users. You must add BOVPN
tunnel routes from the virtual IP address pool subnet to the Site B networks.

For split tunnel, you must also add mobile VPN tunnel routes for the Site B networks.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 246

 Branch Office VPN

Troubleshoot BOVPN Tunnels

BOVPN tunnels require a reliable connection and the same VPN configuration settings on both VPN endpoints. A
network connectivity issue or configuration error can cause issues.

After you configure a new BOVPN tunnel, verify that it works:

n Send traffic through the tunnel
n Monitor the tunnel status

Send Traffic Through the Tunnel

Your Firebox negotiates a VPN tunnel only when traffic needs to use the tunnel. To test a new VPN tunnel, you must
try to send data to an IP address on the remote network. The VPN tunnel is usually not created until you attempt to
send data. The source and destination for the data you send must be allowed by the tunnel route configured for that
VPN.

For example, when you ping a device on the remote network, the ping fails if:
n The tunnel is down.
n The source or destination IP address is not allowed by the tunnel route in the VPN configuration.
n The remote device is offline or does not respond to a ping. However, if the remote device is offline or does not
respond to a ping, the ping traffic still brings the tunnel up.

Monitor the Tunnel Status

After you send traffic through the tunnel, check the status of configured BOVPN tunnels in Firebox System Manager.
To see information about the configured BOVPN gateways and tunnels, on the Front Panel tab, expand Branch
Office VPN Tunnels.

Expand a gateway or VPN interface to see statistics and other status information.

Expand a tunnel to see statistics and information for that tunnel.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 247

 Branch Office VPN

Troubleshoot Problems
To troubleshoot a BOVPN, we recommend that you focus on VPN settings, messages, and logs:

1. Verify that the VPN settings are the same on both devices.
For example, verify that the pre-shared keys, Phase 1, and Phase 2 settings are the same on both devices.
2. In the tunnel route settings for both devices, verify that the IP addresses and subnet masks are correct:
n The local IP address must match the IP address of a local host or network.
n The remote IP address must be the IP address of a host or private network on the remote VPN gateway.
n The tunnel routes on the two devices should look reversed when viewed side-by-side.
3. View VPN diagnostic messages.
4. Run the VPN diagnostic report.
5. Review the IKE log messages on each device during tunnel negotiation.

For a connection that completely times out, try to ping the external interface of the remote device to verify
connectivity. Make sure the remote device is configured to respond to pings. To enable a Firebox to respond to a ping
to the external interface, you must edit the ping policy to allow pings from the Any-External alias.

In any VPN negotiation, one gateway endpoint is the initiator, and the other is the responder.
The initiator sends proposed gateway and tunnel settings, and the responder accepts or rejects
them, based on comparison with locally configured settings. When you troubleshoot IKEv1 or
IKEv2 VPN negotiations, look at the VPN diagnostic messages and VPN Diagnostic Report on
the responder. The responder has information about the settings on both devices. For IKEv2,
we also recommend that you look at the VPN diagnostic messages and VPN Diagnostic Report
on the initiator.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 248

 Branch Office VPN

View VPN Diagnostic Messages

If the BOVPN tunnel cannot be established, WatchGuard System Manager shows a VPN diagnostic message for the
gateway:

You can also see this message in Firebox System Manager and Fireware Web UI.

VPN diagnostic messages can indicate a problem with the VPN tunnel or gateway configuration. VPN diagnostic
messages for a tunnel include the tunnel name and indicate the problem. VPN diagnostic messages related to a VPN
gateway refer to the gateway endpoint by number. For example, if a gateway has two gateway endpoint pairs, VPN
diagnostic messages refer to the first gateway endpoint as Endpoint 1, and the second as Endpoint 2. This naming
scheme is necessary for BOVPN failover because gateway endpoints function as interfaces for each gateway.

For gateways with backup endpoints, it is normal to see timeout messages for the backup (inactive) endpoints. Only
one gateway endpoint pair is active at a time.

VPN diagnostic messages can be errors or warnings.

n Errors — Indicate that the VPN failed because of a configuration or connection issue.
n Warnings — Indicate that a VPN is down because of an abnormal condition, such as Dead Peer Detection
(DPD) failure.

For example, if a VPN between two devices is configured with mismatched settings in the Phase 2 proposal, the VPN
diagnostics messages that appear in Firebox System Manager for the two devices are very different:

VPN diagnostic message on the initiator:

Received 'No Proposal Chosen' message. Check VPN IKE diagnostic log messages on the remote gateway
endpoint for more information.

VPN diagnostic message on the responder:

Received ESP encryption 3DES, expecting AES

Network Security Essentials for Locally-Managed Fireboxes Study Guide 249

 Branch Office VPN

The VPN diagnostic messages on the responder contain the most useful information for VPN troubleshooting. When
a VPN setting does not match, the responder does not tell the initiator which setting is expected. This is to make sure
that a remote device cannot learn about your VPN configuration by trial and error. The VPN diagnostic messages that
show which setting does not match only appear for the device that received and rejected the proposal.

To initiate or restart tunnel negotiations from one endpoint, send traffic through the tunnel (recommended) or rekey
the tunnel. A rekey is temporary and might not work as expected for third-party devices.

After you initiate or restart tunnel negotiations, look at error messages on the other gateway endpoint to see why the
tunnel negotiation failed.

View the VPN Diagnostic Report

Firebox System Manager and Fireware Web UI include a VPN Diagnostic Report that you can use for VPN
troubleshooting. When you run the VPN Diagnostic Report, the diagnostic log level temporarily increases to the
Information level for VPN IKE messages, so that any useful log messages can be captured in the report. Because the
VPN Diagnostic Report temporarily increases the log level, you do not need to change the log level yourself before
you run the report.

To see log messages about tunnel negotiation, the tunnel negotiation must occur during the short time frame that the
VPN Diagnostic Report runs.

To run the VPN diagnostic report, connect to the Firebox with Firebox System Manager, then, on the Front Panel
tab, right-click the gateway name. While a device at the remote end of the tunnel attempts to send traffic, select VPN
Diagnostic Report so that tunnel negotiation happens while the reports. It could take several tries to get useful log
messages when tunnel negotiation fails.

The report runs automatically for 20 seconds. To run the report again for a longer duration, change the Duration to 60
seconds. While a device at the remote end of the tunnel attempts to send traffic, click Start Report.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 250

 Branch Office VPN

The report shows the gateway and tunnel configuration, and information about the status of any active tunnels for the
selected gateway. The VPN Diagnostic Report has several sections.

The first section summarizes the report:

n Conclusion — Summarizes what was observed and lists any VPN diagnostic errors. This section might also
include suggestions of next steps to take to troubleshoot the VPN.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 251

 Branch Office VPN

The next two sections show the configured settings for the selected gateway and all tunnels that use it:
n Gateway Summary — Shows a summary of the gateway configuration, including the configuration of each
configured gateway endpoint
n Tunnel Summary — Shows a summary of the tunnel configuration for all tunnels that use the selected gateway

The last seven sections show run-time information based on the log message data collected when the report was run:
n Run-time Info (bvpn routes) — For a BOVPN virtual interface, shows the static and dynamic routes that use
the selected BOVPN virtual interface, and the distance for each route
n Run-time Info (gateway IKE_SA) — Shows the status of the IKE (Phase 1) security association for the
selected gateway
n Run-time Info (tunnel IPSEC_SA) — Shows the status of the IPSec tunnel (Phase 2) security association for
active tunnels that use the selected gateway
n Run-time Info (tunnel IPSec_SP) — Shows the status of the IPSec tunnel (Phase 2) security policy for active
tunnels that use the selected gateway
n Related Logs — Shows tunnel negotiation log messages, if a tunnel negotiation occurs during the time period
that you run the diagnostic report
n Address Pairs in Firewalld — Shows the address pairs and the traffic direction (IN, OUT, or BOTH)
n Policy Checker Result — Shows policy checker results for policies that manage traffic for each tunnel route

The VPN Diagnostic Report can help you see the status of tunnel negotiations, and help you determine what caused
the tunnel negotiations to fail. It is especially helpful if you have many BOVPN gateways, because it enables you to
focus on the specific gateway you want to troubleshoot.

View the IKE Log Messages

To troubleshoot a VPN tunnel, you can look at IKE log messages. These messages tell you what occurs during tunnel
negotiations. You can see IKE log messages in the VPN Diagnostic Report or in Traffic Monitor.

We recommend that you view log messages on the responder rather than on the initiator. Log
messages on the responder contain more useful information. When a VPN setting does not
match, the responder gives the initiator only basic information such as transform settings. The
responder does not tell the initiator the pre-shared key or tunnel routes. The log messages that
show which setting does not match only appear in the log file for the responder, which is the
device that received and rejected the proposal.

If you have several VPN gateways, you can filter the log messages by the gateway IP address to see only the log
messages for a specific gateway.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 252

 Branch Office VPN

iked is the Fireware daemon that handles Internet Key Exchange.

Each log message related to a branch office VPN tunnel has a header that shows the IP addresses of the local and
remote gateway. The format of the header is:

(local_gateway_ip<->remote_gateway_ip)

Where:

local_gateway_ip is the IP address of the local gateway

remote_gateway_ip is the IP address of the remote gateway

If your device sends log messages to Dimension or WatchGuard Cloud, you can use those tools
to filter log messages by gateway IP address.

Here are a few common log messages that can help you identify specific types of VPN problems. These messages
appear as red text in WatchGuard System Manager, Firebox System Manager, Fireware Web UI, and the VPN
diagnostic tool.

Retry Timeout
Indicates that the IP address of the remote gateway was not reachable. This might be because of network
connectivity problems, or because UDP 500 is not open.

Example log message:

2019-07-23 13:14:13 iked (203.0.113.20<->203.0.113.10)Drop negotiation to
peer 203.0.113.10:500 due to phase 1 retry timeout

Mismatched ID Settings
Indicates a problem with the ID specified in the gateway endpoint settings.

Example log message:

2019-07-23 13:22:17 iked (203.0.113.20<->203.0.113.10)WARNING: Mismatched ID
settings at peer 203.0.113.10:500 caused an authentication failure

Network Security Essentials for Locally-Managed Fireboxes Study Guide 253

 Branch Office VPN

No Proposal Chosen
Indicates a problem with mismatched settings in the Phase 1 or Phase 2 proposal. The receiving device
rejects the proposal, because a setting received from the remote device did not match what was expected
based on the local VPN configuration.

Example log message on initiating device:

2019-07-23 11:49:34 iked (203.0.113.20<->203.0.113.10)Received No Proposal
Chosen message from 203.0.113.10:500 for To_Device_A gateway

Example log message on receiving device:

2019-07-23 11:47:39 iked (203.0.113.10<->203.0.113.20)Sending NO_PROPOSAL_
CHOSEN message to 203.0.113.20:500

On the receiving device, log messages near the NO PROPOSAL CHOSEN log message can indicate why the
proposal was rejected. The log messages show which setting did not match.

Example log message for mismatched Phase 1 proposal on receiving device:

2019-07-23 12:29:15 iked (203.0.113.10<->203.0.113.20)Peer proposes phase
one encryption 3DES, expecting AES

Example log message for mismatched Phase 2 proposal on receiving device:

2019-07-23 13:11:04 iked (203.0.113.10<->203.0.113.20)Peer proposes phase 2
ESP authentication MD5-HMAC, expecting SHA1-HMAC

We recommend that you keep the default log level, which is Error. If you increase the log
level, this increases load on the Firebox. An increased log level also writes more data to your
log database, which could cause you to lose historical log data.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 254

 Additional Resources

Additional Resources
This guide provides a summary of the basic information covered in training classes, videos, and product
documentation. To increase your skills and knowledge, we recommend that you get hands-on practice with the
products and review other technical resources. This appendix provides a list of additional resources but you should
explore the product documentation for additional details beyond the suggested topics.

You can find Fireware Help in the WatchGuard Help Center.

To see the videos, log in to the Learning Center.

For a list of additional resources for each section of this guide, see:
n Firebox Setup and Management Additional Resources
n Logging, Monitoring, and Reporting Additional Resources
n ThreatSync Additional Resources
n Network Settings Additional Resources
n Firewall Policies Additional Resources
n Security Services Additional Resources
n Proxies and Proxy-Based Services Additional Resources
n Authentication Additional Resources
n Mobile VPN Additional Resources
n BOVPN Additional Resources

Network Security Essentials for Locally-Managed Fireboxes Study Guide 255

 Additional Resources

Firebox Setup and Management Additional

Resources
These Help Center resources below provide more information about topics covered in the Firebox Setup and
Management section of this guide.

Set Up a New Firebox

n About Factory-Default Settings
n Run the Web Setup Wizard
n Run the WSM Quick Setup Wizard
n Setup Wizard Default Policies and Settings
n Firebox Configuration Best Practices

Firebox Management Tools

n Administer the Firebox from Policy Manager
n About Fireware Web UI
n Fireware Command Line Interface Reference

Configuration Files and Backup Images

n Firebox Backup and Restore
n Firebox Upgrade, Downgrade, and Migration

Role-based Administration
n About Role-Based Administration
n Manage Users and Roles on Your Firebox
n About Predefined Roles

Feature Keys
n About Feature Keys

Upgrade a Firebox
n Firebox Upgrade, Downgrade, and Migration

Default Threat Protection

n Default Threat Protection
n About Blocked Ports
n About Blocked Sites

Network Security Essentials for Locally-Managed Fireboxes Study Guide 256

 Additional Resources

Global Settings
n Define Firebox Global Settings
n About Policies for Firebox-Generated Traffic
n Enable NTP and Configure NTP Servers

Policies Overview
n Add Policies to Your Configuration
n Setup Wizard Default Policies and Settings
n Create or Edit a Custom Policy Template

Network Security Essentials for Locally-Managed Fireboxes Study Guide 257

 Additional Resources

Logging, Monitoring, and Reporting Additional

Resources
These Help Center resources provide more information about topics covered in the Logging, Monitoring, and
Reporting section of this guide.

Logging and Notification

n About Firebox Logging and Reporting

Monitoring with Firebox System Manager

n Monitor your Firebox with Firebox System Manager (FSM)

Monitoring with Fireware Web UI

n Monitor your Firebox with Fireware Web UI

Firebox Visibility with WatchGuard Cloud

n Fireboxes and FireClusters in WatchGuard Cloud

Set Up Dimension for Firebox Logging

n Add a Dimension or WSM Log Server

Traffic Monitor and Logs

n Device Log Messages (Traffic Monitor)

Network Security Essentials for Locally-Managed Fireboxes Study Guide 258

 Additional Resources

Network Settings Additional Resources

These Help Center resources provide more information about topics covered in the Network Settings section of this
guide.

Network Routing Modes

n Routes and Routing
n Create a Network Bridge Configuration
n Add a Secondary Network IP Address
n About DNS on the Firebox

Interfaces
n About Network Modes and Interfaces
n Common Interface Settings

VLANs
n About Virtual Local Area Networks (VLANs)

Multi-WAN
n About Multi-WAN

NAT
n NAT (Network Address Translation)

Network Security Essentials for Locally-Managed Fireboxes Study Guide 259

 Additional Resources

Firewall Policies Additional Resources

These Help Center resources provide more information about topics covered in the Firewall Policies section of this
guide.

Policy Source and Destination

n About Policy Properties
n About Aliases
n Add Policies to Your Configuration

Management Policies
n Setup Wizard Default Policies and Settings

Limit Policy Scope

n Firebox Configuration Best Practices

Policy Precedence
n About Policy Precedence

Hidden Policies
n About Policies for Firebox-Generated Traffic

Policy Logging and Notification

n Configure Logging and Notification for a Policy
n Set Logging and Notification Preferences

Policy Schedules
n Create Schedules for Firebox Actions
n Set an Operating Schedule

Packet Filters and Proxy Policies

n About Policies
n About Proxy Policies and ALGs

Network Security Essentials for Locally-Managed Fireboxes Study Guide 260

 Additional Resources

Security Services Additional Resources

These Help Center resources provide more information about topics covered in the Security Services section of this
guide.

Security Services Overview

n Manage Security Services
n Subscription Service Update Server

Globally Configured Security Services

n About Botnet Detection

Intrusion Prevention Service

n About Intrusion Prevention Service
n Configure Intrusion Prevention

Application Control
n About Application Control
n Configure Application Control Actions

Network Security Essentials for Locally-Managed Fireboxes Study Guide 261

 Additional Resources

Proxies and Proxy-Based Services Additional

Resources
These Help Center resources provide more information about topics covered in the Proxies and Proxy-Based
Services section of this guide.

Proxies and Proxy Actions

n About Proxy Policies and ALGs
n About Proxy Actions
n About Rules and Rulesets

AntiVirus Scanning and Proxies

n Enable Gateway AntiVirus
n Configure Gateway AntiVirus Actions

APT Blocker
n About APT Blocker
n Configure APT Blocker
n Monitor APT Blocker Activity

HTTP Proxies
n About the HTTP-Proxy

HTTP-proxy and WebBlocker

n About WebBlocker
n Configure WebBlocker

HTTPS-proxy
n About the HTTPS-Proxy
n HTTPS-Proxy: Content Inspection
n Create a Certificate CSR
n Use Certificates with HTTPS Proxy Content Inspection

Content Actions and Routing Actions

n About Content Actions
n HTTP Content Action and Domain Name Rule Examples

Network Security Essentials for Locally-Managed Fireboxes Study Guide 262

 Additional Resources

Authentication Additional Resources

These Help Center resources provide more information about topics covered in the Authentication section of this
guide.

Authentication Servers
n Define a New User for Firebox Authentication
n Configure MFA for a Firebox
n Define or Remove Users or Groups
n Define a New User for Firebox Authentication

Users and Groups in Policies

n Use Users and Groups in Policies

Network Security Essentials for Locally-Managed Fireboxes Study Guide 263

 Additional Resources

Mobile VPN Additional Resources

These Help Center resources provide more information about topics covered in the Mobile VPN section of this guide.

Mobile VPN Introduction

n Mobile VPN Tunnels
n Select a Mobile VPN Type

Mobile VPN with IKEv2

n Mobile VPN with IKEv2

Mobile VPN with SSL

n Mobile VPN with SSL

Network Security Essentials for Locally-Managed Fireboxes Study Guide 264

 Additional Resources

BOVPN Additional Resources

These Help Center resources provide more information about topics covered in the Branch Office VPN section of this
guide.

BOVPN Introduction
n Manual Branch Office VPN Tunnels
n Managed Branch Office VPN Tunnels (WSM)

BOVPN Configuration
n Quick Start - Set Up a VPN Between Two Fireboxes
n Configure Manual BOVPN Gateways
n Configure Manual BOVPN Tunnels

BOVPN Virtual Interfaces

n BOVPN Virtual Interfaces

BOVPN and NAT

n BOVPN and Network Address Translation

Network Security Essentials for Locally-Managed Fireboxes Study Guide 265

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

About the Network Security Essentials for Locally-

Managed Fireboxes Exam
The Network Security Essentials for Locally-Mananaged Fireboxes exam tests your knowledge of basic networking
and how to configure, manage, and monitor a locally-managed WatchGuard Firebox. This exam is appropriate for
network administrators who have experience configuring and managing Firebox devices that run Fireware v12.11.2
or higher.

Key Concepts
To successfully complete the Network Security Essentials for Locally-Managed Fireboxes exam, you must
understand these key concepts:

Fireware Knowledge
n Firebox activation and initial setup
n Network configuration
n Policy and proxy configuration
n Subscription services configuration
n User authentication
n Device monitoring, logging, and reporting
n Branch office and mobile VPN configuration

General Network and Security Knowledge

n IPv4 networking concepts (subnets, DNS, TCP/IP, DHCP, NAT, static routing)
n General understanding of firewalls

Network Security Essentials for Locally-Managed Fireboxes Study Guide 266

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Exam Description
Content
60 multiple choice (select one option), multiple selection (select more than one option), true/false, and
matching questions.

Passing score
75% correct.

Time limit
Two hours.

Reference material
You cannot look at printed or online materials during the exam.

Test environment

This is a proctored exam, with two location testing options:

n Onsite, at a Kryterion testing center

n Online, with a Kryterion online proctor

Prerequisites
The Network Security Essentials for Locally-Managed Fireboxes video course and attendance at an instructor-
led lab class is recommended, but not required.

Prepare for the Exam

WatchGuard provides training and online courseware to help you prepare for the Network Security Essentials exam.
In addition to this study guide, and the training and courseware described below, we strongly recommend that you
install, deploy, and manage one or more Firebox devices that run Fireware v12.11.2 or higher before you begin the
exam.

Instructor-Led Training
To get hands-on experience, we recommend that you attend an instructor-led training class. Classes are often held
in-region, sponsored by sales or a local WatchGuard distributor. We also offer complimentary VILT technology-based
lab training classes for partners. WatchGuard end-users can register for instructor-led training with our network of
WatchGuard Certified Training Partners (WCTPs).
n Partners — Register for training in the WatchGuard Learning Center (login required)
n End-users — View the current WCTP training schedule on the WatchGuard website

Network Security Essentials for Locally-Managed Fireboxes Study Guide 267

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Self-Study Course (Video)

WatchGuard offers video-based courseware that you can use for self-study, or to reinforce instructor-led training. To
prepare for this exam, review the Network Security Essentials course available in the WatchGuard Learning Center
(login required).

Assessment Objectives
The Network Security Essentials Exam evaluates your knowledge of the categories in the list below. For each
knowledge category, the Weight column includes the approximate percentage of exam questions from that
knowledge category. Because some exam questions require skills or knowledge from more than one category, the
weights do not exactly correspond to the percentage of exam questions.

Category Knowledge Areas Weight

Network and Understand basic networking concepts that are not unique to the Firebox. 12%
Network Security
Basics
n IPv4 addresses, subnetting, and routing
n Network Address Translation
n Packet headers (TCP, IP, HTTP)
n MAC addresses
n Network services, ports, and protocols

Administration and Understand how to set up a Firebox with a basic configuration, and 18%
Initial Setup complete basic Firebox administration tasks.
n Firebox default policies and network settings
n Fireware Web Setup Wizard
n Feature keys
n Firebox backup and restore
n Configuration file migration
n Default Threat Protection

Monitoring, Understand how to use management tools to monitor or troubleshoot a 17%

Logging, Firebox.
Reporting, &
ThreatSync
n Tools to monitor Firebox status and activity
n Diagnostic tools in Firebox System Manager
n Firebox logging to Dimension or WatchGuard Cloud
n Firebox log messages
n Logging settings

Networking and Understand how to configure Firebox network settings and NAT. 20%
NAT
n Network interface types, security zones, and settings
n WINS/DNS

Network Security Essentials for Locally-Managed Fireboxes Study Guide 268

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Category Knowledge Areas Weight

n Routing and static routes

n NAT types and configuration
n DHCP
n VLANs
n Multi-WAN

Policies, Proxies, Understand how to configure Firebox policies, proxies, and security 18%
and Security services.
Services
n Packet filter policies and proxy policies
n Policy precedence
n HTTP-proxy
n HTTPS-proxy content inspection
n Content actions and domain name rules
n Fireware subscription security services

Authentication and Understand user authentication and VPN settings on the Firebox. 15%
VPNs
n Authentication servers
n Users and groups in policies
n Mobile VPN routing options and protocols
n Branch Office VPN gateways and tunnel routes
n Branch Office VPN and NAT
n BOVPN virtual interfaces

Network Security Essentials for Locally-Managed Fireboxes Study Guide 269

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Sample Exam Questions

The Network Security Essentials exam includes multiple choice, multiple selection, true/false, and matching
questions. This section provides examples of the types of questions to expect on the exam. Answers to each question
appear at the end of each section.

Network and Network Security Basics

Questions
1. What port and protocol is used by DNS? (Select one.)
a. UDP/67
b. UDP/53
c. TCP/20
d. TCP/25

2. Based on this network diagram, which of these static routes could you add to the Firebox to enable the Firebox
to route traffic from clients on the 192.168.10.0/24 subnet to a server at 10.0.20.80? (Select two.)

a. Route to 10.0.20.0, Gateway 10.0.2.1

b. Route to 10.0.20.80, Gateway 192.168.10.5
c. Route to 192.168.10.5, Gateway 192.168.10.1
d. Route to 10.0.20.0/24, Gateway 192.168.10.5

Network Security Essentials for Locally-Managed Fireboxes Study Guide 270

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

3. Symmetric encryption is the only secure way to establish an encrypted connection to a web server.
a. True
b. False
4. A packet filter policy works at the application, network, and transport layers to examine connection data.
a. True
b. False
5. Which of these is a Class C subnet mask? (Select one.)
a. /8
b. /12
c. /16
d. /24
e. /28
6. How many usable host IP addresses are on a network with a /28 CIDR subnet mask? (Select one.)
a. 14
b. 16
c. 30
d. 32
e. 254
7. What type of encryption is used during the initial setup of an HTTPS connection? (Select one.)
a. Asymmetric encryption
b. Symmetric encryption
c. Block cipher encryption
d. IPSec encryption
e. SSL encryption

Answers
Note: Many exam questions test knowledge in more than one area.

1. b. DNS uses UDP port 53.

2. b and d. You can configure a static route to the specific server, or to the entire subnet it is on. In either case, the
gateway is the IP address of the router that connects to that network, and the gateway must be reachable by
the firewall.
3. b. False. Asymmetric encryption is also used to establish an encrypted connection to a web server.
4. b. False. Layer 7 is the application layer and not examined by packet filters.
5. d. /24 is a Class C subnet mask.
6. a. There are 14 usable host IP addresses on a network with a /28 CIDR subnet mask.
7. a. Asymmetric encryption is used during the initial setup of an HTTPS connection.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 271

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Administration and Initial Setup

Questions
1. On the WatchGuard Product and Support blog, you see that a new version of Fireware was recently released.
How do you know if your Firebox is running the latest version of Fireware? (Select three.)
a. You don’t need to check because you enabled Automatic Fireware Upgrades in WatchGuard Cloud
and your Firebox is connected to WatchGuard Cloud.
b. Connect to Fireware Web UI and look at the Dashboard > Front Panel.
c. From Fireware Web UI, select System > Upgrade OS to see if a new version of Fireware is available.
d. Go to the WatchGuard Software Downloads Center and select your Firebox from the Firebox drop-
down list.
e. Connect your Firebox to WatchGuard Cloud and look in Devices > Firmware Upgrades section for
your Firebox to see if upgrades are available.
2. Which of these types of threats can the Firebox prevent with the Default Packet Handling settings? (Select
four.)
a. Flood attacks
b. KRACK attack
c. IP spoofing
d. Denial of service attacks
e. Man-in-the-middle attack
f. Port scans
g. SQL injection
3. When a site is Auto-Blocked by Default Threat Protection, which of these statements are true? (Select two.)
a. All traffic to the site is blocked.
b. All traffic from the site is blocked.
c. The site is permanently on the Blocked Sites list.
d. The site is temporarily on the Blocked Sites list.
4. When your users connect to the Authentication Portal page to authenticate, they see a security warning
message, which they must accept before they can authenticate. How can you make sure users do not see this
security warning message in their browsers? (Select two.)
a. Replace the Firebox proxy server certificate with the trusted certificate from your web server.
b. Import a web server certificate signed by a trusted certificate authority to the Firebox and select it as
the Firebox web server certificate.
c. Instruct users to disable security warning messages in their preferred browsers.
d. Create a custom self-signed web server certificate on the Firebox and export it, then import it to all
client computers or web browsers.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 272

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Answers
1. b ,c ,e
2. a, c, d, f. The Firebox can prevent Flood attacks, IP spoofing, Port scans, and Denial of service attacks with
Default Packet Handling settings.
3. b, d. When a site is Auto-Blocked by Default Threat Protection, all traffic from the site is blocked and the site is
temporarily on the Blocked Sites list.
4. b, d

Logging, Monitoring, Reporting, and ThreatSync

Questions
1. From the Firebox System Manager Authentication List tab, you can see all the authenticated users connected
to your Firebox and log them out.
a. True
b. False
2. What information can you find in the Firebox System Manager Status Report? (Select three.)
a. Authenticated users
b. Process list
c. Blocked sites
d. IPv4 routing table
e. Domain name servers
f. Interface bandwidth
3. Where can you see how many intrusions IPS has prevented? (Select one.)
a. Traffic Monitor tab in Firebox System Manager
b. Subscription Services settings in Policy Manager
c. Subscription Services dashboard in Fireware Web UI or Subscription Services tab in Firebox System
Manager
d. Front Panel in Fireware Web UI
e. FireWatch in Fireware Web UI

Answers
1. a. True. From the Firebox System Manager Authentication List tab, you can see all the authenticated users
connected to your Firebox and log them out.
2. b, d, e. From the Firebox System Manager Status Report, you can find the Process list, IPv4 routing table, and
domain name servers.
3. c. You can see how many intrustions IPS has prevented in Subscription Services dashboard in Fireware Web
UI or the Subscription Services tab in Firebox System Manager.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 273

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Networking and NAT

Questions
1. You can configure Dynamic NAT to route incoming connections from the Internet to two different FTP servers
on the trusted network.
a. True
b. False
2. Which of these are valid VLAN configurations on the Firebox? (Select three.)
a. VLAN tagging can be applied to a mobile VPN virtual pool.
b. Two interfaces can send and receive untagged traffic for one VLAN.
c. An interface can send and receive tagged traffic for two VLANs.
d. An interface must have an untagged VLAN.
e. An interface can send and receive untagged traffic for one VLAN and tagged traffic for a different
VLAN.
3. In the diagram below, network hosts are not configured with a VLAN ID. How do you configure the circled ports
on the switch so that network hosts connect to the correct VLAN? (Select two.)

a. Configure port 7 as VLAN 10 tagged.

b. Configure port 7 as VLAN 10 untagged.
c. Configure port 7 without a VLAN.
d. Configure port 9 as VLAN 20 tagged.
e. Configure port 9 as VLAN 20 untagged.
4. You can configure the Advanced settings of any outbound policy to override the global Dynamic NAT
configuration.
a. True
b. False

Answers
1. b. False. Dynamic NAT applies only to outgoing connections.
2. b, c, e

Network Security Essentials for Locally-Managed Fireboxes Study Guide 274

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

3. b, e. Ports to client computers should always use untagged VLANs.

4. a. True. You can configure the Advanced settings of any outbound policy to override the global Dynamic NAT
configuration.

Policies, Proxies, and Security Services

Questions
1. From the policies shown in this image, can users in the Sales group connect from the trusted network to
websites with HTTPS? (Select one.)

a. No. The HTTPS-proxy policy only allows HTTPS traffic for the Accounting group.
b. No. The Outgoing policy does not allow any traffic from the Sales group.
c. Yes. The HTTP policy allows HTTP and HTTPS traffic for the Sales group.
d. Yes. The Outgoing policy allows HTTPS traffic from the trusted network.
2. If you disable the Outgoing policy, which protocols must be allowed to enable users behind the Firebox to
connect to commonly used websites? (Select three.)
a. HTTP
b. HTTPS
c. DNS
d. FTP
e. DHCP
3. Automatic signature updates for subscription services fail if the Firebox cannot contact a DNS server.
a. True
b. False
4. Which WatchGuard subscription service must you enable in a proxy policy before you can use APT Blocker?
(Select one.)
a. WebBlocker
b. Intrusion Prevention Service
c. Gateway AntiVirus
d. Application Control
e. IntelligentAV

Network Security Essentials for Locally-Managed Fireboxes Study Guide 275

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

5. Which firewall policies can use the Intrusion Prevention Service to block network attacks? (Select one.)
a. Only packet filter policies
b. Only HTTP and HTTPS proxy policies
c. Only proxy policies
d. Only inbound policies
e. All policies
6. An antivirus update site is hosted on a content delivery network with an IP address that changes dynamically.
The antivirus clients use HTTP to get updates. What type of policy can you configure to allow computers on
your local network to contact the signature update server? (Select one.)
a. Disable the Outgoing policy, then add an HTTPS policy to allow encrypted requests from the IP range
of the computers to the IP addresses of the antivirus update site.
b. Add a policy to allow outbound DNS on port 53 to the host name of the antivirus update site.
c. Add an HTTP policy to allow outbound requests from the IP range of the computers to the wildcard
FQDN of the antivirus update site.
d. Add an HTTP policy that allows access from the IP range of the computers to a Guest subnet.
7. When you create a new packet filter policy that allows traffic through the firewall, by default the policy
generates log messages for allowed traffic.
a. True
b. False
8. What must you configure for an HTTPS-proxy policy to detect known viruses in HTTP traffic that is encrypted
with TLS? (Select two.)
a. Enable the Intrusion Prevention Service.
b. Enable Content Inspection.
c. Configure the HTTP Header Fields action to AV scan.
d. In the HTTPS proxy > TLS Profile settings, select the Allow only TLS-compliant traffic option.
e. Enable Gateway AntiVirus.

Answers
1. d. Yes, the Outgoing policy allows this traffic.
2. a, b, c. If you disable the Outgoing policy, to enable users behind the Firebox to connect to commonly used
websites, you must allow HTTP, HTTPS, and DNS protocols.
3. a. True. Automatic signature updates for subscription services fail if the Firebox cannot contact a DNS server.
4. c. You must enable the Gateway AntiVirus subscription service in a proxy policy before you can use
APT Blocker.
5. e. All firewall policies can use the Intrusion Prevention Service to block network attacks.
6. c. Add an HTTP policy to allow outbound requests from the IP range of the computers to the wildcard FQDN of
the antivirus update site.
7. b. False
8. b, e. For an HTTPS-proxy policy to detect known viruses in HTTP traffic that is encrypted with TLS, you must
Enable Content Inspection and Enable Gateway AntiVirus.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 276

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

Authentication and VPN

Questions
1. What is the purpose of the WatchGuard Authentication policy? (Select one.)
a. Allows management users to authenticate to Fireware Web UI
b. Allows branch office VPN connections between two Fireboxes
c. Allows user connections to the Firebox Authentication Portal
d. Allows Mobile VPN users to authenticate to the Firebox
2. While troubleshooting a branch office VPN tunnel, you see the log message below. What settings could you
modify in the local device configuration to resolve the configuration issue? (Select one.)
iked (203.0.113.50<->203.0.113.20)IKE phase-2 negotiation from 203.0.113.50:500
to 203.0.113.20:500 failed. Tunnel='tunnel.1' Reason=Received proposal without
PFS, Expecting PFS enabled id="0205-0002" Debug
a. BOVPN Gateway settings
b. BOVPN Tunnel settings
c. BOVPN over TLS settings
d. IKEv2 Shared settings
3. You want the fastest and most secure mobile VPN solution for Windows and macOS, but do not want to install
a client. Which of these solutions do you choose? (Select one.)
a. IPSec
b. SSL/TLS
c. IKEv2
d. L2TP
e. SSTP
4. You can use any authentication server with any supported type of Mobile VPN.
a. True
b. False
5. Which option is the most secure method to allow remote users to connect to resources on your private
network? (Select one.)
a. RDP
b. VPN
c. Static NAT
d. Proxy
6. Mobile VPN with SSL is the only VPN type that requires an application to be installed on all client devices in
order to establish a connection to the Firebox. (Select one.)
a. True
b. False

Network Security Essentials for Locally-Managed Fireboxes Study Guide 277

 About the Network Security Essentials for Locally-Managed Fireboxes Exam

7. You configured multiple external interfaces on your Firebox and a BOVPN virtual interface to a remote site.
How can you configure the local Firebox to fail over the BOVPN virtual interface to a backup external interface
when the primary external interface goes down? (Select one.)
a. In the BOVPN-Allow policies, enable an SD-WAN action that includes both external interfaces.
b. In Firebox Routes, add a new static route for the backup external interface.
c. In the BOVPN-Allow.out policy, add the backup external interface alias to the To field.
d. In the BOVPN Virtual Interface settings, add the backup external interface to the Gateway Endpoints
list.
e. In the Multi-WAN failover configuration, select the BOVPN virtual interface.

Answers
1. c. The WatchGuard Authentication policy allows users to connect to the Authentication Portal from the trusted
or optional networks.
2. b. Phase 2 authentication is configured in the BOVPN Tunnel settings.
3. c. IKEv2
4. b. False
5. b. VPN is the most secure method to allow remote users to connect to resources on your private network.
6. a. True. Mobile VPN with SSL is the only VPN type that requires an application to be installed on all client
devices in order to establish a connection to the Firebox.
7. d. In the BOVPN Virtual Interface settings, add the backup external interface to the Gateway Endpoints list.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 278