Network Security Essentials Study Guide Local EN-US-strony-100-200-ANG

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

n Establish a failover sequence for those interfaces.
Network Security Essentials for Locally-Managed Fireboxes Study Guide 100

Network Settings
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.
SD-WAN Failover — If the SD-WAN Failover 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.
SD-WAN Round-Robin — The Firebox distributes traffic among qualified interfaces based the weight you
assign to each interface, the 3-tuple (source IP address, destination IP address, and protocol for packets), and
the metrics you specify. Connections are sticky, which means traffic from the same source to the same
destination using the same protocol is always routed through the same interface. If no interfaces are qualified,
the Firebox routes traffic to the first active (up) interface, which is the first active interface listed in the SD-WAN
action configuration. If no interfaces are active, the Firebox drops packets that match the SD-WAN action. If an
interface becomes active or qualified again, it automatically becomes available for Round Robin selection.
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.

Network Settings
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.
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:
Method
Specifies the SD-WAN method. You can select Failover or Round-Robin.
If you select Failover, the Firebox fails over connections to a different interface if the current interface exceeds
the measurement values that you specify.
If you select Round-Robin, which is the load balancing method, the Firebox splits outgoing traffic between
multiple interfaces based on weight and other factors. For traffic that matches the SD-WAN Round-Robin
action, the Firebox considers these factors to determine the outgoing interface:
n Weight — A weight value that you assign to each interface in an SD-WAN action
n 3-tuple — Source IP address, destination IP address, and protocol for packets handled by an SD-WAN
action
n Measures — Loss rate, latency, and jitter for each interface in an SD-WAN action
Interfaces
Specifies which interfaces participate in the action. You can include one or more of these interface types in
SD-WAN actions:

Network Settings
n External
n Internal (trusted, optional, or custom) — Internal interfaces include those configured for private
network connections such as leased lines and MPLS links.
n BOVPN virtual interface
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.
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.

Network Settings
You can specify the same SD-WAN action in multiple policies.

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.

Network Settings
About Static NAT Source IP Addresses

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

When you configure static NAT, the static NAT configuration is saved in a SNAT action. You can create or edit a
SNAT action when you create or edit a policy. Or you can select Setup > Actions > SNAT to add, edit, or delete
SNAT actions. After you have created a SNAT action, you can use the same action in one or more policies.
Server Load Balancing requires Fireware with a Pro upgrade and is not supported on Firebox
T10, Firebox T15, XTM 2 Series, and 3 Series devices.
There are two types of SNAT actions:
Static NAT
A static NAT action forwards inbound traffic addressed to one IP address to a different IP address and port
behind the firewall. You can specify an FQDN in a SNAT action in addition to an IP address.
Server Load Balancing

A server load balancing SNAT action forwards inbound traffic addressed to one IP address to one of several
servers behind the firewall. In the SNAT action, you select the load balancing algorithm to use. Optionally, you
can assign different weights to each server.
To use static NAT, you add a static NAT action to the To section of the policy that handles each type of inbound
traffic. To implement static NAT for the diagram above, you would add a different static NAT action to the FTP, SMTP,
and HTTP policies that handle the inbound traffic to each of the three servers.
You can combine SNAT with the Set Source IP option for dynamic NAT (DNAT) to perform
the same function as 1-to-1 NAT. With this configuration, you can still use the public IP
address for other purposes.

Network 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.
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.
In this section you learn about:
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
(DNS lookup) the alias.
FQDN (Fully Qualified Performs forward DNS resolution and analyzes DNS replies for the specified FQDN
Domain Name) (includes wildcard domains). Resolved IP addresses from the primary domain and any
subdomains are added to the alias.
Tunnel address Defined by a user or group, address, and name of the tunnel.
Custom address Defined by a user or group, address, and Firebox interface.
Another alias Any other alias.
User or group An authorized user or group.
FQDN
You can use FQDNs to specify a specific host domain (host.example.com) or a wildcard domain
(*.example.com). For example, the wildcard domain *.example.com includes:
a.example.com
b.example.com
a.b.example.com
You can also use subdomain wildcards, such as:
*.b.example.com
*.b.c.example.com
*.b.c.d.example.com
You can use FQDNs in:
n Source (From) and destination (To) lists in a policy

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

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:

