Firewall policy

The firewall policy is the axis around which most of the other features of the FortiGate firewall revolve. A large portion of the settings in the firewall at some point will 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.

The following topics provide information on the firewall policy and configuration:

• Firewall policy parameters

• Configurations in the GUI

• Configurations in the CLI

• Policy views

• Policy match

• Services

Firewall policy parameters

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

• Incoming interface(s)

• Outgoing interface(s)

• Source address(es)

• Destination address(es)

• User(s) identity

• Service(s)

• Schedule

Traffic parameters are checked against the configured policies for a match. If the parameters do not match any configured policies, the traffic is denied.

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.

FortiOS does not perform a reverse-path check on reply traffic that matches an allowed session based on the IP tuple. The request traffic can be sent on one interface and the reply traffic could return on another interface.

Configurations in the GUI

Firewall policies can be created in the GUI by configuring the necessary parameters.

Schedule	The time frame that is applied to the policy. This can be something as simple as a time range that the sessions are allowed to start, such as between 8:00 am and 5:00 pm. Something more complex like business hours that include a break for lunch and time of the session’s initiation may need a schedule group because it will require multiple time ranges to make up the schedule.
Incoming interface(s)	This is the interface or interfaces by which the traffic is first connected to the FortiGate unit. The exception being traffic that the FortiGate generates itself. This is not limited to the physical Ethernet ports found on the device. The incoming interface can also be a logical or virtual interface such as a VPN tunnel, a Virtual WAN link, or a wireless interface.
Outgoing interface(s)	This is the interface or interfaces used by traffic leaving a port once it has been processed by the firewall. Similar to incoming interfaces, it is not limited to only physical interfaces.
Source address(es)	The addresses that a policy can receive traffic from can be wide open or tightly controlled. For a public web server that the world at large should be able to access, the best choice will be all. If the destination is a private web server that only the branch offices of a company should be able to access, or a list of internal computers that are the only ones allowed to access an external resource, then a group of preconfigured addresses is the better strategy
User/group	This parameter is based on a user identity that can be from a number of authentication authorities. It will be an account or group that has been set up in advance that can be selected from the drop down menu. The exception to this is the feature that allows the importing of LDAP Users. When the feature is used, a small wizard window will appear to guide the user through the setup. The caveat is that the LDAP server object in the User & Authentication > LDAP Servers section has to be already configured to allow the use of this import feature.
Destination address(es)	In the same way that the source address may need to be limited, the destination address can be used as a traffic filter. When the traffic is destined for internal resources, the specific address of the resource can be defined to better protect the other resources on the network. One of the specialized destination address options is to use a Virtual IP address. If the destination address doesn’t need to be internal, you can define policies that are only for connecting to specific addresses on the Internet.
Internet service(s)	In this context, an Internet service is a combination of one or more addresses and one or more services associated with a service found on the Internet such as an update service for software.
Service	The services chosen represent the TCP/IP suite port numbers that will most commonly be used to transport the named protocols or groups of protocols. This is different than Application Control which looks more closely at the packets to determine the actual protocol used to create them. A case where either side can initiate the communication, like between two internal interfaces on the FortiGate unit, would be a more likely situation to require a policy for each direction.

To create a policy by an IP address with new objects in the GUI:

1. From the Dashboard > FortiView Sources page, choose any entry.

2. Click Create policy > Create firewall policy by IP address. The Create New Policy pane opens.

3. The Incoming interface field is auto-filled with the correct interface and the Source field is auto-filled with a new staged object and a green icon.

4. Hover over the icon and a warning is shown: This entry does not exist yet. If selected, it will be automatically created when the form is submitted. Check that the stage object has the correct IP address.

   Staged objects can be customized by clicking Customize.

   

   The staged object will not be saved if you click Cancel on the Create New Policy pane.

5. Fill in all other fields with the necessary data and save the policy.

6. When the policy is successfully created, a green notification displays in the top right of the window. Click Show in list to view the policy that was created.

To create a policy with existing objects:

1. Navigate to the Dashboard > FortiView Sources page and choose any source entry that was saved as an address during policy creation in the previous section

2. Click Create policy > Create firewall policy by IP address. The Create New Policy pane opens.

3. The Incoming interface field is auto-filled with the correct interface and the Source field is auto-filled with the correct address object. No green icon is shown for the address object. The object can be found in the Address list by clicking Show in list in the object tooltip.

