Network Security Essentials Study Guide

Training
Network Security Essentials

Study Guide
WatchGuard Fireboxes
Guide Revised For: Fireware v12.7

Revision Date: June 2021
2 WatchGuard Technologies, Inc.
About This Guide
The Network Security Essentials Study Guide is a guide to help you study for the Network Security Essentials
certification exam.
Information in this guide is subject to change without notice. Companies, names, and data used in examples herein are
fictitious unless otherwise noted. No part of this guide 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: 6/14/2021
Disclaimer
Information in this guide is subject to change without notice. Companies, names, and data used in examples herein are
fictitious unless otherwise noted. No part of this guide 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.
Copyright and Patent Information

Copyright © 2021 WatchGuard Technologies, Inc. All rights reserved.
WatchGuard, Firebox, Fireware, LiveSecurity, and spamBlocker are either registered trademarks or trademarks of in the
United States and other countries. This product is covered by one or more pending patent applications.
All other trademarks and trade names are the property of their respective owners.
Complete copyright, trademark, and licensing information can be found in the Copyright and Licensing Guide, available
online at http://www.watchguard.com/help/documentation/.
Printed in the United States.
Address
About WatchGuard
505 Fifth Avenue South
WatchGuard® Technologies, Inc. is a global leader in network security, Suite 500
providing best-in-class Unified Threat Management, Next Generation Seattle, WA 98104
Firewall, secure Wi-Fi, and network intelligence products and services
to more than 75,000 customers worldwide. The company’s mission is
to make enterprise-grade security accessible to companies of all types Support
and sizes through simplicity, making WatchGuard an ideal solution for
Distributed Enterprises and SMBs. WatchGuard is headquartered in www.watchguard.com/support
Seattle, Washington, with offices throughout North America, Europe, U.S. and Canada +877.232.3531
Asia Pacific, and Latin America. To learn more, visit WatchGuard.com. All Other Countries +1.206.521.3575
For additional information, promotions and updates, follow WatchGuard
on Twitter, @WatchGuard on Facebook, or on the LinkedIn Company
page. Also, visit our InfoSec blog, Secplicity, for real-time information Sales
about the latest threats and how to cope with them at
www.secplicity.org. U.S. and Canada +1.800.734.9905
All Other Countries +1.206.613.0895
Network Security Essentials Study Guide 3

How to Use This Study Guide 8
Firebox Setup and Management 10
Set Up a New Firebox 11
Firebox Management Tools 17
Configuration Files and Backup Images 19
Role-based Administration 23
Feature Keys 25
Upgrade a Firebox 28
Default Threat Protection 30
Global Settings and NTP 34
Policies Introduction 37
Logging and Monitoring 41
Logging and Notification 42
Types of Log Messages 44
Firebox Visibility with WatchGuard Cloud 47
Set Up Dimension for Firebox Logging 49
Configure Firebox Logging to Dimension 50
Monitoring with Firebox System Manager 51
Monitoring with Fireware Web UI 55
Read Traffic Log Messages in Traffic Monitor 58
Network Settings 60
Network Routing Modes 61
Interfaces 63
WINS/DNS in Mixed Routing Mode 67
Network Bridges 68
Secondary Networks 71
VLANS 73
Static Routing 80
Multi-WAN 82
Multi-WAN Failover 89
Multi-WAN Interface Overflow 91

Multi-WAN Round Robin 93
Multi-WAN Routing Table 97
Link Monitor 99
Routing Decisions Logic 103
Software-Defined WAN (SD-WAN) 108
Dynamic NAT 112
Static NAT (SNAT) 115
1-to-1 NAT 117
NAT Loopback 120
Traffic Management 122
Quality of Service (QoS) 129
Firewall Policies 132
Policy Source and Destination 133
Management Policies 136
Limit Policy Scope 137
Policy Precedence 139
Hidden Policies 141
Policy Logging and Notification 143
Policy Schedules 146
Packet Filters and Proxy Policies 147
Security Services 150
Security Services Overview 151
Globally Configured Security Services 155
Intrusion Prevention Service 157
Application Control 159
Geolocation 163
Proxies and Proxy-Based Services 165
Proxies and Proxy Actions 166
AntiVirus Scanning and Proxies 169
APT Blocker 174
SMTP-proxy Policies 179
spamBlocker 181

HTTP-proxy Policies and Proxy Actions 184
WebBlocker and the HTTP and HTTPS Proxies 192
HTTPS-proxy Policies 195
Content Actions and Routing Actions 204
Authentication 208
Authentication Servers 209
Firebox Authentication 210
AuthPoint Authentication Server 214
Third-Party Authentication Servers 216
LDAP Authentication Servers 218
Active Directory Authentication Servers 220
RADIUS Authentication Servers 224
SecurID Authentication Servers 226
Users and Groups in Policies 227
Mobile VPN 230
Mobile VPN Introduction 231
Select a Mobile VPN Type 233
Mobile VPN with IKEv2 236
Mobile VPN with L2TP 237
Mobile VPN with SSL 239
Setup Overview 241
Client Configuration Files 244
Mobile VPN Routing Options 246
Branch Office VPN 248
BOVPN Introduction 249
Topology 250
Fireware BOVPN Types 251
IPSec VPN Algorithms and Protocols 254
Policies and VPN Traffic 259
VPN Negotiations 261
BOVPN Configuration 265
BOVPN Virtual Interface Configuration 274

BOVPN and NAT 279
BOVPN and Dynamic Public IP Addresses 281
BOVPN over TLS 286
BOVPN Topologies 287
Troubleshoot BOVPN Tunnels 289
Additional Resources 297
Firebox Setup and Management Additional Resources 298
Logging and Monitoring Additional Resources 301
Network Settings Additional Resources 303
Firewall Policies Additional Resources 306
Security Services Additional Resources 308
Proxies and Proxy-Based Services Additional Resources 310
Authentication Additional Resources 313
Mobile VPN Additional Resources 314
BOVPN Additional Resources 315
About the Network Security Essentials Exam 317
Exam Description 318
Sample Exam Questions 322

How to Use This Study Guide

This guide covers the Fireware Essentials section of the Network Security Essentials course and is a resource to help
you study for the Network Security Essentials 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.
If you are unfamiliar with basic concepts of networking and network security, we recommend that you also complete the
Network Basics and Network Security Basics sections of the Network Security Essentials course, available in the
WatchGuard Learning Center.
For a list of recommended documentation and video resources to help you prepare for the exam, see Additional
Resources.
For information about the exam content and format, see About the Network Security Essentials 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.

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.

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 management tools
n Firebox configuration files and backup images
n Feature keys
n Fireware OS upgrades
n Default Threat Protection
n Global settings, NTP, and SNMP
n Firewall policy basics
For a list of additional resources on these topics, see Firebox Setup and Management Additional Resources.

Set Up a New Firebox

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.
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
www.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://login.watchguard.com/AccountManager/Login/StartRegistration.
n The Firebox serial number
After you activate your Firebox, copy and paste the feature key to a local file.

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

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.

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 New Configuration.
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.

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 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 Reputation Enabled Defense
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.
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.

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 www.watchguard.com/support and click Download Software.

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.
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.

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

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.

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 both Policy Manager and Fireware Web UI to save a backup image of your Firebox.
n Policy Manager — File > Backup and Restore

n Fireware Web UI — System > Backup and Restore Image
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 watchguard.com. Backup images remain on the Firebox until
they are deleted manually or the Firebox is reset to factory-default settings.

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.

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
wg-support Disabled
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

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 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.

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.

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.

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

Upgrade a Firebox
To keep your Firebox up to date with the latest security features, you must periodically upgrade Fireware OS.
There are two 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
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.
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.

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.

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:

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.
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.

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.

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.

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.

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.

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, and you use Reputation Enabled Defense to deny
connections to sites with a bad reputation. 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.

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.

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.

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.

Logging and Monitoring

The Firebox can generate log messages and notifications to help you monitor network activity.
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, see Logging and Monitoring Additional Resources.

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).

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.

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.

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.

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.

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.

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.
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 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 to paste
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.

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.

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.

Monitoring with Firebox System Manager

With Firebox System Manager (FSM), you can quickly see the status of a single Firebox. This helps you to identify
unusual activity and take immediate action.
Firebox System Manager Front Panel tab
In 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
tools to help diagnose problems with the traffic on your network.

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.
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.

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, APT Blocker,
Geolocation, Data Loss Prevention, Reputation Enabled Defense, and File Exceptions.
From here, you can also 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.

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, see Troubleshoot
BOVPN Tunnels

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.

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, Application
Services Control, spamBlocker, WebBlocker, Botnet Detection, APT Blocker, Geolocation, Data Loss
Prevention, Reputation Enabled Defense, 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 your
Discovery Firebox. You can see detailed information for each connected device.

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 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)

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.
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.
Log messages show which policies allow or deny traffic through the firewall. This traffic log message shows information
for an allowed packet:
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 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 SD-WAN
n Static routing
n Dynamic NAT
n Static NAT
n 1-to-1 NAT
n Traffic management
For a list of additional resources on these topics, see Network Settings Additional Resources.

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 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 network All the Firebox interfaces are on the same network. You
and have the same IP address. specify an IP address to use to manage the Firebox.
The computers on the trusted or optional interfaces Traffic from all trusted or optional interfaces is examined
can have a public IP address. NAT is not and sent to the external interface. You can specify a
necessary. 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 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 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 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 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 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 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 Settings
The interfaces Trusted-1 and Trusted-2 are part of the bridge configuration.

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 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.
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:

Network Settings
n You inherit a network that uses the 192.168.0.1/24 or 192.168.1.1/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.

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.
A VLAN allows you to 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 needed 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 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 will accept both tagged and untagged
data frames, but only for VLANs in the trusted, optional, and custom security zones. For an external VLAN, a
device VLAN interface will accept only tagged data frames.
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 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 Each VLAN interface can send and received untagged traffic for only one trusted, optional, or custom VLAN. For
example, if a VLAN interface is configured to send and receive untagged traffic for VLAN-10, it cannot also send
and receive untagged VLAN traffic for any other VLAN at the same time. Also, a VLAN interface cannot be
configured to send and receive untagged traffic for an external VLAN.
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 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 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:
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.
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.

Network Settings
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.
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 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 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 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 — The metric 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 metric.
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 metric to
control the priority of each route. If you use dynamic routing, the dynamic routing protocol automatically sets the metric
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 Settings
Multi-WAN
With multi-WAN, you can configure multiple external interfaces, each on a different subnet. This
allows 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 unless you configure software-
defined WAN (SD-WAN).
By default, multi-WAN is not enabled for modems. Multi-WAN does not impact BOVPNs or inbound traffic.
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.
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 more information, see the Equal-Cost Multi-Path Routing (ECMP) and Routing Table sections.
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.
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.
When you enable multi-WAN, by default, Link Monitor is not enabled.

Network Settings
Multi-WAN Benefits
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 when you
configure SD-WAN or BOVPN gateways.
Terms and Concepts

To configure a Firebox for multi-WAN, you should be familiar with these terms and concepts.
Outgoing Traffic and Multi-WAN

In Fireware, you can configure multiple Firebox interfaces as type External. Because each external interface must have
a default gateway, each external interface provides a path that the Fireware can use to send traffic to external
destinations.
For every connection that starts in a network behind the Firebox and goes to an external destination, the Firebox must
decide which external interface to use to send the traffic. Several factors determine whether the Firebox allows an
outgoing connection, and which external interface the Firebox uses for allowed traffic:
n Firewall policies that allow and deny traffic

n Multi-WAN method
n Static and dynamic routes in the Firebox routing table
n Which external interfaces are currently able to send traffic
n Per-policy settings that can override the multi-WAN method you use (SD-WAN and sticky connections)
n BOVPN gateway endpoint settings
The Routing Decisions Logic section of this guide includes a flow chart that shows how the Firebox makes these
decisions.
Incoming Traffic
For incoming connections, the decision process is simpler. An incoming connection is allowed only if a firewall policy
allows it.
Any external interface can receive traffic if the Firebox sees that the interface is active.

