Firebox Configuration Best Practices

To protect your internal networks, your Firebox denies all packets that are not specifically allowed by a firewall policy. Each firewall policy defines a set of rules that tell the Firebox to allow or deny traffic based upon factors such as source and destination of the packet or the TCP/IP port or protocol used for the packet.

This topic includes:

Recommended Default Configuration

When you run the Web Setup Wizard or Quick Setup Wizard to set up a Firebox, the setup wizard automatically configures default firewall policies and enables licensed security services with recommended settings.

Setup wizards in more recent versions of Fireware configure the Firebox with the latest recommended configuration settings and services.

To set up a new Firebox with recommended default policies, run the Web Setup Wizard or Quick Setup Wizard to set up your Firebox with a basic configuration. For more information, go to About Firebox Setup Wizards.

The setup wizards add these default policies:

  • FTP-proxy, with the Default-FTP-Client proxy action
  • HTTP-proxy, with the Default-HTTP-Client proxy action
  • HTTPS-proxy, with the Default-HTTPS-Client proxy action
  • WatchGuard Certificate Portal (Fireware v12.3 and higher)
  • WatchGuard Web UI
  • Ping
  • DNS
  • WatchGuard
  • Outgoing

With these default policies, the Firebox: 

  • Does not allow connections from the external network to the trusted or optional networks, or the Firebox
  • Allows management connections to the Firebox from the trusted and optional networks only
  • Inspects outgoing FTP, HTTP, and HTTPS traffic, with recommended proxy action settings
  • Uses Application Control, WebBlocker, Gateway AntiVirus, Intrusion Prevention, Application Control, Reputation Enabled Defense, Botnet Detection, Geolocation, and APT Blocker security services to protect the trusted and optional networks

The web reputation authority service provided by Reputation Enabled Defense (RED) is deprecated. For more information, go to this Partner Blog post.

  • Allows outgoing FTP, Ping, DNS, TCP, and UDP connections from the trusted and optional networks

For more information about the default firewall policies and services configuration, go to Setup Wizard Default Policies and Settings.

Firewall Policy Basics

You can edit the default policies and add new policies so that the Firebox allows only approved connections. Before you edit or create new firewall policies, it is important to understand a few policy basics.

Policy Types

There are two types of firewall policies. Each examines connections at a different level of detail.

Packet filter policy - inspects only the packet header

A packet filter examines each packet’s IP and TCP/UDP header, but does not examine the content.

Proxy policy or application layer gateways (ALG) - inspects both the packet header and content

A proxy policy or ALG opens each packet in sequence, removes the network layer header, and examines the packet’s payload. When you configure a proxy policy or ALG, you select a proxy action and configure rules and actions to take based on characteristics of the content. For more information, go to About Proxy Policies and ALGs.

The default configuration uses proxy policies so that the Firebox can examine the content and use the licensed security services to protect your network.

Policy Properties

Ports and Protocols

A policy is defined by the ports and protocols it listens for. When you add a policy, the policy template you select specifies which ports and protocols the policy applies to. The ports and protocols are the only properties you cannot edit in a policy.

Source and Destination

A policy applies only to connections that match both the source (From) and destination (To) in the policy. A source or destination can include aliases, users, groups, IP addresses, and FQDNs.

Disposition (Firewall Action)

The disposition specifies whether the policy allows or denies connections that match the rules in the policy. You can configure a policy to Allow or Deny connections.

For details about how to configure the policy source, destination, and disposition go to Set Access Rules for a Policy.

Policy Precedence

Precedence is the sequence in which the Firebox examines network traffic and applies a policy rule. 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:

  • Ports and protocols
  • Source and destination
  • Disposition
  • Schedule

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. This requires more careful management, particularly if your configuration has a lot of policies.

Recommendation: Use Auto-Order mode up until it doesn’t work for your specific situation. This mode works fine for most deployments.

You can add multiple policies for the same port/protocol with different sources or destinations to allow different levels of access to network resources for different users, groups, or networks. 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.

For more information about policy precedence and how to disable Auto-Order mode, go to About Policy Precedence.

Policy Configuration Best Practices

Customize Policy Names

The default Firebox configuration uses standard names for policies. The default policy names indicate the type of traffic the policy handles, but might not be particularly meaningful in your network environment, particularly if you add multiple policies of the same type.

Recommendation: To make your policies easier to understand and maintain, give each policy a meaningful name that indicates the purpose of the policy, which users or network it applies to, or any other unique characteristics, such as when the policy is active.

Narrow the Firewall Policy Scope

By default, Firewall policies use the built-in aliases Any-External, Any-Trusted, Any-Optional, and Any. Policies configured with these alias might allow connections from more sources and destinations than is necessary. For more control over network connections,evaluate the source and destination in each policy to make sure that the policy does not allow connections from more sources or to more destinations than necessary.