Firewall Policies
Packet Filter Proxy and ALG
Source
IP Header Destination
Port(s)/Protocols
Packet body
Attachments/Files
Packet Content
RFC compliance
Commands
Packet filters are an easy way to allow or deny large amounts of traffic. Proxies can prevent potential threats from
reaching your network without blocking the entire connection. The Firebox configuration includes default sets of rules,
called proxy actions, for each type of proxy policy. You can use the default settings for each type of proxy action, or
you can customize them.
At a high level, this is how each type of policy operates:
Packet Filter Policy

n Examines the IP header of each packet at the network and transport protocol packet layers.
n If the packet header information is legitimate and the content of the packet header matches a packet filter
policy that allows traffic, the Firebox allows the packet.
n Otherwise, the Firebox drops the packet.
Proxy Policy or ALG (Application Layer Gateway)

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

Firewall Policies
n DNS
n Explicit Proxy
n FTP
n H323 (ALG)
n SIP (ALG)
n HTTP
n HTTPS
n SMTP
n POP3
n IMAP
n TCP-UDP (TCP and UDP on all ports)
The FTP packet filter and proxy policies do transparent connections management for the
FTP data channel. The FTP policy is configured for TCP port 21, which is used for the
FTP handshake. The FTP policy dynamically opens another negotiated port for data transfer.

Security Services
Security Services
Security services extend the built-in defenses of your Firebox to help you secure your network.
In this section you learn about:
n How security services work to protect your network

n Services in the Basic and Total Security Suites
n Services enabled in packet filters and proxy policies
n Security service signature updates
n Botnet Detection
n DNSWatch
n Intrusion Prevention Service (IPS)
n Application Control
n Geolocation
n Tor Exit Node Blocking
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.
Tor Exit Node Blocking

Blocks known Tor exit node IP addresses.
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 Portal1
Application Control
APT Blocker
Botnet Detection
Data Loss Prevention2
DNSWatch
Gateway AntiVirus
Geolocation
IntelligentAV1

Security Services
Features and Services Basic Security Suite Total Security Suite
Intrusion Prevention Service
spamBlocker
Threat Detection and Response
WebBlocker
Support Standard (24× 7) Gold (24×7)
1 Available on Firebox T40, T45, T80, and T85, Firebox M Series devices (except M200/M300), Firebox Cloud, and
FireboxV.
2 Not available on Firebox T20, T25, T40, T45, T80, T85, M290, M390, M590, M690, M4800, and M5800 devices.
Signature Updates
The Gateway AntiVirus, Intrusion Prevention Service, Application Control, Data Loss Prevention, Botnet Detection,
and Geolocation security services use a frequently-updated set of signatures to identify the latest viruses, threats,
and applications. IntelligentAV does not use signatures to identify viruses, but does need to download occasional
updates. You can manually get the latest signatures or updates for these services from the Subscription Services
tab in Firebox System Manager or Fireware Web UI.
Tor Exit Node Blocking uses a database of known Tor exit node IP addresses from Reputation Enabled Defense
(RED). You can manually get the latest updates for this service from the Subscription Services page in Fireware
Web UI.
If the signatures on the Firebox are not current, you are not protected from the latest viruses and intrusions. To make
sure that you always have the latest signature updates, configure all signature-based services to update signatures
automatically. To do this, click Update Server when you configure the service, then select the signatures you want to
update automatically.
To make sure that the Firebox can connect to the update server, you must add at least one DNS server to your
network configuration. The Firebox uses DNS to resolve the update server URL to an IP address.
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:

Security Services
n Application Control
n Geolocation
n Intrusion Prevention Service
n Tor Exit Node Blocking
You can enable these security services in proxy policies only:
Security Service Supported Proxy Policies
APT Blocker HTTP, HTTPS, SMTP, POP3, IMAP, FTP
Data Loss Prevention HTTP, HTTPS, SMTP, FTP
Gateway AntiVirus/IntelligentAV HTTP, HTTPS, SMTP, POP3, IMAP, FTP, TCP-UDP
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.