Network Settings
The multi-WAN method you use does not affect the path that incoming traffic takes to get to your Firebox. Because the
Firebox cannot control which external interface an incoming connection arrives on, this guide does not discuss incoming
connections.
IPSec VPN Traffic

IPSec VPN traffic refers to traffic sent over a BOVPN connection. The multi-WAN concepts in this guide apply only to
non-IPSec traffic. The methods that Fireware uses to route normal (non-IPSec) traffic to external networks are distinct
and separate from the way traffic is sent to the remote side of an IPSec VPN. When the Firebox sends traffic to the
other side of a VPN tunnel, it selects from the interfaces specified in the gateway settings for that tunnel. Multiple
external interfaces for IPSec VPNs are covered in a separate section.
Equal-Cost Multi-Path Routing (ECMP)

ECMP is an algorithm for routing packets to destinations when there are multiple next-hop paths of equal cost. The
Routing Table multi-WAN method uses ECMP to evenly distribute outgoing traffic across multiple external interfaces
based on source and destination IP addresses.
A routing table is a collection of data about destinations in a network and how to reach them. Fireware always consults
the Firebox routing table, regardless of the multi-WAN method. Because of this, ECMP does not interfere with static
routes you configure on the Firebox, or with dynamic routing protocols such as RIP, OSPF, and BGP.
An ECMP group is the group of external interfaces used for ECMP calculations. When the Firebox determines that an
external interface in the ECMP group can no longer forward traffic to external networks, it removes that interface from
the ECMP group. Fireware puts the external interface back into the ECMP group when it determines that the interface is
available again.
Sticky Connections
Dynamic NAT changes the source IP address of an outgoing connection to match the IP address on the external
interface the Firebox uses to send the connection. You use sticky connections to make sure that when an outgoing
traffic flow is established, all connections between the inside user’s IP address and the external site’s IP address use
the same external interface for a certain amount of time.
Fireware keeps a dynamic table of sticky connections that includes the source/destination pair for each outgoing
connection, the external interface used for the connection, and the age of the connection. If a new connection between
the pair happens before the sticky connection timeout, the age is reset to zero. When the age of an entry reaches the
sticky connection limit, the entry is deleted from the sticky connections table. New connections between the two IP
addresses can use a different external interface.
You can configure the sticky connection interval for the Round-robin or Interface Overflow multi-WAN methods.
You cannot use sticky connection options when:
n You use the Failover or Routing Table multi-WAN methods.

n You enable SD-WAN for a policy.

Network Settings
Global Sticky Connection Settings

You configure the global sticky connection settings in the multi-WAN settings.
We recommend you use the default settings for sticky connections. The three-minute timeout
prevents most problems that arise when the source IP address of new traffic from behind the
Firebox changes.
Policy-Based Sticky Connection Settings

For any policy, you can override the global sticky connection settings configured in the multi-WAN settings. Policy-
based sticky connection settings specify that outgoing traffic that uses the policy has a shorter or longer sticky
connection setting than the global sticky connection setting. You can also disable sticky connections for a policy.
Some applications drop a client’s connection if the client’s source IP address changes. The most common example is
when a user is on a website that uses HTTPS. Some HTTPS sites use a session cookie that includes the user’s source
IP address. If the user is on the site and the browser attempts a new connection (for example, a new GET or POST
request to the site causes a new TCP session), the site might deny the new connection if the source IP address does
not match what is in the session cookie.
If users report that they need to frequently re-authenticate to sites that use HTTPS, you can configure a higher sticky
timeout for the policy that allows outbound HTTPS traffic.
You might also want to configure a higher sticky timeout setting for Voice Over IP (VoIP) and video conferencing traffic
for a better user experience.

Network Settings
If you do not use a specific HTTPS policy in your Firebox configuration (for example, you have a policy that allows
outbound connections over any TCP port), you can add a policy that allows only port 443 traffic. You can then adjust the
sticky connection timeout in this policy without affecting other connections.
Exclude Interfaces from multi-WAN

In certain cases, you might want to dedicate some Firebox interfaces to BOVPN, mobile VPN, or policies that use SD-
WAN. You can include or exclude interfaces from multi-WAN. However, all multi-WAN methods except Routing Table
must include at least two interfaces.

Network Settings
SD-WAN
When you specify an SD-WAN action in a policy, the Firebox routes traffic that matches the policy to interfaces
specified in the SD-WAN action. SD-WAN takes precedence over the routing decision that Fireware would otherwise
apply based on the multi-WAN method or route table.
You can use SD-WAN to route traffic for a policy through an external interface, internal interface, or BOVPN virtual
interface.
For more information about SD-WAN, see Software-Defined WAN (SD-WAN).
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:
n Round-robin — The Firebox removes the failed interface from the Round-robin group. If your Round-robin group
has only two external interfaces, all outgoing connections now use the remaining active interface. If your Round-
robin group has more than two external interfaces, the Firebox reduces the size of the group so that it includes
only the remaining active interfaces. The Firebox continues to use the relative weights of the remaining
interfaces to make routing decisions.
n Failover — The Firebox removes the failed interface from the failover group. Traffic goes out through the next
available interface in the failover list.
n Interface Overflow — The Firebox removes the failed interface from the Interface Overflow group. The Firebox
uses the Interface Overflow threshold assigned to each interface to determine which one to use for outgoing
traffic. If your Interface Overflow interface group has only two external interfaces, all outgoing connections now
use the remaining active interface.
n Routing Table — The Firebox removes the failed interface from the ECMP group. ECMP continues to make
routing decisions based on the external interfaces that remain active.
Failback
When you reconnect the interface or Link Monitor probes determine that an interface is active again, the Firebox makes
the interface available again for outgoing traffic.
The Probe Interval and the Reactivate After settings on the Link Monitor tab determine how long this process takes.
If you keep the default settings, the Firebox sends a probe every five seconds and reactivates the interface after three
successful probes for a logical link failure.
New outgoing connections, unless they match an entry in the sticky connections table, start to use the now-active
external interface based on the multi-WAN method you select.

Network Settings
Existing connections (including traffic that matches an entry in the sticky connections table) behave according to the
option you select in the Failback for Active Connections drop-down list:
n Immediate Failback
o The Firebox drops all currently active connections.
o TCP RST packets are sent to close all open TCP connections.
o NAT ports that are open for return UDP packets are closed.
o The sticky connections table is purged.
n Gradual Failback
o All currently active connections are allowed to finish before Fireware begins to use the multi-WAN method to
send them through another external interface.

o The sticky connections table stays the same.
n No Failback
o All connections use the failback interface and never fail over to the original interface.
Select Immediate Failback if your backup line is expensive, you want to use the backup line only in an emergency, and
your organization can tolerate dropped connections when the failback happens.
Select Gradual Failback if your organization cannot tolerate dropped connections when the failback happens.
Select No Failback if you have no preference which interface is the active interface after a failover event.

Network Settings
Multi-WAN Failover
Failover is the default multi-WAN method. Use this method if you want to:
n Use one external interface for all traffic, and you have another ISP that you can use if the primary line goes down.
n Reserve a WAN2 interface for special traffic and use WAN1 for all other traffic. If the primary WAN1 connection
goes down, all traffic can use WAN2 for the emergency outage.
How It Works
The Firebox sends all traffic through the external interface at the top of the list in the Multi-WAN Failover
Configuration dialog box. If that interface is not active, the Firebox checks the next external interface in the list. The
first active interface in the list is the gateway for all outgoing traffic.
If the Firebox senses an Ethernet link failure, failover happens immediately. The default probe options are:
n Send a probe every five seconds

n Deactivate the interface after three probes in a row fail
n Reactivate the interface after three successful probes in a row
If an external interface that was previously down becomes active again, and it is higher in your list than the currently
active external interface, the Firebox immediately starts to send all new connections out the active external interface
that is now highest in the list, unless you select the No Failback option.
You must specify how the Firebox handles existing connections that currently use the interface that is now lower in the
list. For information about failback options, see the previous Failback section.
How to Configure It
To configure this method, select Failover in the multi-WAN configuration.

Network Settings
Select Configure to:
n Specify the interfaces that participate in failover.

n Establish a failover sequence for those interfaces.
When an External Interface Fails

The failed interface is removed from the failover group. The next available interface in the Failover list assumes the
highest precedence. Client connections time out and are re-established with the new route.

Network Settings
Multi-WAN Interface Overflow

Use the Interface Overflow method when you want to restrict the maximum bandwidth that each external interface
uses. When the bandwidth threshold is reached for an external interface, new connections use the next external
interface in your list.
How It Works
When you use the Interface Overflow method, you specify the order you want the Firebox to send traffic through
external interfaces and configure each interface with a bandwidth threshold value. The Firebox starts to send traffic
through the first external interface in the Interface Overflow Configuration list. When the traffic through that interface
reaches the bandwidth threshold you set for that interface, the Firebox starts to send new connections through the next
interface in the list.
This multi-WAN method allows the amount of traffic sent over each external interface to be restricted to a specified
bandwidth limit.
To determine traffic volume through an interface, the Firebox examines the amount of sent (TX) and received (RX)
packets and uses the higher number. When you configure the interface bandwidth threshold for each interface, you
must consider the needs of your network for this interface and set the threshold value based on these needs. For
example, if your ISP is asymmetric and you set your bandwidth threshold based on a large TX rate, interface overflow
will not be triggered by a high RX rate.
When all external interfaces reach their threshold, the Firebox uses the ECMP algorithms to find the best path.
How to Configure It
To configure this method, select Interface Overflow in the multi-WAN configuration.

Network Settings
To configure the bandwidth threshold for an interface, select Configure > [interface name] > Configure.

The failed interface is removed from the interface overflow group. Traffic goes out through the other external interfaces
in the group, according to the interface overflow threshold assigned to each one.

Network Settings
Multi-WAN Round Robin

Use the Round-robin method when you want to specify a weighted distribution of outgoing traffic across your external
interfaces.
How It Works
The Round-robin method distributes traffic to each external interface based on the number of connections.
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.
The Round-robin algorithm is applied only after routes, sticky connections, and SD-WAN routing fail to give a routing
decision.
The weights you assign are relative weights. For example, suppose interface 0 (eth0) is an external interface and you
give it a weight of 3. Interface 1 (eth1) is also an external interface and you give it a weight of 2. For every three bytes of
traffic that go through eth0, two bytes will go through eth1. The byte count sent through eth0 will be one and one-half
times as much as eth1.
To determine which interface to use for a new outgoing connection, weighted Round-robin calculates the
connections:weight ratio (current connections as a proportion of the assigned weight) for each external interface and
chooses the interface with least value for the new connection.
For example, configure Interfaces 0, 1, and 2 as external interfaces, and use Round-robin weights of 8, 2, and 1 for
those interfaces respectively. Assume that new connections happen in sequence, and each new connection increases
the load on an interface equally. The algorithm assigns the new connections as shown in the table:
Current ratio of Current ratio of Current ratio of

{connections:weight} {connections:weight} {connections:weight} New connection uses
Interface 0 Interface 1 Interface 2 this interface
0:8 0:2 0:1 0
1:8 0:2 0:1 1
1:8 1:2 0:1 2
1:8 1:2 1:1 0
2:8 1:2 1:1 0
3:8 1:2 1:1 0
4:8 1:2 1:1 0
5:8 1:2 1:1 1

Network Settings
Current ratio of Current ratio of Current ratio of

{connections:weight} {connections:weight} {connections:weight} New connection uses
Interface 0 Interface 1 Interface 2 this interface
5:8 2:2 1:1 0
6:8 2:2 1:1 0
7:8 2:2 1:1 0
8:8 2:2 1:1 Use ECMP when all interfaces have