Recommendations:

  • For each policy, configure the source and destination as narrowly as possible.
  • Do not use the Any alias in policies (except in the default Ping and BOVPN-Allow.in and BOVPN-Allow.out policies).
  • Review all policies that include the aliases Any, Any-External, Any-Optional, or Any-Trusted.
    • Make sure the aliases in each policy are really necessary for the connections you want to allow.
    • If possible, replace these aliases with a more specific source or destination to narrow the policy scope.

Here are some examples of when to narrow policy scope of some automatically generated policies:

Edit the destination in the default DNS policy

The default DNS policy allows connections from Any-Trusted and Any-Optional to Any-External.

Recommendation: To narrow the scope of this policy you can change the destination to include just the IP addresses or FQDNs of the external DNS servers in your DNS settings.

Edit the source in Firebox management policies

The default WatchGuard and WatchGuard Web UI policies allows management connections from Any-Trusted and Any-Optional.

Recommendation: You can remove Any-Optional from these policies to prevent management connections from your Optional networks. To reduce the scope even more, remove Any-Trusted and add specific subnets or IP address from which you want the Firebox to accept management connections.

Edit the destination of the default Mobile VPN access policies

When you enable Mobile VPN with SSL or Mobile VPN with L2TP, an automatically generated firewall policy allows connections from users and groups you specify in the VPN configuration to the destination Any.

The automatically generated VPN access policies are:

  • For Mobile VPN with SSL: Allow SSLVPN-Users
  • For Mobile VPN with L2TP: Allow L2TP-Users

The allowed resources you configure in the VPN settings control which connections a VPN client routes through the tunnel. The allowed resources are not destinations in the VPN policy. If a user in a mobile VPN group authenticates to the Firebox without the VPN, the Firebox recognizes the user as a member of the VPN group, and the VPN policy could allow connections from that user to any destination.

Recommendation: Edit these default policies to narrow the scope of the destination. Remove the Any alias and add the specific resources you want to the Firebox to allow VPN users to connect to.

For more information about aliases, go to About Aliases and Create an Alias.

Disable the Outgoing Policy

The default Firebox configuration includes the Outgoing packet filter policy. The Outgoing policy 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 does not filter content when it examines the traffic through your Firebox. The Outgoing policy exists to make sure that the Firebox allows outbound TCP and UDP connections that do not match any other policy.

Recommendation: To make sure that the Firebox allows only connections you want to allow, we recommend you disable the Outgoing policy. This is a best practice, but takes careful planning and follow-up. Before you remove the Outgoing policy, you must add policies for all outbound connections that you want the Firebox to allow.You can either add a separate policy for each type of outbound traffic you want to allow, or you can create a custom packet filter for the specific ports necessary for outbound connections you want to allow from your network.

WARNING: Even with careful planning, after you disable the Outgoing policy it is likely that the Firebox will deny some outbound connections that you want to allow. Be prepared to troubleshoot these issues and add policies as necessary to allow required outbound connections through the Firebox.

After you disable the Outgoing policy, you should plan to spend time to identify issues and update your firewall policies to allow approved outbound connections. This process takes time, but also give visibility into and control over the types of traffic on your network.

Enable HTTPS Content Inspection

In the HTTPS-Proxy, you can select the Inspect action to enable content inspection. When you enable content inspection, the Firebox decrypts the HTTPS connection, examines the content, and then re-encrypt the connection with a certificate signed by a CA that each network client trusts. Content inspection enables the proxy to examine and take action on the content of network traffic.

Some applications interpret content inspection as a man-in-the-middle attack, and can cause the applications to not function correctly. You must configure the HTTPS proxy action not to inspect traffic for domains associated with applications that are not compatible with content inspection.

WARNING: Even with careful planning, it is likely that some applications will not function after you enable content inspection. Plan to immediately test your critical applications and add domain name rules required to bypass inspection.

Some applications that do not function well with HTTPS content inspection enabled include:

  • Microsoft services (Office Online, Skype, Teams, Exchange, Sharepoint, Onedrive, Product Activation)
  • Apple services (iTunes, iCloud, App Store)
  • Adobe services (Creative Cloud, Sign)
  • Other services (Facebook, LinkedIn, Dropbox, Okta)

Recommendation: Enable content inspection, and configure the proxy action to bypass inspection for applications that are not compatible.

  1. In the HTTPS-Client proxy action, enable HTTPS content inspection. For more information, go to HTTPS-Proxy: Content Inspection.
  2. In the Content Inspection settings, enable Predefined Content Inspection Exceptions. The HTTPS proxy does not inspect traffic for domains in the predefined exceptions list. The exceptions enable many services to function correctly when content inspection is enabled, without manual configuration of Domain Name rules.
  3. Immediately test critical applications on your network to identify any that do not function with Content Inspection enabled.
  4. If your Fireware version does not support Predefined Content Inspection Exceptions, or if you want to bypass content inspection for an application that is not on the predefined exceptions list, add domain name rules for the domains the application connects to.
    1. Determine the domain names associated with the application.
    2. Add domain name rules with the Allow action to bypass inspection for those domains.

