Policy views and policy lookup

This topic provides a sample of firewall policy views and firewall policy lookup.

Policy views

In Policy & Objects policy list page, there are two policy views: Interface PairView and By Sequence view.

Interface PairView displays the policies in the order that they are checked for matching traffic, grouped by the pairs of Incoming and Outgoing interfaces. For example, all policies referencing traffic from WAN1 to DMZ are in one section. The policies referencing traffic from DMZ to WAN1 are in another section. The sections are collapsible so that you only need to look at the sections you want.

By Sequence displays policies in the order that they are checked for matching traffic without any grouping.

The default display is Interface PairView. You can switch between the two views except if any or multiple-interfaces are applied in the policy.

How Any or multiple-interfaces policy can change the Interface Pair View

The FortiGate unit automatically changes the view on the policy list page to By Sequence whenever there is a policy containing any or multiple-interfaces as the Source or Destination interface. If the Interface PairView is grayed out, it is likely that one or more policies have used the any or multiple-interfaces.

When you use the any or multiple-interfaces, the policy goes into multiple sections because it might be any one of a number of interface pairings. Policies are divided into sectioned using the interface pairings, for example, port1 to port2.

Each section has its own policy order. The order in which a policy is checked for matching criteria to a packet’s information is based solely on the position of the policy within its section or within the entire list of policies. If the policy is in multiple sections, FortiGate cannot place the policy in order in multiple sections. Therefore the view can only be By Sequence.

Policy lookup

Firewall policy lookup is based on the Source_interfaces/Protocol/Source_Address/Destination_

Address that matches the source-port and dst-port of the protocol. Use this tool to find out which policy matches specific traffic from a number of policies. After completing the lookup, the matching firewall policy is highlighted on the policy list page.

The Policy Lookup tool has the following requirements:

• Transparent mode does not support Policy lookup function.
• When executing the policy lookup, you need to confirm whether the relevant route required for the policy work already exists.

Sample configuration

This example uses the TCP protocol to show how policy lookup works:

1. In Policy & Objects policy list page, click Policy Lookup and enter the traffic parameters.
2. Click Search to display the policy lookup results.

Other NGFW policy-based mode options

You can combine both application control and web filtering in the same NGFW policy mode policy. If the policy accepts applications or URL categories, you can apply Antivirus, DNS Filtering, and IPS profiles in NGFW mode policies as well as logging and policy learning mode.

Application control in NGFW policy-based mode

Configure Application Control by adding individual applications to security policies. You can set the action to ACCEPT or DENY to allow or block applications.

In the above example, if you browse to www.facebook.com, your connection will time out.

NGFW policy mode and NAT

If your FortiGate is operating in NAT mode, rather than enabling source NAT in individual NGFW policies, go to Policy & Objects > Central SNAT and add source NAT policies that apply to all matching traffic. In many cases, you may only need one SNAT policy for each interface pair. For example, if you allow users on the internal network (connected to LAN) to browse the Internet (connected to wan1), you can add a LAN to wan1 Central SNAT policy similar to the following.

Profile-based NGFW vs policy-based NGFW

From version 5.6, we added a new policy mode called Next Generation Firewall (NGFW). This mode is only available when the VDOM inspection-mode is flow. This model is divided into two working modes — profile-based and policybased. Profile-based NGFW is the traditional mode where a user needs to create an AV/web/IPS profile which is applied to the policy.

Policy-based mode is new. In this mode, users can add applications and web filtering categories directly to a policy without having to first create and configure Application Control or Web Filtering profiles. If a URL category is set, the applications that are added to the policy must be within the browser-based technology category. NGFW is per VDOM setting. This means users can operate their FortiGate or individual VDOMs on their FortiGate in NGFW policy-based mode when they select flow-based inspection.

Switching NGFW mode from profile-based to policy-based converts your profile-based security policies to policy-based security policies. If you don’t want this to happen or you just want to experiment with policy-based NGFW mode, consider creating a new VDOM for policy-based NGFW mode. You can also backup your configuration before switching modes.

NGFW policy-based firewall policies might have unintended consequences to the passing or blocking of traffic. For example, if you add new firewall policies that are designed to DENY social media traffic based on applications or URLs, having a traditional “catch all” firewall policy to DENY all other traffic at the bottom of the firewall policy list may have the unintended consequence of blocking legitimate traffic. Also note that NGFW policy-based mode applies the NAT settings from matching Central SNAT policies. If you don’t already have a Central SNAT policy in place, you must create one.

After version 6.2, we removed the inspection-mode from VDOM to firewall policy, and the default inspection-mode is flow so we can change NGFW mode from profile-based (default) to policy-based directly in the VDOM’s System > Settings.

To enable policy-based NGFW mode using the GUI:

You can operate your FortiGate or individual VDOMs in Next Generation Firewall (NGFW) policy mode.

1. Go to System > Settings.
2. In NGFW Mode, select Policy-based.
3. In SSL/SSH Inspection, select the SSL/SSH inspection mode to be applied to all policies.

To enable policy-based NGFW mode using the CLI:

config system settings set ngfw-mode {profile-based | policy-based} end

Firewall policy parameters

For traffic to flow through the FortiGate firewall, there must be a policy that matches its parameters:

• Incoming interface(s) l Outgoing interface(s) l Source address(es) l User(s) identity l Destination address(es) l Internet service(s) l Schedule l Service

Without all six (possibly eight) of these things matching, the traffic is declined.