full traffic load
This table shows which external interface is used for a new outgoing connection based on the connections:weight ratio
Calculate Weights for Round-robin

You can only use whole numbers for the interface weights; no fractions or decimals are allowed.
To ensure an optimal distribution of connections, you might need to perform a calculation to know which whole-number
weight to assign for each interface. Use a common multiplier so that the ratios of connections at each external interface
is resolved to whole numbers.
Example
You have three Internet connections. One ISP gives you 6 Mbps, another ISP gives you 1.5 Mbps, and a third ISP gives
you 768 Kbps. Convert the proportion to whole numbers:
1. Convert the 768 Kbps to Mbps so that you use the same unit of measurement for all three lines. This is
approximately .75 Mbps. Your three lines are rated at 6, 1.5, and .75 Mbps.
2. Multiply each value by 100 to remove the decimals. Proportionally, these are equivalent: {6 : 1.5 : .75} is the
same ratio as {600 : 150 : 75}.
3. Find the greatest common divisor of the three numbers. In this case, 75 is the largest number that evenly divides
all three numbers 600, 150, and 75.
4. Divide each of the numbers by the greatest common divisor.
The results are 8, 2, and 1. This gives the whole-number weights used for the example.
How to Configure It
To configure this method, select Round-robin in the multi-WAN configuration. Select Configure to:
n Specify the interfaces that participate in Round-robin

n Assign a weight to those interfaces
By default, all external interfaces participate in Round-robin. You must include at least two interfaces.

Network Settings
If you have more than two external interfaces, you might want to reserve one external interface for a special purpose.
For example, you might want to use an external interface only to route traffic to an application service provider. To
exclude an external interface from the round-robin, clear the check box next to that interface.

Network Settings

The failed external interface is removed from the Round-robin group. Fireware continues to use the relative weights of
the remaining interfaces to make routing decisions.

Network Settings
Multi-WAN Routing Table

Use the Routing Table method when you want a quick and easy way to evenly distribute outgoing traffic among multiple
external interfaces.
How It Works
If you have multiple active external interfaces, multiple default routes to the external network are available with the
same cost (one hop). The Routing Table multi-WAN method uses Equal-Cost Multi-Path Routing (ECMP) to distribute
outgoing connections based on the src/dst (source and destination) IP addresses. The Firebox does not consider the
amount of bandwidth sent through each interface. The Routing Table method is the quickest way to load balance more
than one route to the Internet.
When you select the Routing Table multi-WAN method, the Firebox first looks at SD-WAN routing actions in policies,
the internal route table, and the sticky connection table to see if it should send a packet through a specific external
interface. If the Firebox does not find a specified route, it selects a route based on ECMP. Because the ECMP algorithm
manages all connection decisions, no additional configuration is necessary after it is enabled.
The Routing Table method attempts to equalize the number of connections that go out of each interface. If a large
number of connections are passing through the Firebox with different src/dst IP addresses, the Firebox can evenly
distribute the connections.
How to Configure It
To configure this method, select Routing Table in the multi-WAN configuration. This is the only setting.

Network Settings

The failed interface is removed from the ECMP group. ECMP continues to make routing decisions based on the
external interfaces that remain active.

Network Settings
Link Monitor
Link Monitor is vital for multi-WAN, SD-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.
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)

Network Settings
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 and SD-WAN 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.
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:

Network Settings
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.
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:

Network 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 Settings
Routing Decisions Logic

When a computer behind the Firebox on a trusted or optional network attempts to send traffic to the external network,
the Firebox must make three main decisions:
n Whether the traffic is allowed out

n Whether an external interface is available to send the traffic
n Through which external interface to send the traffic
To make these decisions, the Firebox considers these questions:
1. Does the packet match the From and To lists in a policy?

Yes — Continue.
No — Drop the packet and send a log message with the reason Unhandled Internal Packet.
2. Does the policy allow the traffic?
Yes — Continue.
No — Drop, block, or deny the packet based on the configured settings.
3. Does the policy use SD-WAN routing?
Yes — Send the traffic through the interface specified by the SD-WAN action.
If the SD-WAN action specifies more than one interface, the first interface in the list is preferred. The preferred
interface is used if it is qualified. A qualified interface is an interface that is available and has loss, latency, and
jitter metrics that do not exceed those you specified. If none of the SD-WAN interfaces for this policy are
available, the Firebox drops the packet and sends an all gateways are down log message.
No — Continue.
4. Check the Firebox kernel routing table. Is there a specific route (a route that is not a default route) that matches
the traffic's source and destination?
Yes — Use the gateway for that route.
No — Continue.
5. How many default routes are in the kernel routing table?
Zero (the kernel routing table has no default route) — Drop the packet; all external interfaces are down.
Exactly One default route in the routing table — Use the gateway interface for this default route to send the
packet out.
There is more than one default route in the routing table — Continue.
6. Does the traffic match an entry in the sticky connections hash table?
Yes — Send the traffic using the sticky interface.
No — Continue.
7. Does the policy To list specify the Any-External alias?
Yes — Use the specified multi-WAN routing method: weighted Round-robin, Failover, or Interface Overflow.
No — If you specify an interface in the To list instead of the Any-External alias, the policy does not include the
default route (0.0.0.0/0). The packet fails to be delivered because it has a destination IP address other than
the IP address of the interface you specified.

Network Settings
Load balancing interface groups pertain only to the Round-robin, Failover, and Interface
Overflow multi-WAN methods. A load balancing interface group includes all the interfaces you
specify to participate in the Round-robin, Failover, or Interface Overflow configuration.

Network Settings
Multi-WAN Routing Decision Flow Chart

This flow chart shows how the Firebox determines which interface to use to send an outgoing connection.

Network Settings
Diagram Notes
A. A specific route is a route that is not a default route. A default route has the destination 0.0.0.0.
You can see route tables on the Status Report tab of Firebox System Manager.

Network Settings
B. In Firebox System Manager, the Front Panel tab shows the logical link status (Available or Failed). The color
of the NIC icon shows the physical link status:
n Green means there is a physical link detected on the cable.

n Black means there is no physical link detected because the cable is unplugged.
You can also see interface status information on the Status Report tab, or in Fireware Web UI.
C. For each outgoing connection, the Firebox combines the [source IP address/destination IP address] pair to make
a unique hash value. The Firebox puts the hash value for an outgoing connection in the sticky connections hash
table, and associates the table entry with the external interface used to send the outgoing traffic.
If the [source IP address/destination IP address] hash of an outgoing connection matches a hash table entry, the
Firebox uses the external interface associated with that entry in the table for that connection.
Entries in the hash table have a limited duration (3 minutes, by default). You can specify a different duration.
When a new outgoing connection matches a hash table entry, the timer for that entry resets. When the timer for
an entry reaches zero, the Firebox purges the entry from the table.

Network Settings
Software-Defined WAN (SD-WAN)
SD-WAN automatically routes network traffic across multiple WAN connections based on
policies you define.
SD-WAN can help you increase application availability and performance, and better utilize a hybrid WAN. For example,
you can:
n Send high-priority, latency-sensitive traffic such as VoIP and video conferencing over higher-quality, more
expensive WAN connections.
n Send lower-priority traffic over less expensive WAN connections.
n Specify metric-based routing thresholds so that connections fail over to a different WAN connection when
performance is less than ideal.
SD-WAN ignores the global multi-WAN configuration settings.
SD-WAN actions apply to new connections that initiate traffic. SD-WAN actions do not apply
to reply traffic. You cannot use SD-WAN actions to force reply traffic out a specific interface.
SD-WAN Routing
Metric-based SD-WAN Routing
With metric-based SD-WAN routing, the Firebox makes routing decisions based on loss, latency, and jitter metrics. For
example, if the packet loss rate for an interface exceeds the value you specify, the Firebox can automatically route the
traffic over another interface specified in the SD-WAN action.
SD-WAN Routing Without Metrics

If you do not specify metrics in the SD-WAN configuration, the Firebox makes SD-WAN routing decisions based on
connectivity only.
For example, if a Link Monitor target fails to respond after a certain number of attempts, the Firebox considers the
interface inactive. The Firebox can then fail over connections to another interface included in the SD-WAN action.

Network Settings
Configuration
To configure SD-WAN, you:
n Specify Link Monitor targets (required for metric-based SD-WAN routing).

n Create an SD-WAN action.
n Add interfaces to the SD-WAN action.
n Configure a policy to use the SD-WAN action.
There is no limit to the number of SD-WAN actions that you can create. For example, you can create multiple SD-WAN
actions for different scenarios such as VoIP, backup services, and guest users.
You can apply the same SD-WAN action to more than one policy. You can choose to apply SD-WAN actions to only
some of your policies.
Configure Link Monitor Targets

Link Monitor is an important part of your SD-WAN configuration. When you configure Link Monitor for an interface, you
specify one or more Link Monitor targets, which are remote hosts beyond your network perimeter. The Firebox sends
traffic through the interface to a Link Monitor target to verify connectivity.
When your Firebox uses metric-based SD-WAN routing, it makes routing decisions based on loss, latency, and jitter
calculations from Link Monitor probes. For meaningful data, we recommend that you carefully select Link Monitor
targets. In most cases, we recommend that you specify a Link Monitor target other than the default gateway. For Link
Monitor best practices, see Fireware Help.
Configure SD-WAN Actions

An SD-WAN action includes these settings:
Interfaces
Specifies which interfaces participate in the action. You can include one or more of these interface types in SD-
WAN actions:
n External
n Internal (trusted, optional, or custom) — Internal interfaces include those configured for private network
connections such as leased lines and MPLS links.
Primary Interface
Specifies which interface is primary. The first interface in the list is the primary interface. The primary interface is
preferred if it is active and has metrics that do not exceed the values you specified. To change the primary
interface, you can move interfaces up or down in the list.
Failover
Specifies whether metrics (loss, latency, or jitter) or connectivity (active/inactive) are used to determine failover.
If you select metrics, you can also specify whether any or all metrics are used to determine failover.

Network Settings
Failback
Specifies how connections fail back (immediately, gradually, or not at all).
Configure Policies
In a policy, you select the SD-WAN action you want to apply. SD-WAN actions force traffic in the policy to use the
interfaces defined in the SD-WAN action.
You can specify the same SD-WAN action in multiple policies.

Network Settings

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 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 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.
It is important to make sure that the traffic the rule applies to goes out through only one interface using SD-WAN.

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.
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.

Network Settings
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 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 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.

Network Settings
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 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 Settings

Network Settings
Traffic Management
Traffic management, also known as traffic shaping, enables you to set the maximum bandwidth
available for different types of traffic, and to guarantee a minimum amount of bandwidth for
specific traffic flows.
Although the Firebox has no control over the rate at which packets arrive at a given interface, you can use Traffic
Management settings to guarantee and limit bandwidth.
Guarantee Bandwidth
Set the minimum bandwidth to guarantee for traffic managed by a Traffic Management action.
Limit Bandwidth
Set the maximum bandwidth to allocate to traffic managed by a Traffic Management action.
Bandwidth limits and guarantees apply only if the necessary bandwidth is available through the interface that handles
the traffic.
Traffic Management configuration is very flexible, and enables you to control traffic by policy, application, traffic
direction, and source IP address. For example, you can use Traffic Management actions to:
n Limit bandwidth for HTTP for all users on the trusted interface to the Internet.
n Guarantee 10 Mbps bandwidth for HTTP traffic for a specific user or group.
n Guarantee or limit bandwidth used by specific applications or application categories.
n Limit the bandwidth for a group.
n Limit the bandwidth used for FTP for each source IP address.
USE CASE:
Many organizations have mission-critical, real-time network applications that must take priority over other
traffic. You can use bandwidth restrictions and reservations, together with prioritization, to make sure
critical applications have the bandwidth they need.