For more information about how to add domain name rules, go to HTTPS-Proxy: Domain Name Rules

Policy Troubleshooting Tips

If your configuration includes a lot of policies, it can sometimes be difficult to know which policy applies to a specific connection. Here are some tips to help with policy troubleshooting.

Examine Log Messages

The Firebox sends traffic log messages as it applies packet filter and proxy rules to traffic that goes through the device. You can sort and filter the log messages to learn why the Firebox denied a connection.

For information about how to read log messages, go to Read a Log Message.

By default, the Firebox sends a traffic log message when a policy denies a connection. You can also configure policies to send log messages for allowed connections. This can help you to:

  • Verify that inbound policies allow connections to an internal server
  • Verify that a custom outbound policy allows connections

We do not recommend that you enable logging of allowed connections for all policies because this generates a lot of log messages. This can fill the Dimension log server database more quickly, and can noticeably impact Firebox performance.

For information how to configure logging in a policy, go to Configure Logging and Notification for a Policy.

Use Policy Checker

Another tool you can use to determine which policy applies to a connection is Policy Checker in Fireware Web UI.

For more information, go to Use Policy Checker to Find a Policy.

Network and VPN Configuration Best Practices

Customize Interface Names

The default Firebox configuration uses standard names for interfaces.

Recommendation: To make your configuration easier to understand and maintain, we recommend that you give each interface a name that describes the network it connects to.

Configure Internal IP Address Ranges Not Commonly Used on Home Networks

We recommend that you do not use the private network ranges 192.168.0.0/24 or 192.168.1.0/24 on your corporate or guest networks. These ranges are commonly used on home networks.

If a mobile VPN user has a home network range that overlaps with your corporate network range, traffic from the user does not go through the VPN tunnel. To resolve this issue, we recommend that you Migrate to a New Local Network Range.

Configure Multiple DNS Servers

It is important to configure multiple Domain Name System (DNS) servers on the Firebox. The DNS servers are used by mobile VPN and network clients, and by security services to resolve the names of the servers they must connect to.

Recommendation: To make sure that a DNS server is always available on your network, we recommend that you configure at least two DNS servers, one with a private IP address, and another with a public IP address. We recommend that you list the private DNS server first, so it has higher precedence.

You add DNS Servers in the network settings. For more information, go to Configure Network DNS and WINS Servers.

Configure Non-Overlapping VPN Virtual Address Pools

When you configure Mobile VPN with IPSec, L2TP, SSL, or IKEv2 you must specify an IP address pool for VPN clients.

Recommendations: 

  • Make sure that the IP address pools for VPN clients do not overlap with any other IP address in the configuration.
  • If your company has multiple sites with mobile VPN configurations, make sure each site has a mobile VPN IP address pool that does not overlap with pools at other sites.
  • Do not use the private network ranges 192.168.0.0/24 or 192.168.1.0/24 for mobile VPN IP address pools. These ranges are commonly used on home networks. If a mobile VPN user has a home network range that overlaps with your corporate network range, traffic from the user does not go through the VPN tunnel. To resolve this issue, we recommend that you Migrate to a New Local Network Range.

Certificate Configuration Best Practices

Use PKI to Create Firebox Certificates

By default, your Firebox creates self-signed certificates to secure management session data and authentication attempts for Fireware Web UI and for proxy content inspection. To make sure the certificate used for content inspection is unique, its name includes the serial number of your device and the time at which the certificate was created. Because these certificates are not signed by a trusted certificate authority (CA), and they do not contain valid domain or IP information, users on your network see security warnings in their web browsers.

Recommendation: Replace the default self-signed certificates with signed certificates that are trusted by your network clients. Use local private key infrastructure (PKI) to generate any internal certificates used by the Firebox, such as Web Server and Proxy Authority certificates.

This provides several advantages:

  • It is easier to deploy certificates with an internal PKI than to create them on the Firebox.
  • It is easier to deploy certificates with third-party software (such as Active Directory) than to manually install them on each network client.
  • If the network clients trust your local PKI certificate authority, they automatically trust certificates you issue to the Firebox.
  • If you replace your Firebox, there is no need to redeploy certificates to your network clients.

For more information about how the Firebox uses certificates, go to About Certificates.

Related Topics

HTTP-Proxy Best Practices

FTP-Proxy Best Practices

About Network Segmentation