Security Services
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
Intrusion Prevention Service

The Intrusion Prevention Service (IPS) includes a set of signatures associated with specific commands that could be
harmful, as well as patterns for known software exploits. IPS compares traffic to these signatures to identify intrusion
attacks.
When a new intrusion threat appears on the Internet, the features that make the intrusion unique are recorded as a
signature. To make sure that you always have the latest IPS signatures, enable automatic signature updates.
You configure the Intrusion Prevention Service globally. When you enable IPS, it is enabled for
all policies by default. You can selectively disable it for specific policies, if needed. We
recommend that you disable IPS on default Firebox management policies, such as the
WatchGuard Web UI policy.
IPS Scan Modes

IPS can operate in one of two scan modes.
Full Scan
IPS scans all packets within connections handled by policies with IPS enabled. This mode is the most secure
because it catches evasion techniques, but there is a performance trade-off.
Fast Scan
IPS scans fewer packets within each connection to improve performance. This option greatly improves the
throughput for scanned traffic, but does not provide the comprehensive evasion coverage of Full Scan mode.
We recommend you use the Full Scan mode in most environments.
IPS Threat Levels and Actions

IPS groups signature threats into five threat levels: Critical, High, Medium, Low, and Information. When you enable
IPS, you can configure the action that the Firebox takes for content that matches IPS signatures at different threat
levels.
The actions IPS can take for each threat level are:
n Allow — Allows the content, even if it matches an IPS signature.

n Drop — Drops the content and drops the connection. No information is sent to the sender.
n Block — Blocks the packet, and adds the source IP address to the Blocked Sites list.

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 on
Fireboxes with a Basic or Total Security Suite subscription. 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.

Security Services
When Geolocation is enabled, traffic log messages show the destination or source of the
connection external to the Firebox.

Security Services
Tor Exit Node Blocking 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 Tor Exit
Node Blocking service.
Tor moves encrypted traffic across a network of Tor servers and provides anonymity to users. A Tor exit node is the
final node that routes Tor traffic to a destination. Because some Tor traffic can be malicious, you can use the Tor Exit
Node Blocking service to block inbound Tor exit node traffic to the Firebox.
You can enable or disable Tor Exit Node Blocking in the Botnet Detection settings. The service is enabled by default
and applies to all policies.

Security Services
Tor Exit Node Blocking and Policies

You can choose to enable or disable Tor Exit Node Blocking for a specific policy in the policy settings. This is because
you might not want to block Tor exit node traffic for legitimate reasons.
Tor Exit Node Blocking blocks inbound Tor exit node traffic only. It does not block outbound traffic from the Firebox to
Tor exit nodes. If you want to block outbound Tor exit node traffic, use Application Control.

Security Services

Proxies and Proxy-Based Services

You can use proxy policies to protect servers and clients from threats. Proxy policies examine the contents of each
packet to determine whether network traffic is safe and adheres to your network security and acceptable use policies.
Security services that examine the content of packets are configured in proxy policies.
In this section, you learn about:
n Proxy policies and services that require proxy policies

n Proxy actions
n Gateway AntiVirus and IntelligentAV
n APT Blocker
n 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 T40, T45, T80, T85, and M Series (except M200/M300)
n Virtual — Firebox Cloud and FireboxV (VM must have 4GB RAM)
If Data Loss Prevention is enabled, DLP scans happen after all antivirus scans are complete.
IntelligentAV and APT Blocker are covered in more detail in these sections:
n IntelligentAV
n APT Blocker
Gateway AntiVirus and Proxies

