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 lookup

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)
• User(s) identity
• Destination address(es)
• Internet service(s)
• Schedule
• Service

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.

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(s) identity	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.
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.
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.

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. The Expiration date fields appears with the current date and time.

   

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.

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, 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 two policy views: Interface Pair View and By Sequence view.

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.

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

The default display is Interface Pair View. You can switch between the two views except if any or multiple interfaces are applied in the policy. The FortiGate 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 Pair View is grayed out, it is likely that one or more policies have used the any or multiple interfaces.

You can export the current view to CSV and JSON formats by clicking Export and selecting CSV or JSON. The file is automatically downloaded.

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. On a Policy & Objects policy list page, click Policy Lookup and enter the traffic parameters.

   

2. Click Search to display the policy lookup results.