4. Fill in the other fields with required data and save the policy. When the policy is successfully created, a green notification displays in the top right of the window.

5. Click Show in list to view the policy.

Displaying logic between firewall policy objects in the GUI

The FortiOS GUI can display the logical AND relationship in firewall policies between source and destination objects, including security posture tags when enabled, to help you configure firewall policies.

To display the logic in firewall policies in the GUI:

1. Go to Policy & Objects > Firewall Policy, and click Create New. The Create New Policy pane opens.

2. In the Source & Destination section, click Show Logic.

   • The labels Any of and And any of appear to clarify how the objects are used to match traffic. The And any of label indicates a logical AND relationship between the objects.

   

3. Enable Security posture tag:

   • The labels And any of appear, indicating a logical AND relationship between the two security posture tag objects.

   • The first security posture tag group is required when Security posture tag is enabled and is considered the primary tag group.

   • A second security posture tag group is optional when Security posture tag is enabled and is considered the secondary tag group.

   • Within each of the tag groups, there is a logical OR relationship between the tags when multiple tags are used.

   

4. In the Destination list, select one or more destinations to display And any of between the Destination and Service fields.

   

Following is the logic of using the mandatory and optional fields in the Source & Destination section, based on the following configurations:

Traffic must match all criteria below:

• Any Source: either Windows-Client OR Mac-Clients

• Any User/group: either LDAP-Administrator, LDAP-Finance, OR LDAP-Sales

• The primary Security posture tag: Non-Critical

• Any secondary security posture tags: either all_registered_clients OR Domain-Users

• Any Destination: either Webserver1 OR Webserver2

• Any Service: Either DNS, HTTP, OR HTTPS

Enabling advanced policy options in the GUI

Advanced policy options can be enabled so that you can configure the options in the GUI.

To enable advanced policy options:

config system settings
    set gui-advanced-policy enable
end

Advanced policy options are now available when creating or editing a policy in the GUI:

To enable configuring TCP sessions without SYN:

config system settings
    set tcp-session-without-syn enable
end

TCP sessions without SYN can now be configured when creating or editing a policy in the GUI:

Add Policy change summary and Policy expiration to Workflow Management

Two options, Policy change summary and Policy expiration, are included in Workflow Management. Policy change summary enforces an audit trail for changes to firewall policies. Policy expiration allows administrators to set a date for the firewall policy to be disabled.

There are three states for the Policy change summary:

• Disable: users will not be prompted to add a summary when editing a policy.

• Required: the Policy change summary will be enabled and will require users to add a summary when editing or creating a firewall policy.

• Optional: the Policy change summary will be enabled but users can leave the summary empty, if preferred, when editing or creating a firewall policy.

There are three states for Policy expiration:

• Disable: the firewall policy will not expire. This is the default setting for Policy expiration.

• Default: the firewall policy will expire after the default number of days.

• Specify: the firewall policy will expire at a set date and time.

The default value for Policy expiration is 30 days. This number can be changed in the CLI or in System > Settings in the GUI to any value between zero and 365 days. If the default value is set to zero, the Default state will disable the Policy expiration.

To configure the firewall policy change summary and default expiration in the GUI:

1. Go to System > Feature Visibility.

2. Enable Workflow Management.

3. Click Apply.

4. Go to System > Settings.

5. In the Workflow Management section, set Policy change summary to Required. Policies expire by default is enabled by default with an Expire after value of 30.

   

6. Click Apply.

To configure firewall policy expiration in the GUI:

1. Go to Policy & Objects > Firewall Policy and click Create New.

2. Name the policy and configure the necessary parameters.

3. Set Policy expiration to Specify.

   

4. Select the date and time for the policy to expire from the Expiration date fields.

5. Click OK. The Workflow Management - Summarize Changes pane opens.

   

6. In the Change summary field, enter details about the changes made to the policy. These details can be referred to later for auditing purposes.

7. Click OK.

To configure the firewall policy change summary in the CLI:

config system settings
    set gui-enforce-change-summary {disable | require | optional}
end

To configure the policy expiration default value in the CLI:

config system settings
    set default-policy-expiry-days <integer>
end

To configure firewall policy expiration in the CLI:

config firewall policy
    edit <id>
        set policy-expiry {enable | disable}
        set policy-expiry-date <YYYY-MM-DD HH:MM:SS>
    next
end