Network Settings
Enable Traffic Management

Before you can add Traffic Management actions, you must enable Traffic Management in the global networking
settings. For performance reasons, this setting is disabled by default. Only enable this setting if you plan to configure
Traffic Management or Quality of Service (QoS).
We do not recommend Traffic Management for tabletop Firebox models such as T Series
Fireboxes. Traffic Management significantly impacts performance on these models.
Traffic Management Action Types

There are three types of Traffic Management actions:
All Policies
The action applies to the combined bandwidth of all policies that use it. If the action is used for multiple policies,
all policies share the bandwidth guarantee or maximum specified in the action.
Per Policy
The action applies individually to each policy that uses it. If the action is used for multiple policies, the bandwidth
maximum or guarantee specified in the action applies separately to each policy.
Per IP Address
The action applies individually to each client source IP address. When you configure a Per IP Address action,
you also specify the Maximum Instance, which is the number of client source IP addresses that the bandwidth
constraints in the action can individually apply to.
If the number of concurrent clients that use a Per IP Address action is larger than the Maximum Instance, clients
with different source IP addresses begin to share the bandwidth specified in the action. A round-robin algorithm
determines which source IP addresses share bandwidth. Recently connected source IP addresses share
bandwidth with source IP addresses that have been connected longest.
If you apply a Per IP Address action to multiple policies, the action applies to each client source IP address for
the combined traffic handled by all policies that use the action. It functions similar to an All Policies action,
except on a per IP address basis.
Traffic Management in Policies

In a policy, you can configure two Traffic Management actions, a Forward action and a Reverse action. The Forward
action applies to traffic that originates from the addresses in the From list (source) in the policy. The Reverse action
applies to traffic that originates from the To list (destination).

Network Settings
If a policy uses the same Traffic Management action for traffic in both directions, the action applies to the combined
bandwidth of traffic in both directions.
For example, large FTP file transfers disrupt HTTP traffic on your network. To solve this problem, you decide to use
Traffic Management to guarantee a minimum amount of bandwidth to HTTP traffic.
First, you specify the Outgoing Interface Bandwidth for the trusted interface:
Next, you create a Traffic Management action and specify a Guaranteed Bandwidth value:
In the HTTP policy, specify the Traffic Management action:

Network Settings
Finally, in the DNS policy, specify the Traffic Management action:
Both the DNS and the HTTP policy use the same Traffic Management action, Min500Kbps. When necessary, the
policies that use this action will have a minimum of 500 Kbps between them. Otherwise, this bandwidth will be available
for other policies.
Traffic Management in Application Control

If you have an Application Control subscription, you can also use Traffic Control actions to control the bandwidth used
by applications and application categories. If you apply a Traffic Control action to an application category, all
applications in the category share the bandwidth specified in the Traffic Management action.
In Application Control, there are no separate forward and reverse actions. Traffic Management actions apply to
application traffic in both directions for all policies that use the Traffic Management action.
For example, you might want to limit the bandwidth used by streaming media applications to 100 Kbps per user. This
can be a good alternative to blocking application use completely.
First, add a new Traffic Management action:

Network Settings
In the Application Control configuration, add a new action called Limit_Streaming.
Click Select by Category, select Media streaming services, and select the Traffic Management action.

Network Settings
To set a different Traffic Management action or to disable traffic management for an application in the category, you can
edit the action for the individual application. Application-specific actions take precedence over application category
actions. For example, if you want to make an exception for Skype, you can configure a separate action for that
application.
To override a Traffic Management action for a specific application in the category, you must
assign a different Traffic Management action to the application. If you disable traffic
management for an application, the Traffic Management action for the category applies to
traffic for that application.

Network Settings
Traffic Management Action Precedence

It is possible that more than one Traffic Management action could apply to traffic. For example, you could configure the
HTTP policy to use a Traffic Management action, and you could also configure Application Control to use a Traffic
Management action for video streaming applications that use HTTP.
If multiple Traffic Management actions could apply, the most specific action is used. The order that actions are applied,
from most to least specific is:
1. Application
2. Application category
3. Policy
Monitoring Bandwidth Statistics

You can see bandwidth statistics for each Traffic Management action in:
n Firebox System Manager — Traffic Management tab

n Fireware Web UI — Traffic Management System Status page
We do not recommend traffic management for tabletop Firebox models such as T Series
Fireboxes. Traffic management significantly impacts performance on these models.

Network Settings
Quality of Service (QoS)

On a network configured for QoS, devices prioritize traffic based on markers in packet headers.
In most cases, we recommend that you configure Traffic Management rather than QoS. Traffic
Management has the same benefits of QoS but is simpler to configure.
QoS Plan
QoS requires an extensive plan. You must determine:
n Whether your network devices and ISP support QoS.

n What type of QoS marking your network devices use (DSCP or IP precedence).
n How much network bandwidth you have available.
n Which network applications are high priority.
n Which network applications are sensitive to latency or jitter, or both.
You must also make sure that your network supports QoS from end to end. This means that user computers, servers,
access points, switches, the Firebox, and your ISP must all support QoS marking. If your ISP does not support QoS,
the ISP might drop packets that have QoS marking.
QoS Marking
Some devices might depend on a switch to mark traffic; other devices might mark their own traffic.
Traffic marked by a switch

In this example, some endpoint devices on your network do not add QoS markers. When traffic from these
endpoints reaches a managed switch configured for QoS, the switch applies a QoS mark.
Traffic marked by an endpoint device

In this example, some endpoint devices on your network mark their own traffic. When traffic from these
endpoints reaches a switch, the switch must support QoS, allow the traffic, and keep the QoS mark unchanged.
Configuration
To enable QoS on the Firebox, you must select the Enable all traffic management and QoS features global setting.
This setting is disabled by default because it impacts throughput on your Firebox. Do not enable this setting unless you
plan to use either QoS or Traffic Management.

Network Settings
After you enable QoS on the Firebox, you can configure Firebox interfaces to handle QoS marks from your internal
devices. When the Firebox receives the traffic, it keeps, clears, or changes the QoS mark, depending on the Firebox
settings you specify.
You can also configure policy-based QoS. This means the Firebox only handles QoS for traffic that matches a policy.
This guide does not include QoS configuration procedures. For detailed information about QoS, see Fireware Help.
Throughput Impact
Traffic Management and QoS affect maximum throughput on the Firebox because the Firebox CPU must complete
additional processing for each packet. Potential throughput reductions are as follows:
n Unified Threat Management (UTM) firewall — On a Firebox with security services applied to HTTP traffic,
throughput might be reduced up to 10%.
n IMIX firewall — Throughput might be reduced up to 40%. This is most noticeable on tabletop Fireboxes when
you measure internal traffic, for which the maximum performance is less than the potential link speed.
n IMIX UDP traffic over BOVPN — Throughput might be reduced up to 20%.

Firewall Policies
Firewall Policies
Firewall policies control what types of connections and content the Firebox allows.
n Policy From and To fields

n Aliases
n Management policies
n Policy precedence
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.

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
Alias members can include a combination of these types of addresses:

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 the
(DNS lookup) 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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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:
Packet Filter Proxy and ALG
Source
IP Header Destination
Port(s)/Protocols
Packet body
Attachments/Files
Packet Content
RFC compliance
Commands

Firewall Policies
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:
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)

Firewall Policies
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.

Security Services
Security Services
Security services extend the built-in defenses of your Firebox to help you secure your network.
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 Botnet Detection
n DNSWatch
n Intrusion Prevention Service (IPS)
n Geolocation
For a list of additional resources on these topics, see Security Services Additional Resources.

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.
Reputation Enabled Defense (RED)

Cloud-based service that controls access to websites based on reputation and previous behavior.
spamBlocker
Identifies and denies unwanted and dangerous spam email messages.

Security Services
Threat Detection and Response

Cloud-based service that collects events from the Firebox and network endpoints and takes automated action to
respond to threats.
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 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 Portal*
Application Control
APT Blocker
Botnet Detection
Data Loss Prevention
DNSWatch
Gateway AntiVirus
Geolocation
IntelligentAV*
Intrusion Prevention Service

Security Services
Features and Services Basic Security Suite Total Security Suite
spamBlocker
Threat Detection and Response
WebBlocker
Support Standard (24× 7) Gold (24×7)
*Available on Firebox M Series devices (except M200/M300), Firebox Cloud, and FireboxV.
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.
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.
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 Geolocation
n Intrusion Prevention Service
You can enable these security services in proxy policies only:

Security Services
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
Reputation Enabled Defense HTTP, HTTPS
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.

Security Services
Globally Configured Security Services
Some security services are not enabled at the policy level. Instead, you must enable and
configure these security services globally:
n Botnet Detection
n DNSWatch
Botnet Detection
A botnet is a large number of client computers that are infected by malware and controlled by a remote server. The
remote command and control server can control the botnet computers and use them to perform malicious acts, such as:
n Perform denial-of-service attacks

n Send spam and viruses
n Compromise private data
The Botnet Detection security service uses a feed of known botnet site IP addresses. When Botnet Detection is
enabled, it allows the Firebox to prevent infected botnet clients from connecting to botnet servers and also prevents
remote infected computers from connecting to your public-facing servers.
If you see false positives for sites that you do not consider to be botnet sites, you can manually add the IP addresses to
the Exceptions list.
To make sure that you always have the latest list of botnet site IP addresses, configure Botnet
Detection to automatically update the sites list.
Botnet Detection is enabled globally by default. Botnet Detection is licensed as part of Reputation
Enabled Defense. Your Firebox must have Reputation Enabled Defense enabled in the feature
key before you can use the Botnet Detection service.

Security Services
DNSWatch
DNSWatch is a cloud-based security service that is integrated with your Firebox. DNSWatch monitors, resolves, and
filters outbound DNS requests received from the Firebox. It blocks connections from your users to malicious
clickjacking and phishing domains, regardless of the connection type, protocol, or port.
When you enable DNSWatch and the Firebox is registered to your DNSWatch account, the Firebox adds the IP
addresses of two DNSWatch DNS servers to the top of the Network DNS server list.
With DNSWatch enabled, the Firebox forwards outbound DNS queries from hosts on the protected networks to the
DNSWatch DNS servers. DNSWatch then evaluates whether the domain is a known threat.
If the domain is not a known threat:
n DNSWatch resolves the DNS query to the destination.
If the domain is a known threat or is on the DNSWatch blacklist:
n DNSWatch resolves the domain to the IP address of the DNSWatch Blackhole Server.
n The DNSWatch Blackhole Server attempts to gather more information about the threat from the endpoint that
made the DNS request.
n For HTTP and HTTPS requests, DNSWatch redirects the user to a customizable Deny page. The Deny page
includes interactive training to help educate your users about how to recognize and avoid phishing attacks.
DNSWatch applies to all outbound DNS traffic. There are no DNSWatch settings to configure in
the firewall policies on the Firebox. In many cases, DNSWatch DNS servers take precedence
over other DNS servers that could already be configured on your Firebox. However, if a local DNS
server appears first in the Network DNS server list, queries made for local domain resources are
sent to the local DNS server.

Security Services

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 Fast Scan mode in most environments, especially on T Series models.
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.

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).

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.

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.

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

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).

Security Services
Geolocation
Geolocation is licensed as part of Reputation Enabled Defense. Your Firebox must have
Reputation Enabled Defense enabled in the feature key before you can use the Geolocation
service.
The Geolocation security service enables you to detect the geographic locations of connections to and from your
network. You can configure Geolocation to block connections to or from IP addresses in specific countries.
The Firebox looks up the geographic location of an external source of traffic or the traffic destination IP address in a
database. To make sure that you always have the latest Geolocation database, enable automatic updates.
If the Firebox cannot determine the geographic location of an IP address, Geolocation does not
drop the connection.
When a user on your network tries to connect to a website in a blocked country, a deny message appears in the web
browser. The deny message includes the reason the connection was denied and the name of the blocked country.
When Geolocation drops other types of traffic, no deny message appears.
Geolocation Actions
To configure Geolocation, you add Geolocation actions that specify which countries to block, then assign the actions to
policies. You can select countries to block from a map or from the country list.