Gateway AntiVirus scans different types of traffic for different proxies:
n Email — With the SMTP-proxy, IMAP-proxy, or POP3-proxy, Gateway AntiVirus finds viruses encoded with
frequently used email attachment methods. These include base64, binary, 7-bit, 8-bit encoding, and
uuencoding.
n FTP — With the FTP-proxy, Gateway AntiVirus finds viruses in uploaded and downloaded files.
n Web — With the HTTP-proxy or HTTPS-proxy, Gateway AntiVirus scans web pages and any uploaded or
downloaded files for viruses.
To enable Gateway AntiVirus to scan HTTPS content, you must enable content inspection in the HTTPS-proxy and
select an HTTP proxy action with Gateway AntiVirus configured, and the AV Scan option selected in the proxy action
rules.
Configure Gateway AntiVirus Actions

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

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 T40, T45, T80, and T85, Firebox M Series (except M200/M300), Firebox Cloud,
and FireboxV. IntelligentAV does not scan files when Gateway AntiVirus is disabled or when the Gateway AntiVirus
feature key expires, even if IntelligentAV is enabled.
To use IntelligentAV with Firebox Cloud or FireboxV, the VM must have 4 GB or more RAM.
IntelligentAV Content Types
IntelligentAV can scan many file types, including Microsoft Office documents, PDF files, and Windows portable
executable (PE) files. For a full list of supported file types, see Fireware Help.

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.

When the spamBlocker service denies a message or tags a message as spam in Fireware 12.9 or higher, and in the
spamBlocker settings you enable the Firebox to send spam log messages, the Firebox generates a log message.
The log message contains the wgrd_spam_id item. You can use the information in the log message to send a false
positive or false negative report to WatchGuard. spamBlocker can generate a spamBlocker spam ID log
message for the SMTP, POP3, and IMAP proxies.
If you want to send a false positive or false negative report to WatchGuard, copy the spamBlocker spam log message
text, paste it in the body of an email, and in the subject line of the email type FP Report <company name> <date
of submission> or FN Report <company name> <date of submission>.
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.

Network Security Essentials Study Guide Local EN-US-strony-100-200-ANG

Uploaded by

Document Information

Original Title

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 Local EN-US-strony-100-200-ANG

Uploaded by

Copyright:

Available Formats

Network Settings

Select Configure to:

n Specify the interfaces that participate in failover.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 100

When an External Interface Fails

Network Security Essentials for Locally-Managed Fireboxes Study Guide 101

Multi-WAN Interface Overflow

Network Security Essentials for Locally-Managed Fireboxes Study Guide 102

When an External Interface Fails

Network Security Essentials for Locally-Managed Fireboxes Study Guide 103

Multi-WAN Round Robin

Current ratio of Current ratio of Current ratio of

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 Security Essentials for Locally-Managed Fireboxes Study Guide 104

Current ratio of Current ratio of Current ratio of

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

Calculate Weights for Round-robin

n Specify the interfaces that participate in Round-robin

Network Security Essentials for Locally-Managed Fireboxes Study Guide 105

Network Security Essentials for Locally-Managed Fireboxes Study Guide 106

When an External Interface Fails

Network Security Essentials for Locally-Managed Fireboxes Study Guide 107

Multi-WAN Routing Table

Network Security Essentials for Locally-Managed Fireboxes Study Guide 108

When an External Interface Fails

Network Security Essentials for Locally-Managed Fireboxes Study Guide 109

Monitor the physical link state

Monitor the logical link state

Network Security Essentials for Locally-Managed Fireboxes Study Guide 110

n Determine whether an interface can send traffic

Recommendations for Targets

Network Security Essentials for Locally-Managed Fireboxes Study Guide 111

Recommendations for Ping Targets

Recommendations for TCP Targets

Recommendations for DNS Targets

Probe Interval Settings

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

Network Security Essentials for Locally-Managed Fireboxes Study Guide 112

Network Security Essentials for Locally-Managed Fireboxes Study Guide 113

Routing Decisions Logic

n Whether the traffic is allowed out

To make these decisions, the Firebox considers these questions:

1. Does the packet match the From and To lists in a policy?

Network Security Essentials for Locally-Managed Fireboxes Study Guide 114

7. Does the policy To list specify the Any-External alias?

Network Security Essentials for Locally-Managed Fireboxes Study Guide 115

Multi-WAN Routing Decision Flow Chart

Network Security Essentials for Locally-Managed Fireboxes Study Guide 116

Network Security Essentials for Locally-Managed Fireboxes Study Guide 117

n Green means there is a physical link detected on the cable.

Network Security Essentials for Locally-Managed Fireboxes Study Guide 118

SD-WAN ignores the global multi-WAN configuration settings.

SD-WAN Routing Without Metrics