Policy change summaries are used to track changes made to a firewall policy. The Audit Trail allow users to review the policy change summaries, including the date and time of the change and which user made the change.

The Audit Trail is only supported by FortiGate models with disk logging.

To review the audit trail in the GUI:

1. Go to Policy & Objects > Firewall Policy.

2. Select the policy you want to review and click Edit.

3. In the right-side banner (or on the Info tab if shown), click Audit Trail. The Audit trail for Firewall Policy pane opens and displays the policy change summaries for the selected policy.

   

4. Select an entry to review the details of the change made.

5. When you are done reviewing the Audit Trail, click Close.

6. Click Cancel to exit the Edit Policy page.

Configurations in the CLI

Firewall policies can be created in the CLI by configuring the necessary parameters. See Configurations in the GUI for more information on the various parameters.

Parameter	Definition
srcintf	Incoming (ingress) interface.
dstintf	Outgoing (egress) interface.
srcaddr	Source IPv4 address and address group names.
dstaddr	Destination IPv4 address and address group names.
internet-service	Enable/disable use of Internet Services for this policy. If enabled, destination address and service are not used.
schedule	Schedule name.
service	Service and service group names.
anti-replay	Enable/disable checking of TCP flags per policy.
match-vip	Enable/disable matching of VIPs when used in a policy with a deny action.
auto-asic-offload	Enable/disable hardware acceleration. Available on select FortiGate models with Secure Processing Unit (SPU) hardware only.
tcp-mss-sender	Sender TCP maximum segment size (MSS).
tcp-mss-receiver	Receiver TCP maximum segment size (MSS).
session-ttl	Time-to-live (TTL) in seconds for session accepted by this policy.

Firewall anti-replay option per policy

When the global anti-replay option is disabled, the FortiGate does not check TCP flags in packets. The per policy anti-replay option overrides the global setting. This allows you to control whether or not TCP flags are checked per policy.

To enable the anti-replay option so TCP flags are checked using the CLI:

config firewall policy
    edit 1
        set name "policyid-1"
        set srcintf "wan2"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set schedule "always"
        set service "ALL"
        set anti-replay enable
        set logtraffic all
        set nat enable
    next
end

Deny matching with a policy with a virtual IP applied

Preventing hosts with specific source addresses from accessing a server behind the FortiGate may be required in some cases. For this scenario, you should have previously configured a firewall policy with a virtual IP (VIP) object applied to it to allow such access. See Destination NAT for details.

When denying traffic destined for a typical firewall policy without a VIP applied, you would simply configure a new firewall policy with an action of deny and with specific source addresses above the firewall policy that you want to prevent these hosts from accessing. However, the FortiGate matches firewall policies with VIPs applied differently than typical firewall policies. Policies with VIPs applied have priority over typical firewall policies.

Therefore, to block specific source traffic destined for a firewall policy specified with an action of accept and with a VIP applied, you should configure set match-vip enable on the firewall policy with a deny action that has been configured to match traffic before the firewall policy with the VIP applied. By default, new deny action firewall policies have match-vip enabled.

If the policy action is set to accept, match-vip cannot be enabled.

To block VIP traffic in a deny policy:

config firewall policy
    edit 1
        set name "deny-policy-1"
        set srcintf "wan1"
        set dstintf "lan1"
        set srcaddr "src-hosts-to-deny-access"
        set dstaddr "all"
        set action "deny"
        set schedule "always"
        set service "all"
        set match-vip enable
    next
    edit 2
        set name "vip-policy-1"
        set srcintf "wan1"
        set dstintf "lan1"
        set srcaddr "all"
        set dstaddr "vip-object-1"
        set action "accept"
        set schedule "always"
        set service "ALL"
    next
end

Alternatively, to block access to a firewall policy with a VIP applied, you can configure a new VIP object configured with set src-filter <range>. Configure a new firewall policy with a deny action and with this new VIP applied, and then configure this policy to match traffic before the firewall policy with the same VIP applied with an action of accept. In this case, the firewall policy can simply have set match-vip disable.

To specify a VIP with source addresses specified with a deny policy:

config firewall vip
    edit “vip-with-srcaddr-to-deny”
        set extip "10.1.100.199"
        set extintf "wan1"
        set mappedip "172.16.200.55"
        set src-filter "1.1.1.1/24"
    next