Traffic flow initiated from each direction requires a policy, that is, if sessions can be initiated from both directions, each direction requires a policy.

Just because packets can go from point A to point B on port X does not mean that the traffic can flow from point B to point A on port X. A policy must be configured for each direction.

When designing a policy, there is often reference to the traffic flow, but most communication is two-way so trying to determine the direction of the flow might be confusing. If traffic is HTTP web traffic, the user sends a request to the website, but most of the traffic flow will be coming from the website to the user or in both directions? For the purposes of determining the direction for a policy, the important factor is the direction of the initiating communication. The user is sending a request to the website, so this is the initial communication; the website is responding so the traffic is from the user’s network to the Internet.

Firewall policies

The firewall policy is the axis around which most features of the FortiGate firewall revolve. Many settings in the firewall end up relating to or being associated with the firewall policies and the traffic that they govern. Any traffic going through a FortiGate unit has to be associated with a policy. These policies are essentially discrete compartmentalized sets of instructions that control the traffic flow going through the firewall. These instructions control where the traffic goes, how it’s processed, if it’s processed, and even whether or not it’s allowed to pass through the FortiGate.

When the firewall receives a connection packet, it analyzes the packet’s source address, destination address, and service (by port number). It also registers the incoming interface, the outgoing interface it needs to use, and the time of day. Using this information, the FortiGate firewall attempts to locate a security policy that matches the packet. If it finds a policy that matches the parameters, it then looks at the action for that policy. If it is Accept, the traffic is allowed to proceed to the next step. If the Action is Deny or a match cannot be found, the traffic is not allowed to proceed.

The two basic actions at the initial connection are either Accept or Deny:

• If the Action is Accept, the policy action permits communication sessions. There may be other packet processing instructions, such as requiring authentication to use the policy or restrictions on the source and destination of the traffic.
• If the Action is Deny, the policy action blocks communication sessions, and you can optionally log the denied traffic. If no security policy matches the traffic, the packets are dropped. A Deny security policy is needed when it is required to log the denied traffic, also called violation traffic.

One other action can be associated with the policy:

• IPsec – This is an Accept action that is specifically for IPsec VPNs.

In addition to the Accept or Deny actions, there can be a number of instructions associated with a FortiGate firewall, some of which are optional. Instructions on how to process the traffic can include such things as:

• Logging traffic. l l Network Address Translation or Port Address Translation. l Use Virtual IPs or IP Pools. l Caching. l Whether the source of the traffic is based on address, user, device, or a combination. l Whether to treat as regular traffic or IPsec traffic. l What certificates to use. l Security profiles to apply.
• Proxy Options. l Traffic Shaping.

Troubleshoot an HA formation

The following are requirements for setting up an HA cluster or FGSP peers.

Cluster members must have:

• The same model. l The same hardware configuration. l The same connections.
• The same generation.

The requirement to have the same generation is done as a best practice as it avoids issues that can occur later on. If you are unsure if the boxes you have are from the same generation, please contact customer service.

Troubleshooting common HA formation errors

One box keeps shutting down during HA setup (hard drive failure):

If one box has a hard drive failure but the other does not, the one with the hard drive failure will be shut down during HA setup. In this case, RMA the box to resolve the issue.

Desired box won’t be the Master:

When all members join together as a cluster, a process called a negotiation begins in order to decide which box will become the Master. It is decided by the following criteria:

The first factor is the amount of connected good interfaces. If Box A has two monitored interfaces up and Box B has only one, then Box A will become the Master. Ensure all monitored connections to members are good.

All members are Masters and members can’t see other members:

Typically, this is a heartbeat issue. It is recommended that for a two-member cluster, you use a back-to-back connection for heartbeat communication. If there are more than three members in the cluster, a separate switch should be used to connect all heartbeat interfaces.

Check HA sync status

The HA sync status can be viewed in the GUI through either a widget on the Dashboard or on the System > HA page. It can also be confirmed through the CLI. When a cluster is out of sync, administrators should correct the issue as soon as possible as it affects the configuration integrity and can cause issues to occur.

HA sync status in the GUI

• Dashboard widget:
• Following HA setup, the HA Status widget can be added to the Dashboard. The widget shows the HA sync status by displaying a green checkmark next to each member in sync. A red mark indicates the member is out of sync.
• System > HA page: l The same set of icons will be displayed on the System > HA page to indicate if the member is in sync.

HA sync status in the CLI

• In the CLI, run the command get sys ha status to see if the cluster is in sync. The sync status is reported under Configuration Status. In the following example, both members are in sync:

FGT_A # get sys ha status

HA Health Status: OK Model: FortiGate-300D Mode: HA A-P Group: 146 Debug: 0 Cluster Uptime: 0 days 21:42:53 Cluster state change time: 2019-03-09 11:40:51 Master selected using: <2019/03/08 18:56:12> FGT6HD3914800153 is selected as the master because it has the least value 0 of link-failure + pingsvr-failure.

ses_pickup: enable, ses_pickup_delay=disable override: enable Configuration Status:

FGT6HD3914800069(updated 5 seconds ago): in-sync

FGT6HD3914800153(updated 4 seconds ago): in-sync

System Usage stats:

FGT6HD3914800069(updated 5 seconds ago): sessions=17, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=25% FGT6HD3914800153(updated 4 seconds ago):

sessions=0, average-cpu-user/nice/system/idle=0%/0%/0%/100%, memory=25%

: : : Master: FGT6HD3914800069, HA operating index = 0 Slave : FGT6HD3914800153, HA operating index = 1