Security Services
If there are specific sites that you do not want to block, add them to the Exceptions list in a Geolocation action.
Geolocation and Policies
After the Setup Wizard is complete, Geolocation is enabled automatically for all policies. All
policies are configured to use the default Global Geolocation action automatically. The Global
action does not block any countries by default.
If you want more control over the types of connections the Firebox denies based on geographic location, you can enable
or disable Geolocation for a specific policy in the policy settings and change the Geolocation action used by the policy.
When Geolocation is enabled, traffic log messages show the destination or source of the
connection external to the Firebox.

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 SMTP proxy actions
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.

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

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.

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
n Reputation Enabled Defense (RED)

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

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 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.

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.

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.

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 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.

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.

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

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.

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.
If your Firebox has Threat Detection and Response (TDR) enabled, the Firebox also sends
APT Blocker alarms to ThreatSync so that TDR Host Sensors can recognize and
automatically remediate the threat.
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.
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.

SMTP-proxy Policies
Fireware includes an SMTP-proxy policy template to manage email sent over SMTP (Simple Mail Transfer Protocol).
When you add an SMTP-proxy policy, you select and configure a proxy action that contains rulesets that apply to
incoming or outgoing connections.
SMTP Proxy Actions

SMTP is a protocol used to send email messages between email servers and also between email clients and email
servers over a TCP connection on port 25 or 465. You can use the SMTP-proxy to control email messages and email
content. The proxy scans SMTP messages and compares their content to the rules in the proxy configuration.
The SMTP-proxy supports SMTP traffic on TCP port 25, and SMTP Secure (SMTPS) traffic encrypted with TLS
(Transport Layer Security) on port 465. The TLS Support option in the proxy properties determines whether TLS is
enabled, disabled, or required.
The SMTP-proxy supports:
n SMTP traffic on TCP port 25

n SMTPS with the STARTTLS command on TCP port 25
n SMTPS on TCP port 465 (used by some legacy clients and services)
The SMTP-proxy checks the message for RFC compliance and harmful content. It examines the SMTP headers,
message recipients, senders, and content, as well as any attachments. The SMTP-proxy can restrict traffic from
specific user names or domains. It can also strip unwanted or dangerous SMTP headers, filter attachments by file name
or MIME content type, or deny the email based on an address pattern. The ability to strip header information is
particularly valuable to many network administrators.
When you create an SMTP-proxy policy, you can choose from two default proxy actions:
SMTP-Incoming.Standard
This proxy action includes rulesets to protect your SMTP email server from external traffic.
SMTP-Outgoing.Standard
This proxy action includes rulesets to control outgoing SMTP connections from users on your trusted and
optional networks.
WatchGuard recommends that you do not use an outbound SMTP-proxy, unless you want to use
DLP to examine outbound content. An outbound SMTP proxy can cause mail delivery issues, and
is generally unnecessary. For example, you do not need to check your outbound email for spam.
The predefined SMTP template is always configured for inbound connections.
For more information about the SMTP protocol, see RFC 821 at http://tools.ietf.org/html/rfc821.

Prevent SMTP Mail Relay

Email relaying, also called mail spamming or referred to as an open mail relay, is an intrusion in which an unauthorized
person uses your email server, address, and other resources, to send large amounts of spam email.
You can configure the SMTP proxy action to provide basic mail relay protection. In the proxy action, in the Address
> Rcpt To settings, configure the proxy to allow messages addressed to the domains your SMTP server receives mail
for, and to deny messages addressed to any other domain.
SMTP proxy action configured to allow mail to the domain example.com
For more information, see Fireware Help.

spamBlocker
Use spamBlocker to detect and block spam before it reaches an email server on the network
protected by the Firebox.
A large volume of unwanted email, also known as spam, often contains malicious links, degrades employee
productivity, and wastes network resources. WatchGuard spamBlocker™ is a cloud-based service that uses industry-
leading anti-spam technology to block spam at your Internet gateway. spamBlocker looks for patterns in spam traffic,
instead of the contents of individual email messages. Because it uses a combination of rules, pattern matching, and
sender reputation, it can find spam in any language, format, or encoding method.
After spamBlocker categorizes a message, it adds the spam category and spam score to the
full email message header. Because the information spamBlocker adds to the email header can
interfere with other anti-spam services, we recommend you do not use spamBlocker and other
anti-spam services together.
You can also use APT Blocker to stop malware threats from entering your network through the
SMTP-proxy, POP-proxy, or IMAP-proxy.
WatchGuard spamBlocker works with SMTP, POP3, and IMAP-proxy policies to examine inbound email messages.
For the SMTP-proxy, you can configure the Firebox to take the following actions when spamBlocker determines that an
email message is spam:
n Deny — Stops the spam email message from being delivered to the email server, and sends SMTP error 571
Delivery not authorized, message refused to the email server that sent the email message.
n Add subject tag — Allows the spam email message to go to the mail server but adds text to the subject line to
identify the email message as spam or possible spam.
n Allow — Allows the spam email message to go through the Firebox without a subject tag.
n Drop — Drops the connection immediately. Unlike the Deny action, the Firebox does not send an SMTP error
message to the server that sent the email. If the Firebox does not send an error, the server that sent the email will
detect this as a timeout and will likely try to resend the message at least once.
n Quarantine — Sends the spam email message to a Quarantine Server.
If you use spamBlocker with the POP3 or IMAP-proxy, you have only two actions to choose from: Add Subject Tag
and Allow. You cannot use the Quarantine Server with the POP3 or IMAP-proxy.

Confirmed Spam
If spamBlocker categorizes an email message as spam (i.e., email message comes from a known spammer), we
recommend you use the Deny action if you use spamBlocker with the SMTP-proxy, or the Add subject tag if you use
spamBlocker with the IMAP-proxy or POP3-proxy.
spamBlocker Tags
The Firebox can add spamBlocker tags to the subject line of spam email messages. You can customize the text of the
tags that spamBlocker adds. This example shows the subject line of an email message that was classified as spam.
and tagged with the default ***SPAM*** tag:
Subject: ***SPAM*** Free auto insurance quote
Here are some examples of other possible spamBlocker tags you could create:
Subject: (SPAM) You've been approved!
Subject: [POSSIBLE SPAM] Save 75%
Subject: [JUNK EMAIL] Free shipping
Subject: *SPAM/BULK* 10 lbs in 10 days!
spamBlocker Exceptions
spamBlocker might sometimes identify a message as spam when it is not spam.
If you know the address of the sender, you can add a spamBlocker exception that tells the Firebox not to use
spamBlocker to scan messages from that source address or domain. Define your exception as specifically as possible.
For example, add an exception for a specific sender, not a whole domain. For information about how to specify sender
information, see Fireware Help.
If spamBlocker misses spam, or falsely identifies legitimate email as spam, you can send
feedback to WatchGuard. For more information, see the WatchGuard Security Portal.
You can add a domain to the exceptions list. We recommend this only as a temporary measure while you send
feedback to WatchGuard.

Use care when you add wildcards to an exception. Spammers can spoof header information.
The more specific the addresses in your exception list, the more difficult it is to spoof them.
Use an HTTP Proxy Server

In the global spamBlocker settings, you can configure spamBlocker to use an HTTP proxy server to connect to the
spamBlocker server through the Internet.
On the HTTP Proxy Server tab, specify the parameters for the proxy server. This includes the address of the proxy
server, the port the Firebox must use to contact the proxy server, and the authentication credentials the Firebox uses for
proxy server connections (if required by the proxy server).

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.

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.

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.

Sends requested URLs to a cloud-based WatchGuard reputation server that returns a reputation score. The
HTTP-proxy uses the reputation score to determine whether to drop the traffic, allow the traffic and scan it with
Gateway AntiVirus, or allow the traffic without a Gateway AntiVirus scan.
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.

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.

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.
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
Reputation Enabled Defense