end
config firewall policy
    edit 3
        set name "deny-policy-3"
        set srcintf "wan1"
        set dstintf "lan1"
        set srcaddr "all"
        set dstaddr "vip-with-srcaddr-to-deny"
        set action "deny"
        set match-vip disable
        set schedule "always"
        set service "ALL"
    next
    edit 2
        set name "vip-policy-1"
        set srcintf "wan1"
        set dstintf "lan1"
        set srcaddr "all"
        set dstaddr "vip-object-1"
        set action "accept"
        set match-vip disable
        set schedule "always"
        set service "ALL"
    next
end

Hardware acceleration

Hardware acceleration is supported on select FortiGate devices and is enabled by default on all firewall policies to ensure optimal performance when processing network traffic traversing the FortiGate. See the Hardware Acceleration Reference Manual for details.

Typically, hardware acceleration on a specific firewall policy is disabled for one of two purposes:

• To allow CLI commands such as the packet sniffer and debug flow to display all traffic matching the policy since traffic offloaded by SPU hardware on a FortiGate device is not visible by those CLI tools.

• To troubleshoot any possible issues arising by using hardware acceleration.

To disable hardware acceleration in an IPv4 firewall policy:

config firewall policy
    edit 1
        set auto-asic-offload disable
    next
end

To disable hardware acceleration in an IPv6 firewall policy:

config firewall policy6
    edit 1
        set auto-asic-offload disable
    next
end

To disable hardware acceleration in a multicast firewall policy:

config firewall multicast-policy
    edit 1
        set auto-asic-offload disable
    next
end

TCP Maximum Segment Size (MSS)

The TCP maximum segment size (MSS) is the maximum amount of data that can be sent in a TCP segment. The MSS is the MTU size of the interface minus the 20 byte IP header and 20 byte TCP header. By reducing the TCP MSS, you can effectively reduce the MTU size of the packet.

The TCP MSS can be configured in a firewall policy, or directly on an interface. See Interface MTU packet size for details on configuring TCP MSS directly on an interface.

To configure TCP MSS in a firewall policy:

config firewall policy
    edit <policy ID>
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "10.10.10.6"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set tcp-mss-sender 1448
        set tcp-mss-receiver 1448
    next
end

Adjusting session time-to-live (TTL)

A session is a communication channel between two devices or applications across the network. Sessions allow FortiOS to inspect and act on a sequential group of packets in a session all at once instead of inspecting each packet individually. Each session has an entry in the session table that includes important information about the session.

The session time-to-live (TTL) parameter determines how long a session of a particular protocol such as TCP, UDP, or ICMP remains in the session table. To ensure proper operation of some devices or applications, the session TTL parameter may need to be increased or decreased to allow sessions to remain active in the session table for a longer or shorter duration, respectively.

To configure a modified session TTL in a firewall policy:

config firewall policy
    edit <policy ID>
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "10.10.10.6"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set session-ttl 1800
    next
end

The session TTL can be set to zero or never to ensure a session never times out. See No session timeout for details.

Session TTL should only be set to zero or never after careful consideration of:

• The connected device’s or application’s requirements for sessions to always stay alive

• The expectation that a connected device or application will use the same session determined by traffic using a fixed source port, fixed destination port, fixed source IP address, and fixed destination IP address.

When session TTL is set to zero or never, then sessions will not be cleared from the session table or expire after a specified time unless the CLI commands diagnose system session filter <filter> and diagnose system session clear are used. If this setting is used in the case when traffic through a firewall policy can generate numerous unique sessions, then this may have unintended consequences to the FortiGate’s memory usage and performance due to the session table constantly growing and not clearing out idle sessions.

To disable session TTL in a firewall policy:

config firewall policy
    edit <policy ID>
        set srcintf "internal"
        set dstintf "wan1"
        set srcaddr "10.10.10.6"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set session-ttl never
    next
end

Policy views

In Policy & Objects policy list pages, there are three policy views: Interface Pair View, Sequence Grouping View, and By Sequence. For large policy tables (thousands of policies), the By Sequence view will load the fastest.

Interface Pair View displays the policies in the order that they are checked for matching traffic, grouped by the pairs of incoming and outgoing interfaces in collapsible sections. The Interface Pair View can be used when a policy is configured with multiple interfaces. Right-click on any pair name and click Expand All or Collapse All to expand or collapse all of the pairs.

When a policy is inserted, the Incoming and Outgoing interfaces are automatically filled in, and you can confirm the location of the new policy in the right-side gutter before clicking OK to insert the policy.