If you have enabled the Reputation Enabled Defense service, you can configure the proxy to immediately deny
connections to URLs that have a bad reputation. You can bypass any configured Gateway AntiVirus scans for
URLs that have a good reputation. You can also change the reputation score thresholds here.
We recommend that you use the default reputation thresholds.
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.

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.

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.

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.

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.

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.1.
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.
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.

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.
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.

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)
n Reputation Enabled Defense
These other services require HTTPS content inspection to be effective:

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

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.

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.

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.

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

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/*

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.

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.

Authentication
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, 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.

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:
n 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.
n The user types a user name and password.

Authentication
n 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.
n If the authentication server responds that the user is authenticated, the user can connect to approved network
resources.
n 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

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.

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.

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:

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).

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 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 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.

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.

Authentication
LDAP Authentication Servers

You can use an LDAP (Lightweight Directory Access Protocol) authentication server to authenticate your users to the
Firebox. LDAP is an open standard protocol for use with directory services. The LDAP Server configuration on your
Firebox supports all third-party LDAP servers.
Before you configure your Firebox for LDAP authentication, review your LDAP vendor documentation to determine
whether your installation requires case-sensitive attributes.
How LDAP Works

LDAP is a hierarchical organization of objects. The hierarchy that defines the position of each object in the database and
each variable associated to each object type is called the schema. Each LDAP server refers to a schema or a set of
schema extensions. Microsoft Active Directory is also an LDAP server and has its own schema. Because the schema
structure is hierarchical, the root of the tree, typically used as the search base for recurring searches that look for
objects in the whole LDAP database, corresponds to the dc definition of the domain.
For example, if you specify the domain example.com as the root of the LDAP database, the root search base you
specify to look for users and groups is dc=example,dc=com.
Microsoft Active Directory stores users under the cn Users object by default (cn=Users,dc=example,dc=com).
You can also add other containers, such as Organizational Units (OUs), that enable you to group objects in a structured
way. When the LDAP database contains a lot of objects, this hierarchical organization improves scalability and
optimizes the query process.
You can configure the Firebox to query the LDAP or Microsoft Active Directory server starting at any level of the tree,
based on how you specify the search base in the LDAP or Active Directory server settings on the Firebox.
LDAP Search Base

When you configure the Firebox to use LDAP authentication, you must set a search base to limit the server directories
in which the Firebox searches for an authentication match. The standard format for the search base setting is:
ou=organizational unit,dc=first part of distinguished server name,dc=any part of the distinguished server name that
appears after the dot.
In most cases, we recommend that you specify the top-level domain so queries search the entire LDAP structure. For
example, if your domain name is example.com, your search base is dc=example,dc=com.
To specify one or more subdomains, add dc entries to the left of the domain name. For example, if your domain name is
example.com, and you have the subdomain test, your search base is dc=test,dc=example,dc=com.

Authentication
LDAP Firebox Configuration

To use LDAP server authentication with the Firebox, you must:
n Enable and specify the LDAP server in the Firebox configuration.

n In the Firebox LDAP configuration, specify the server IP address, search base, and group attribute. In most
cases, you must also specify the DN of a searching user.
n Add LDAP users or groups in the Firebox configuration.
n Add LDAP user names or group names to Firebox policies.
You can use any user DN with the privilege to search LDAP/Active Directory. However, we recommend that you
specify a user account other than an administrator account. A DN with only the privilege to search is usually sufficient.
For example: cn=User1,cn=Users,dc=example,dc=com.
LDAP over SSL (LDAPS)

By default, LDAP traffic is unencrypted plain text. LDAP authentication does not hash or encrypt passphrases.
To encrypt user credentials, we recommend that you select Enable LDAPS. When you use LDAPS, the traffic
between the LDAPS client on your Firebox and your LDAP server is secured by a TLS tunnel. When you select this
option, you can also choose whether to enable the LDAPS client to validate the LDAP server certificate. If you choose
to use LDAPS and you specify the DNS name of your server, make sure the search base you specify includes the DNS
name of your server.

Authentication
Active Directory Authentication Servers

Active Directory is a Microsoft directory service that uses the LDAP protocol. You can specify an Active Directory
server in your Firebox configuration so users can authenticate to the Firebox with their network credentials.
An Active Directory server can be located on any Firebox interface. However, we recommend that you locate your
Active Directory server on an internal interface so that LDAP traffic is not sent out of an external interface. By default,
LDAP traffic is not encrypted.
Users can connect to an Active Directory server through a VPN tunnel. Even though a VPN interface is technically an
external interface, the VPN tunnel securely transmits LDAP traffic over the Internet.
For Active Directory authentication to work, you must correctly configure both your Firebox and the Active Directory
server.
Active Directory Firebox Configuration

When you configure Active Directory on the Firebox with the wizard, you only need to specify:
n Active Directory domain name

n Server address
n Whether to enable LDAPS
The wizard determines the search base from these settings. The search base determines the scope of LDAP queries.
For detailed information about the search base setting, see the LDAP section of this guide.
If you use the wizard, you can edit the configuration later to configure more settings. You can also skip the wizard to
manually configure Active Directory on the Firebox.
When you edit or manually configure the Active Directory Firebox settings, you can:
n Add a backup Active Directory server.

n Edit the default port number.
n Edit the default timeout and dead time values.
n Edit the search base.
n Specify additional LDAP query options.

Authentication
You can add an unlimited number of Active Directory servers to the Firebox.
LDAP over SSL (LDAPS)

If your users authenticate with the Active Directory authentication method, their distinguished names (DN) and
passwords are hashed but not encrypted. To use Active Directory authentication and encrypt user credentials, we
recommend that you select the Enable LDAPS option. When you use LDAPS, the traffic between the LDAPS client on
your Firebox and your Active Directory server is secured by an SSL tunnel. When you select this option, you can also
choose whether to enable the LDAPS client to validate the Active Directory server certificate. If you choose to use
LDAPS and you specify the DNS name of your server, make sure the search base you specify includes the DNS name
of your server.

Authentication
Active Directory SSO

To simplify the authentication process for your users, you can configure single sign-on (SSO). With SSO, your users on
local networks provide their user credentials one time (when they log on to their computers) and are automatically
authenticated to your Firebox.
The WatchGuard SSO solution for Active Directory includes these components:
SSO Agent (Required)

You must install the SSO Agent on a domain server in your network. This server can be the domain controller or
another domain member server. When you install the SSO Agent, make sure that it runs as a user account that is
a member of the Domain Users security group. The Domain Users account you select must be able to run
services on the Active Directory server, to search the directory, and to search all other user audit information.
With these privileges, when users try to authenticate to your domain, the SSO Agent can query the SSO Client
on the client computer, the Event Log Monitor, or the Exchange Monitor for the correct user credentials, and
provide those user credentials to your Firebox. You can configure up to four SSO Agents on your Firebox for
redundancy.
SSO Client (Optional, but recommended)

When you install the SSO Client software on your Windows or macOS client computers, the SSO Client
receives a call from the SSO Agent and returns the user name, security group membership information, and
domain name for the user who is currently logged in to the computer. The SSO Client updates the SSO Agent
when user events occur. The SSO Client runs as a local system service on each user computer. It requires no
interaction from the user.
Event Log Monitor (Optional)

The Event Log Monitor enables Windows users to authenticate with SSO without the WatchGuard SSO Client.
We recommend that you use Event Log Monitor only as a backup SSO method.
Exchange Monitor (Optional)

The Exchange Monitor gets user login information from the IIS logs on your Microsoft Exchange Server.
Because Microsoft Exchange Server is integrated with your Active Directory server, Exchange Monitor can
easily get the user credentials from the IIS and RPC client access log messages in your user store.
If you do not want to install the SSO Client on each client computer, you can instead install the Event Log Monitor on
your domain controller, or the Exchange Monitor on your Microsoft Exchange Server computer. Then you can configure
the SSO Agent to get user login information from the Event Log Monitor or the Exchange Monitor. This is known as
clientless SSO.
With clientless SSO:
n Event Log Monitor collects login information from domain client computers and from the domain controller for
users that have already logged on to the domain and sends them to the SSO Agent.
n Exchange Monitor collects login and logout information from the user connections to the Exchange Server and
sends the information to the SSO Agent.

Authentication
For the most reliable SSO deployment, you must install the SSO Client, Event Log Monitor, or
Exchange Monitor. If at least one of these components is not installed, or not configured
correctly, the SSO Agent uses Active Directory (AD) Mode for SSO. We do not recommend
AD Mode as a primary SSO method or for environments where users log on to computers with
service or batch logons. When more than one user is associated with an IP address, network
permissions might not operate correctly. This can be a security risk.
In this section, we do not go into detail about how to install and configure the SSO solution. For more information about
how to configure SSO for your network, see the SSO topics in Fireware Help.
For an SSO method that does not require software and works with any client type and operating system, consider
RADIUS SSO. The next section in this guide explains RADIUS SSO.
Active Directory SSO and the Authentication Portal

After a user authenticates with Active Directory SSO, that user or another user can authenticate from the same IP
address to the Authentication Portal, and can select a different domain. If a user is authenticated to the Firebox with
Active Directory SSO and another user authenticates from the same IP address to the Authentication Portal, the
Authentication Portal session replaces the Active Directory SSO session. If a user is authenticated to the Firebox
through the Authentication Portal and another user tries to authenticate from the same IP address with Active Directory
SSO, the second session with Active Directory SSO is not created.

Authentication
RADIUS Authentication Servers

RADIUS is a client/server system that keeps the authentication information for users, remote access servers, VPN
gateways, and other resources in one central database. RADIUS authenticates the local and remote users on a
company network. You can configure multiple RADIUS servers on any Firebox.
The authentication messages to and from the RADIUS server always use an authentication key. This authentication
key, or shared secret, must be the same on the RADIUS client and server.
RADIUS Firebox Configuration

To use RADIUS server authentication with the Firebox, you must:
n Add the IP address of the Firebox to the RADIUS server to configure the Firebox as a RADIUS client.
n Enable and specify the RADIUS server in the Firebox configuration.
n In the Firebox RADIUS configuration, specify the server IP address and shared secret.
n Add RADIUS users or groups in the Firebox configuration.
n Add RADIUS user names or group names to Firebox policies.

Authentication
RADIUS Single Sign-On

To authenticate a user with RADIUS single sign-on (SSO):
n The user's computer, known as the RADIUS client or supplicant, sends an authentication request to the
authenticator.
The authenticator is a network device configured for IEEE 802.1X port-based authentication. Usually this device
is a wireless access point or switch on your internal network.
n After the 802.1X process completes, the RADIUS server sends the Firebox a copy of its accounting messages.
n The Firebox creates user sessions.
For RADIUS SSO to operate, the RADIUS Start, Stop, and Interim-Update accounting messages sent by the RADIUS
client must include these attributes:
n User-Name — The name of the authenticated user

n Framed-IP-Address — The client IP address of the authenticated user
Because the authenticator communicates with the RADIUS server to authenticate a user, it is optional to add the
RADIUS server to your Firebox configuration. However, we recommend that you add the RADIUS server to the Firebox
so you can create users and groups for use in Firebox policies.
RADIUS SSO and Active Directory SSO

You can enable both RADIUS SSO and Active Directory SSO at the same time. A RADIUS SSO session cannot
replace an existing session created by Active Directory SSO for a user at the same IP address.
To avoid any inconsistencies, we recommend that you do not enable both for users on the same subnet or IP range. If
for some reason you must enable both types of SSO for the same subnet, you can add IP addresses to the Exception
List in the RADIUS SSO or Active Directory SSO settings to make sure the intended authentication method is used
from a specific IP address.
RADIUS SSO and the Authentication Portal

After a user authenticates with RADIUS SSO, that user or another user can authenticate from the same IP address to
the Authentication Portal, and can select a different domain. If a user is authenticated to the Firebox with RADIUS SSO
and another user authenticates from the same IP address to the Authentication Portal, the Authentication Portal session
replaces the RADIUS SSO session. If a user is authenticated to the Firebox through the Authentication Portal and
another user tries to authenticate from the same IP address with RADIUS SSO, the second session with RADIUS
SSO is not created.

Authentication
SecurID Authentication Servers

SecurID is an authentication method that supports multi-factor authentication (MFA).
When you configure a RADIUS authentication server on the Firebox, you can select whether the server uses
RSA SecurID. Your users must have an approved SecurID token and a personal identification number (PIN).
For more information about SecurID, see the documentation provided by RSA.

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.

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.

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.

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.
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, see Mobile VPN Additional Resources.

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.

Mobile VPN
Mobile VPN Types

Fireware supports four types of mobile VPNs.

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, see Fireware Help.

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:
Authpoint Active Firebox (Firebox-DB)

Mobile VPN 1 Directory LDAP RADIUS SecurID Local Authentication
Mobile VPN Yes Yes2 No Yes No Yes

with IKEv2
Mobile VPN Yes Yes2 No Yes No Yes

with L2TP
Mobile VPN Yes Yes Yes Yes Yes Yes

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.
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.

Mobile VPN
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.
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 L2TPv2 VPN client.
any L2TPv2 client that client that complies with RFC
complies with RFC 2661. 2661.
SSL Users authenticate to the Users authenticate to the Users must install an OpenVPN client.
Firebox to download and Firebox to download and install Users can authenticate to the Firebox
install the client and the client and configuration. to download the Mobile VPN with SSL
configuration. client configuration file to import to the
The client computer must
OpenVPN client.
The client computer must support TLS 1.1 or higher.
support TLS 1.1 or higher.
IKEv2 Firebox administrators can Firebox administrators can Android

download a .bat script from download a .mobileconfig
User must install the third-party
the Firebox to configuration profile from the
strongSwan app. Firebox
automatically configure the Firebox to automatically
administrators can download a .sswan
native IKEv2 VPN client.* configure the native IKEv2 VPN
file from the Firebox to automatically
client.
configure the strongSwan app.
iOS
Firebox administrators can download a

.mobileconfig configuration profile from
the Firebox to automatically 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, see Fireware Help.

Mobile VPN
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 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.

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.
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.
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
AES-GCM: 128-bit, 192-bit, or 256-bit

Mobile VPN
Mobile VPN with L2TP

We recommend Mobile VPN with L2TP only for users with legacy operating systems that do not support IKEv2, or
when you cannot install client software on any platform.
Security
You can select a pre-shared key or a certificate for endpoint verification.
Mobile VPN with L2TP supports local authentication on the Firebox (Firebox-DB) and RADIUS authentication servers.
L2TP is not secure when the Enable IPSec option is disabled. Keep this option enabled.
Performance
Mobile VPN with L2TP is faster than Mobile VPN with SSL, but slower than Mobile VPN with IKEv2.

Users can connect with native clients on most operating systems. However, manual configuration is required unless
you deploy through Group Policy or other scripted methods. For scripted deployment through third-party software,
consult the documentation provided by the software vendor.
Connection Settings
Mobile VPN with L2TP uses these ports, protocols, and encryption algorithms to establish a connection:
Required ports UDP port 1701
UDP 500 and ESP for IKE
UDP 500 and 4500 for NAT-T
Transport and authentication protocols L2TP (Layer 2 Tunneling Protocol)
IPSec (Internet Protocol Security)
IKE (Internet Key Exchange)
Authentication: MD5, SHA-1, SHA2-256, SHA2-384, SHA2-512
Encryption protocols DES, 3DES, AES
Encryption strength DES (56-bit) and 3DES (168-bit)

Mobile VPN
AES: 128-bit, 192-bit, or 256-bit

Mobile VPN
Mobile VPN with SSL

We recommend Mobile VPN with SSL when IKEv2 IPSec traffic is not allowed on the remote network or when split
tunneling is required.
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
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.
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.

Mobile VPN
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.

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 or the Firebox portal. We recommend that users
download the client from the WatchGuard website. When you direct users to the WatchGuard website, you can be sure
they always download the latest version. Also, users do not see the SSL security alert that they see on the Firebox
portal (if the Firebox has a self-signed certificate).
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

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.

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. For example, 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.
Make sure the settings you configure on the Firebox match the settings on the VPN client.
DNS
In the configuration for each mobile VPN type, you can specify which DNS or 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 Firebox global
DNS or 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 DNS or WINS settings
from the Firebox. You must specify DNS or WINS settings on the client.
n Assign these settings to mobile clients — VPN clients use the DNS or WINS servers you specify here.

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 L2TP Firewall Policies

When you enable Mobile VPN with L2TP, the Firebox creates these policies:
n WatchGuard L2TP — An L2TP policy that allows connections from an L2TP client on UDP port 1701.
n Allow-IKE-to-Firebox — A hidden IPSec policy that allows VPN connections to terminate on the Firebox.
n Allow L2TP Users — An Any policy that allows the groups and users you configured for L2TP 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 Any policy
and create new policies that enable more limited access.
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, see 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.

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.

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), and WG

IKEv2.sswan (Android)
n Certificates — rootca.crt and rootca.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, see 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.
For computers with Windows 7, you must manually configure the native IKEv2 client. The
automatic configuration script is not supported.

Mobile VPN

Mobile users must manually configure the native VPN client of the client OS to connect with L2TP. Or, you can use
Group Policy to create VPN adapters and automatically push them to user computers. We do not provide a client
configuration file for L2TP connections.
For information about Group Policy, see the Microsoft documentation.
Mobile VPN with SSL

When you configure Mobile VPN with SSL, a client configuration file is automatically created and saved on the Firebox.
Users can download the Mobile VPN with SSL client from 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.

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.
If you require split tunneling, we recommend that you use Mobile VPN with SSL. To configure split tunnel, in the
Mobile VPN with SSL configuration, select Allow access to all Trusted, Optional, and Custom networks or
Specify allowed resources. In the Mobile VPN with SSL configuration, you can also manually specify tunnel
routes. These routes are required for BOVPN access through the SSL VPN. This configuration is another type of
split tunneling.
The Firebox supports connections from Mobile VPN with IKEv2 and Mobile VPN with L2TP clients configured for
split tunneling. However, you must manually configure IKEv2 and 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 IKEv2 and L2TP clients. See the documentation
provided by your VPN client vendor.
For both default route and split tunnel, we recommend that each client computer has security
software. For example, anti-virus software and WatchGuard Threat Detection and Response
(TDR) 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.

Mobile 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.

Branch Office VPN
Branch Office VPN

A branch office Virtual Private Network (BOVPN) enables secure, encrypted connections between networks at
geographically separated locations.
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 BOVPN over TLS
n Topologies
For a list of additional resources on these topics, see BOVPN Additional Resources.

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.

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.

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, see 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.

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 metric
Virtual with the highest priority to the destination. You assign a route metric from 1 to 254 to each BOVPN
Interface virtual interface route. A route metric 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 send
over TLS 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:

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 see 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.

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, see 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.

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.

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. This is especially true
for T55 and T70 Fireboxes, which do not have a hardware crypto chip. 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
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.

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

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 and 20. 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 or 20.
For more information about Diffie-Hellman Groups, see 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.

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.

Branch Office VPN
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 and 20) 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.

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.

Branch Office VPN

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.

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
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). Both AH and ESP encrypt the data and protect 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.

Branch Office VPN
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.
4. 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.
Phase 1
Setting IKEv1 IKEv2
Modes Main or Aggressive Only one mode
NAT Traversal Can be enabled or Always enabled

disabled
IKE Keep- Supported Not supported

Alive*
Dead Peer Can be enabled or Always enabled

Detection disabled
(DPD) Can be traffic-based or time-based (as
Always traffic-based described in RFC 3706):
n Traffic-Based — the Firebox sends

a DPD message only if no traffic is
received from the remote gateway
for a specified length of time 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 None Transform settings are shared for all

Settings dynamic endpoints and Mobile VPN with
IKEv2. Shared settings include:
n NAT Traversal Keep-Alive interval

Branch Office VPN
Phase 1
Setting IKEv1 IKEv2
n Phase 1 transforms
*This is an obsolete setting. We recommend DPD in all cases for reliability, performance, and scalability.

Branch Office VPN
BOVPN Configuration
You can configure these types of BOVPNs on the Firebox:
n Manual BOVPN
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, see 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.

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. See 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).

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)

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.

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:

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

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, see 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, see the
Link Monitor section of this guide.

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.

Branch Office VPN
Each gateway address pair must be listed in the same order in the Gateway Endpoints list on both Fireboxes.

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
n SD-WAN
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:

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, see Fireware
Help.

Branch Office VPN
Examples
In this section, we briefly show three common uses for BOVPN virtual interfaces. For detailed configuration examples,
see 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 metric of 10 has a higher priority
than a route with a metric 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 metric 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.

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 metric 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 metric (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 metric (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
SD-WAN
You can configure SD-WAN actions that specify BOVPN virtual interfaces. In a policy, you select the SD-WAN action
you want to apply. SD-WAN actions force traffic in the policy to use the interfaces defined in the SD-WAN action.
If you select loss, latency, and jitter measures in an SD-WAN action, connections fail over if the values you specified
for those measures are exceeded. If you do not select any metrics in an SD-WAN action, connections fail over only if
the interface is inactive.

Branch Office VPN
For example, your company has VoIP traffic between two sites. You want users to experience high-quality, reliable
voice calls over a secure connection. To achieve these goals, you dedicate an MPLS link to VoIP traffic. You send other
site-to-site traffic, such as FTP, over a BOVPN virtual interface tunnel. If network issues such as high loss, latency,
and jitter occur on the MPLS link, VoIP traffic fails over to the BOVPN virtual interface.
This diagram shows two external connections: an MPLS connection for VoIP traffic, and a BOVPN virtual interface
connection for all other traffic.
For added security, you could also configure a BOVPN virtual interface connection over the MPLS connection.
For more information about SD-WAN, see Software-Defined WAN (SD-WAN) in the Network Settings section of this
guide.

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, see 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

Branch Office VPN
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.
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:

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:

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:

Branch Office VPN

Branch Office VPN
In the Site B configuration, specify testID as the local gateway ID:

Branch Office VPN

Branch Office VPN
BOVPN over TLS
Use BOVPN over TLS only when an IPSec VPN tunnel is not an option.
BOVPN over TLS is an alternative type of site-to-site BOVPN.
We recommend BOVPN over TLS only when an IPSec VPN tunnel is not an option. For example, if you are the network
administrator for a shopping mall kiosk, you might not control the upstream network provided by the mall. If the mall
network does not allow IPSec traffic, you can still use a VPN if you enable BOVPN over TLS. Like HTTPS traffic,
which is allowed on most networks, BOVPN over TLS uses port 443.
BOVPN over TLS uses a client-server model for communication. On a Firebox configured in Server mode, you can
configure tunnels to one or more Fireboxes configured in Client mode. On a Firebox configured in Client mode, you can
configure tunnels to one or more Fireboxes configured in Server mode. You cannot configure a Firebox in both Server
and Client mode. Third-party VPN endpoints are not supported.
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. IPSec BOVPNs perform better than BOVPN
over TLS implementations.

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.

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.

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.

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.
View VPN Diagnostic Messages

If the BOVPN tunnel cannot be established, WatchGuard System Manager shows a VPN diagnostic message for the
gateway:

Branch Office VPN
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
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.

Branch Office VPN
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.

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.

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 metric 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.

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

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.

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:
n Partners — Log in to the Learning Center and go to Technical Training > Network Security > Network
Security Essentials.
n End users — Go to the Courseware page in WatchGuard Support Center.
For a list of additional resources for each section of this guide, see:
n Firebox Setup and Management Additional Resources

n Logging and Monitoring 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

Firebox Setup and Management Additional

Resources
The resources below provide more information about topics covered in the Firebox Setup and Management section of
this guide.
To see the videos:
Set Up a New Firebox

Video:
n Firebox Setup: Factory Default Settings

n Firebox Setup: Web Setup Wizard
Help Center:
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

Video:
n WSM vs Web UI for Configuration Management
Help Center:
n Administer the Firebox from Policy Manager

n About Fireware Web UI
n Fireware Command Line Interface Reference
Configuration Files and Backup Images

Video:
n Configuration File and Backup Image
Help Center:
n Firebox Backup and Restore

n Firebox Upgrade, Downgrade, and Migration

Role-based Administration
Video:
n Role-based Administration
Help Center:
n About Role-Based Administration

n Manage Users and Roles on Your Firebox
n About Predefined Roles
Feature Keys
Video:
n Firebox Feature Keys
Help Center:
n About Feature Keys
Upgrade a Firebox
Video:
n Upgrade a Firebox
Help Center:
n Firebox Upgrade, Downgrade, and Migration
Default Threat Protection

Video:
Help Center:

n About Blocked Ports
n About Blocked Sites
Global Settings and SNMP

Video:
n Global Settings, NTP, and SNMP
Help Center:
n Define Firebox Global Settings

n About Policies for Firebox-Generated Traffic
n Enable NTP and Configure NTP Servers

Policies Overview
Help Center:
n Add Policies to Your Configuration

n Create or Edit a Custom Policy Template

Logging and Monitoring Additional Resources

The resources below provide more information about topics covered in the Logging and Monitoring section of this guide.
To see the videos:
Logging and Notification

Help Center:
n About Firebox Logging and Reporting
Monitoring with Firebox System Manager

Video:
n Monitoring in Firebox System Manager

n Network Diagnostic Tasks in Firebox System Manager
Help Center:
n Monitor your Firebox with Firebox System Manager (FSM)
Monitoring with Fireware Web UI

Video:
n Monitoring and Diagnostic Tools in Fireware Web UI
Help Center
n Monitor your Firebox with Fireware Web UI
Firebox Visibility with WatchGuard Cloud

Video:
n Visibility: Add a Firebox to WatchGuard Cloud
Help Center:
n Device Visibility in WatchGuard Cloud
Set Up Dimension for Firebox Logging

Video:
n Set Up Firebox Logging to Dimension
Help Center:
n Add a Dimension or WSM Log Server

Traffic Monitor and Logs

Video:
n Monitoring and Diagnostic Tools in Fireware Web UI
Help Center:
n Device Log Messages (Traffic Monitor)

Network Settings Additional Resources

The resources below provide more information about topics covered in the Network Settings section of this guide.
To see the videos:
Network Routing Modes

Video:
n Network Routing Modes

n Mixed Routing Modes and WINS/DNS
n Static Routing Basics
Help Center:
n Routes and Routing

n Create a Network Bridge Configuration
n Add a Secondary Network IP Address
n About DNS on the Firebox
Interfaces
Video:
n Aliases, Interfaces, and Policies
Help Center:
n About Network Modes and Interfaces

n Common Interface Settings
VLANs
Video:
n VLANs (Part 1): An Introduction

n VLANs (Part 2): Configure VLANs
n VLANs (Part 3): Logging and Monitoring
Help Center:
n About Virtual Local Area Networks (VLANs)
Multi-WAN
Video:

n Multi-WAN (Part 1): Link Monitoring

n Multi-WAN (Part 2): Methods

Help Center:
n About Multi-WAN
SD-WAN
Video:
n Multi-WAN (Part 3): SD-WAN
Help Center:
n About SD-WAN
NAT
Video:
n Dynamic NAT (Part 1): Introduction

n Dynamic NAT (Part 2): Configuration
n Dynamic NAT (Part 3): Secondary IP Addresses and DNAT
n Static NAT (Part 1): Introduction
n Static NAT (Part 2): Secondary IP Addresses
n Static NAT (Part 3): Port Address Translation
n 1-to-1 NAT
Help Center:
n NAT (Network Address Translation)
Traffic Management and Quality of Service (QoS)

Video:
n Traffic Management
n QoS
Help Center:
n About Traffic Management and QoS

Firewall Policies Additional Resources

The resources below provide more information about topics covered in the Firewall Policies section of this guide.
To see the videos:
Policy Source and Destination

Video:
n Firewall Policies Overview

n Policy From and To Fields
Help Center:
n About Policy Properties

n About Aliases
n Add Policies to Your Configuration
Management Policies
Help Center:
Limit Policy Scope

Help Center
n Firebox Configuration Best Practices
Policy Precedence
Video:
n Policy Precedence and Ordering
Help Center:
n About Policy Precedence
Hidden Policies
Help Center:
n About Policies for Firebox-Generated Traffic
Policy Logging and Notification

Video:

n Policy Logging Settings
Help Center:
n Configure Logging and Notification for a Policy

n Set Logging and Notification Preferences
Policy Schedules
Video:
n Policy Schedules
Help Center:
n Create Schedules for Firebox Actions

n Set an Operating Schedule
Packet Filters and Proxy Policies

Video:
n Firewall Policies Overview
Help Center:
n About Policies
n About Proxy Policies and ALGs

Security Services Additional Resources

The resources below provide more information about topics covered in the Security Services section of this guide.
To see the videos:
Security Services Overview

Video:
n WatchGuard Security Services - Best in Breed

n Packet Filter Policies and Security Services
n Proxies and Security Services
Help Center:
n Manage Security Services

n Subscription Service Update Server
Globally Configured Security Services

Video:
Help Center:
n About Botnet Detection

n About DNSWatch
n DNSWatch DNS Settings Precedence

Video:
Help Center:
n About Intrusion Prevention Service

n Configure Intrusion Prevention
Application Control
Video:
n Application Control (Part 1): Application Control Actions

n Application Control (Part 2): Application Control in Policies

Help Center:
n About Application Control

n Configure Application Control Actions
Geolocation
Video:
Help Center:
n About Geolocation
n Configure Geolocation

Proxies and Proxy-Based Services Additional

Resources
The resources below provide more information about topics covered in the Proxies and Proxy-Based Services section
of this guide.
To see the videos:
Proxies and Proxy Actions

Video:
n Proxy Policies and Proxy Actions
Help Center:
n About Proxy Policies and ALGs

n About Proxy Actions
n About Rules and Rulesets
AntiVirus Scanning and Proxies

Video:
n Gateway AV and IntelligentAV in Proxies
Help Center:
n Enable Gateway AntiVirus

n Configure Gateway AntiVirus Actions
APT Blocker
Video:
n APT Blocker
Help Center:
n About APT Blocker
n Configure APT Blocker
n Monitor APT Blocker Activity

SMTP-proxy
Video:
n SMTP Proxy
Help Center:
n About the SMTP-Proxy
spamBlocker
Help Center:
n About spamBlocker
HTTP Proxies
Video:
n HTTP Proxy (Part 1): Configure Proxy Settings

n HTTP Proxy (Part 2): Log Messages
Help Center:
n About the HTTP-Proxy
HTTP-proxy and WebBlocker

Video:
n WebBlocker
Help Center:
n About WebBlocker
n Configure WebBlocker
HTTPS-proxy
Video:
n HTTPS Proxy UI and Settings

n HTTPS Proxy Content Inspection (Part 1 - Part 4)
Help Center:
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

Video:
n Content Actions and Domain Name Rules
Help Center
n About Content Actions

n HTTP Content Action and Domain Name Rule Examples

Authentication Additional Resources

The resources below provide more information about topics covered in the Authentication section of this guide.
To see the videos:
Video:
n Authentication (Part 1): Authentication Servers Overview

n Authentication (Part 3): Firebox Authentication Portal
n Certificates
n Understand Certificate Errors for Connections to a Firebox (Part 1 and 2)
Help Center:
n Define a New User for Firebox Authentication

n How RADIUS Server Authentication Works
n Configure RADIUS Server Authentication
n Configure MFA for a Firebox
n Configure SecurID Authentication
n Configure LDAP Authentication
n Configure VASCO Server Authentication
n Define or Remove Users or Groups
n Define a New User for Firebox Authentication
n Use Authentication to Restrict Incoming Connections (Firebox Authentication Portal)
n User Authentication Steps (Firebox Authentication Portal)
Users and Groups in Policies

Video:
n Authentication (Part 2): User and Groups in Policies
Help Center:
n Use Users and Groups in Policies

Mobile VPN Additional Resources

The resources below provide more information about topics covered in the Mobile VPN section of this guide.
To see the videos:
Mobile VPN Introduction

Video:
n Fireware Mobile VPN Solutions Overview

n Mobile VPN Routing
Help Center:
n Mobile VPN Tunnels

n Select a Mobile VPN Type

Video:
Help Center:

Video:
Help Center:
Mobile VPN with SSL

Video:
n Mobile VPN with SSL (Part 1): VPN Configuration

n Mobile VPN with SSL (Part 2): Deployment and Client Connection
Help Center:

BOVPN Additional Resources

The resources below provide more information about topics covered in the Branch Office VPN section of this guide.
To see the videos:
BOVPN Introduction
Video:
n BOVPN (Part 1): Introduction
Help Center:
n Manual Branch Office VPN Tunnels

n Managed Branch Office VPN Tunnels (WSM)
BOVPN Configuration
Video:
n BOVPN (Part 2): Configuration

n BOVPN (Part 3): Dynamic Public IP Address
Help Center:
n Quick Start - Set Up a VPN Between Two Fireboxes

n Configure Manual BOVPN Gateways
n Configure Manual BOVPN Tunnels
BOVPN Virtual Interfaces
Video:
n BOVPN over TLS and BOVPN Virtual Interfaces
Help Center:
n BOVPN Virtual Interfaces
BOVPN and NAT
Video:
n BOVPN (Part 4): 1-to-1 NAT

n BOVPN (Part 5): Dynamic NAT
Help Center:
n BOVPN and Network Address Translation

BOVPN over TLS
Video:
n BOVPN over TLS and BOVPN Virtual Interfaces
Help Center:
n About Branch Office VPN over TLS

About the Network Security Essentials Exam

The Network Security Essentials exam tests your knowledge of basic networking and how to configure, manage, and
monitor a WatchGuard Firebox. This exam is appropriate for network administrators who have experience configuring
and managing Firebox devices that run Fireware v12.7.
Key Concepts
To successfully complete the Network Security Essentials 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

Exam Description
Content
70 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 video course or instructor-led course 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.7 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
training classes for partners. WatchGuard end-users can register for a class with our network of WatchGuard Certified
Training Partners (WCTPs).
n Partners — Register for training here (login required)

n End-users — View the current WCTP training schedule on the WatchGuard website

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.
The Network Security Essentials video course is available on the WatchGuard Portal (login required).
To see the videos:
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. 10%
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 complete 10%
Setup 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
Monitoring, Understand how to use management tools to monitor or troubleshoot a Firebox. 15%
Logging, and
Reporting 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. 25%
NAT
n Network interface types, security zones, and settings
n WINS/DNS
n Routing and static routes
n NAT types and configuration
n DHCP
n VLANs
n Multi-WAN and SD-WAN actions
Policies, Proxies, Understand how to configure Firebox policies, proxies, and security services. 25%
and Security
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

Category Knowledge Areas Weight
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 Firebox authentication portal
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

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 on
the last page.
Questions
1. Which of these is a default Class B subnet mask? (Select one.)
a. /8
b. /12
c. /16
d. /24
e. /28
2. 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
3. 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.
4. 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

5. What port and protocol is used by DNS? (Select one.)

a. UDP/67
b. UDP/53
c. TCP/20
d. TCP/25
6. What is the purpose of the policy shown in this image? (Select one.)
a. To allow clients on an external network to connect to a secure web server on a trusted or optional
network using its public IP address
b. To allow clients on your trusted network to connect to a secure web server on a trusted or optional
network using its private IP address
c. To allow clients on your trusted network to connect to a secure web server on a trusted or optional
network using its public IP address
d. To allow clients on an external network to connect to a secure web server on a trusted or optional
network using its private IP address

7. 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
8. 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
9. You can use the TCP-UDP proxy to control Web, FTP, and SIP traffic on ports other than 80, 21, and 5060.
a. True
b. False

10. Which authentication servers can be used with any type of Mobile VPN (Select two.)
a. Firebox-DB
b. Active Directory
c. RADIUS
d. LDAP

Answers
Note: Many exam questions test knowledge in more than one area.
1. c. A class B subnet mask is 255.255.0.0, which is 16 bits, and is represented in slash notation as /16.
2. c. The WatchGuard Authentication policy allows users to connect to the Authentication Portal from the trusted or
optional networks.
3. d. Yes, the Outgoing policy allows this traffic.
4. b. False. Dynamic NAT applies only to outgoing connections.
5. b. DNS uses UDP port 53.
6. c. This is an example of NAT loopback.
7. b. Phase 2 authentication is configured in the BOVPN Tunnel settings.
8. 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.
9. a. True. The TCP-UDP proxy applies to TCP and UDP traffic on any TCP or UDP port.
10. a and c. Only Firebox-DB and RADIUS are supported by all Mobile VPN types.

Network Security Essentials Study Guide

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Network Security Essentials Study Guide

Uploaded by

Copyright:

Available Formats

Training

Network Security Essentials

Guide Revised For: Fireware v12.7

Copyright and Patent Information

Network Security Essentials Study Guide 3

4 WatchGuard Technologies, Inc.

Network Security Essentials Study Guide 5

6 WatchGuard Technologies, Inc.

Network Security Essentials Study Guide 7

How to Use This Study Guide

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.

Network Security Essentials Study Guide 8

9 WatchGuard Technologies, Inc.

Firebox Setup and Management

In this section you learn about:

n Firebox activation and setup wizards

Network Security Essentials Study Guide 10

Set Up a New Firebox

The setup wizards configure:

n Passphrases for administrative user accounts

To activate your Firebox, you must have:

n An account on the WatchGuard website — To create a new WatchGuard account, go to

11 WatchGuard Technologies, Inc.

Default Interface Settings

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

Ethernet 1 (Eth1) n Trusted interface

Ethernet 2 (Eth2) and n Optional interfaces

Ethernet 24 (Eth24) — n Trusted interface

Network Security Essentials Study Guide 12

Ethernet 32 (Eth32) — n Trusted interface

Web Setup Wizard

Quick Setup Wizard

13 WatchGuard Technologies, Inc.

To run either setup wizard you need:

download the feature key from WatchGuard.

Network Security Essentials Study Guide 14

Other Configuration Methods

These options are not covered in this training.

Default Policies and Services

Enabled Services (if licensed in the feature key)

15 WatchGuard Technologies, Inc.

Network Security Essentials Study Guide 16

Firebox Management Tools

n WatchGuard System Manager > Policy Manager

WatchGuard System Manager

In WSM, you can:

17 WatchGuard Technologies, Inc.

Fireware Command Line Interface

Network Security Essentials Study Guide 18

Configuration Files and Backup Images

19 WatchGuard Technologies, Inc.

n You connect directly to the Firebox to make configuration changes.

Network Security Essentials Study Guide 20

A backup image includes:

Automatic Backups with OS Upgrades

n Policy Manager — File > Backup and Restore

21 WatchGuard Technologies, Inc.

Export a Backup Image

Restore a Backup Image

Network Security Essentials Study Guide 22

Default User Account Default Role Default Passphrase

admin Device Administrator (read-write permissions) readwrite

status Device Monitor (read-only permissions) readonly