When a single policy is selected, an inline menu opens below the row. The More dropdown menu includes the same expanded list of options that are available in the right-click menu. When multiple policies are selected, the top menu bar changes to show buttons that are applicable to the multiple selections and you can click View selected to show only the selected policies on the page.

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

Policies can then be moved by their policy ID before or after another specified policy ID.

Moving policies by ID is only available when viewing the Firewall Policy page in By Sequence or Sequence Grouping View.

To move a policy by policy ID:

1. Go to Policy & Objects > Firewall Policy.

2. Select the policy you want to move.

3. Select More > Move by ID.

   

   The Move by ID pane is displayed.

4. Define the new location of the policy:

   1. Select whether the policy should be moved Above or Below the policy ID you will define in the next step.

   2. In the Destination policy ID field, enter the ID of the destination policy or select it from the dropdown menu.

      

5. If you do not want to automatically view the new location of the policy, disable Jump to policy after move. This feature is enabled by default.

6. Click OK.

   If Workflow Management is enabled in System > Feature Visibility, the Workflow Management - Summarize Changes pane is displayed. Enter a Change summary then click OK to continue.

   The policy will be moved to the new location.

   

Policy match

Firewall policy match 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 match, the matching firewall policy is highlighted on the policy list page.

The Policy match tool has the following requirements:

• Transparent mode does not support policy match function.

• When executing the policy match, 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 match works:

1. On a Policy & Objects policy list page, click Policy match and enter the traffic parameters.

   

2. Click Find matching policy to display the policy match results.

Services

Services represent typical traffic types and application packets that pass through the FortiGate. Services include the service protocol type (TCP, UDP, ICMP, and so on), address, category, and logical destination port. Services can then be applied in a firewall policy to represent the TCP/IP suite port numbers that will most commonly be used to transport the named protocols or groups of protocols. Likewise, security profiles use service definitions to match session types.

The following services are available:

• Predefined services

• Custom services

• Service groups

Predefined services

Firewall policies can be configured with default, predefined services that have been created for common traffic types. Predefined services can be edited, cloned, and deleted from the Policy & Objects > Services list. Cloning a services allows you to create a copy of the service parameters and edit it to create a similar service while still maintaining the existing service.

To clone a service:

1. Go to Policy & Objects > Services.

2. Go to the Services tab.

   

3. Select the service you want to clone.

4. Click Clone. The New Service page is displayed.

   

5. Edit the service details as needed.

6. Click OK.

To edit a service:

1. Go to Policy & Objects > Services.

2. Go to the Services tab and select the service that you need to edit.

   

3. Click Edit. The Edit Service page is displayed.

   

4. Edit the service details as needed.

5. Click OK.

Custom services

You can create new, customized services in the Policy & Objects > Services page and the CLI. When creating a custom service, the ports, IP addresses, and protocols must be known for proper configuration. Once a service has been created, it must be applied to a firewall policy to take effect.

Custom services can also be created while configuring a new firewall policy.

To configure a custom service in the GUI:

1. Go to Policy & Objects > Services.

2. Go to the Services tab and click Create new.

3. Configure the service parameters as needed.

   

4. Click OK.

Custom services can be configured in the CLI for TCP/UDP/UDP-Lite/SCTP, ICMP, ICMP6, and IP protocols. Service parameters are dependent on the protocol type. See config firewall service custom in the CLI Reference guide for more information.

To configure a custom service in the CLI:

config firewall service custom
    edit <name>
        set protocol TCP/UDP/SCTP
        set tcp-portrange <destination port range>
        set udp-portrange <destination port range>
        set udplite-portrange <destination port range>
        set sctp-portrange <destination port range>
    next
end

Service groups

Service groups are a collection of services and other service groups, allowing multiple services to be applied in a firewall policy at once.

Service groups can be cloned and edited in the Service Groups tab using the same process as services. See Predefined services.

To configure a service group in the GUI:

1. Go to Policy & Objects > Services.

2. Go to the Service Groups tab and click Create new. The New Service Group page is displayed.

   

3. Enter the Name of the group.

4. (Optional) Enter a comment and select a color for the service group.

5. Select the group type.

6. Click the Members field and select the services and service groups to include in the group.

7. Click OK.

To configure a service group in the CLI:

config firewall service group
    edit <name>
        set fabric-object {enable | disable}
        set member <service name1>, <service name2>
        set proxy {enable | disable}
    next
end