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

FGSP (session-sync) peer setup

Connect all necessary interfaces as per the topology diagram below. Interfaces may be changed depending on the models in use. Interface names in the topology diagram are for example purposes only.

To setup a FGSP peer through the CLI:

These instructions assume that the device has been connected to the console and the CLI is accessible, and that all boxes have been factory reset.

1. Connect all necessary interfaces as per the topology diagram.
2. Enter the following command to change the FortiGate unit host name:

config system global set hostname Example1_host(Example2_host, etc)

end

3. On each FGSP peer device, enter the following command:

config system cluster-sync set peerip xx.xx.xx.xx    —>> peer’s interface IP for session info to be passed. end

4. Set up identical firewall policies.

FGSP peers share the same session information which goes from the same incoming interface (example: port1) to the outgoing interface (example: port2). Firewall policies should be identical as well, and can be copied from one device to its peer.

To test the setup:

1. Initiate TCP traffic (like HTTP access) to go through boxA.
2. Check the session information.

Example: diag sys session filter src xx.xx.xx.xx (your PCs IP) diag sys session lsit.

3. Use the same command on boxB to determine if the same session information appeared.

Fail protection

The FortiGate Clustering Protocol (FGCP) provides failover protection, meaning that a cluster can provide FortiGate services even when one of the devices in the cluster encounters a problem that would result in the complete loss of connectivity for a stand-alone FortiGate unit. Fail protection provides a backup mechanism that can be used to reduce the risk of unexpected downtime, especially in mission-critical environments.

FGCP supports failover protection in two ways:

1. Link failover maintains traffic flow if a link fails, and
2. If a device loses power, it automatically fails over to a backup unit with minimal impact on the network.

When session-pickup is enabled in the HA settings, existing TCP session are kept, and users on the network are not impacted by downtime as the traffic can be passed without reestablishing the sessions.

When and how the failover happens

1. link fails

Before triggering a failover when a link fails, the administrator must ensure that monitor interfaces are configured. Normally, the internal interface that connects to the internal network, and an outgoing interface for traffic to the internet or outside the network, should be monitored. Any of those links going down will trigger a failover.

2. Loss of power for active unit.

When an active (master) unit loses power, a backup (slave) unit automatically becomes the master, and the impact on traffic is minimal. There are no settings for this kind of fail over.

Cluster setup

HA active-passive cluster setup

An HA Active-Passive (A-P) cluster can be set up using the GUI or CLI.

This example uses the following network topology:

To set up an HA A-P cluster using the GUI:

1. Make all the necessary connections as shown in the topology diagram.
2. Log into one of the FortiGates.
3. Go to System > HA and set the following options:

Except for the device priority, these settings must be the same on all FortiGates in the cluster.

4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.

The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate’s interfaces.

6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting setting the device priority, to join the cluster.

To set up an HA A-P cluster using the CLI:

1. Make all the necessary connections as shown in the topology diagram.
2. Log into one of the FortiGates.
3. Change the hostname of the FortiGate:

config system global set hostname Example1_host

end

Changing the host name makes it easier to identify individual cluster units in the cluster operations.

4. Enable HA:

config system ha set mode a-p

set group-name Example_cluster

set hbdev ha1 10 ha2 20 end

5. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
6. Repeat steps 1 to 5 on the other FortiGate devices to join the cluster.

HA active-active cluster setup

An HA Active-Active (A-A) cluster can be set up using the GUI or CLI.

This example uses the following network topology:

To set up an HA A-A cluster using the GUI:

1. Make all the necessary connections as shown in the topology diagram.
2. Log into one of the FortiGates.
3. Go to System > HA and set the following options:

Except for the device priority, these settings must be the same on all FortiGates in the cluster.

4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.

The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate’s interfaces.

6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting setting the device priority, to join the cluster.

To set up an HA A-P cluster using the CLI:

1. Make all the necessary connections as shown in the topology diagram.
2. Log into one of the FortiGates.
3. Change the hostname of the FortiGate:

config system global set hostname Example1_host

end

Changing the host name makes it easier to identify individual cluster units in the cluster operations.

4. Enable HA:

config system ha set mode a-a

set group-name Example_cluster

set hbdev ha1 10 ha2 20 end

5. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
6. Repeat steps 1 to 5 on the other FortiGate devices to join the cluster.

HA virtual cluster setup

An HA virtual cluster can be set up using the GUI or CLI.

To set up an HA virtual cluster using the GUI:

1. Make all the necessary connections as shown in the topology diagram.
2. Log into one of the FortiGates.
3. Go to System > HA and set the following options:

Except for the device priority, these settings must be the same on all FortiGates in the cluster.

4. Leave the remaining settings as their default values. They can be changed after the cluster is in operation.
5. Click OK.

The FortiGate negotiates to establish an HA cluster. Connectivity with the FortiGate may be temporarily lost as the HA cluster negotiates and the FGCP changes the MAC addresses of the FortiGate’s interfaces.

6. Factory reset the other FortiGate that will be in the cluster, configure GUI access, then repeat steps 1 to 5, omitting setting the device priority, to join the cluster.
7. Go to System > Settings and enable Virtual Domains.
8. Click Apply. You will be logged out of the FortiGate.
9. Log back into the FortiGate, ensure that you are in the global VDOM, and go to System > VDOM.
10. Create two new VDOMs, such as VD1 and VD2:
    1. Click Create New. The New Virtual Domain page opens.
    2. Enter a name for the VDOM in the Virtual Domain field, then click OK to create the VDOM.
    3. Repeat these steps to create a second new VDOM.
11. Implement a virtual cluster by moving the new VDOMs to Virtual cluster2:
    1. Go to System > HA.
    2. Enable VDOM Partitioning.
    3. Click on the Virtual cluster2 field and select the new VDOMs.
    4. Click OK.

To set up an HA virtual cluster using the CLI:

1. Make all the necessary connections as shown in the topology diagram.
2. Set up a regular A-P cluster. See HA active-passive cluster setup on page 212.
3. Enable VDOMs:

config system global set vdom-mode multi-vdom

end

You will be logged out of the FortiGate.

4. Create two VDOMs:

config vdom edit VD1 next edit VD2 next

end

5. Reconfigure the HA settings to be a virtual cluster:

config global config system ha set vcluster2 enable config secondary-vcluster set vdom “VD1” “VD2”

end

end end

Use Custom Images for Replacement Messages

The replacement message list in System > Replacement Messages enables you to view and customize replacement messages. Highlight the replacement messages you want to edit and customize the message content to your requirements. Hit Save when done. If you do not see the message you want to edit, select the Extended View option in the upper right-hand corner of the screen.

If you make a mistake, select Restore Default to return to the original message and code base.

Replacement message images

You can add images to replacement messages on:

• Disclaimer pages l Login pages l Declined disclaimer pages l Login failed pages
• Login challenge pages l Keepalive pages

Adding images to replacement messages

To add images to replacement messages in the GUI:

1. Go to System > Replacement Messages.
2. Select Manage Images at the top of the page.
3. Select Create New.
4. Enter a name for the image.
5. Select the Content Type.
6. Select Browse to locate the file and select OK.

Modify images in replacement messages

Replacement messages can be modified to include an HTML message or content that suits your organization. A list of common replacement messages appear in the main window. Select Extended View to see the entire list and all categories for replacement messages.

To modify an image in a replacement message:

1. Go to System > Replacement Messages.
2. Select the replacement message you want to edit.

In the bottom pane of the GUI the message will be displayed on the left alongside the HTML code on the right. The message view changes in real-time as you edit the content.

3. Select Save.

Replacement message groups

Replacement message groups enable you to view common messages in groups for large carriers. Message groups can be configured by going to Config > Replacement Message Group.

Using the defined groups, you can manage specific replacement messages from a single location, rather than searching through the entire replacement message list.

If you enable virtual domains (VDOMs) on the FortiGate unit, replacement message groups are configured separately for each virtual domain. Each VDOM has its own default replacement message group, configured from System > Replacement Message Group.

When you modify a message in a replacement message group, a reset icon appears beside the message in the group.

Select the reset icon to reset the message in the replacement message group to the default version.

DHCP server

A DHCP server provides an address from a defined address range to a client on the network, when requested.

You can configure one or more DHCP servers on any FortiGate interface. A DHCP server dynamically assigns IP addresses to hosts on the network connected to the interface. The host computers must be configured to obtain their IP addresses using DHCP.

You can configure a FortiGate interface as a DHCP relay. The interface forwards DHCP requests from DHCP clients to an external DHCP server and returns the responses to the DHCP clients. The DHCP server must have appropriate routing so that its response packets to the DHCP clients arrive at the unit.

Configure DHCP on the FortiGate

To add a DHCP server on the GUI:

1. Go to Network > Interfaces.
2. Edit an interface.
3. Enable the DHCP Server option and configure the settings.

To add a DHCP server on the CLI:

config system dhcp server edit 1 set dns-service default set default-gateway 192.168.1.2 set netmask 255.255.255.0 set interface “port1” config ip-range edit 1 set start-ip 192.168.1.1 set end-ip 192.168.1.1

next edit 2 set start-ip 192.168.1.3 set end-ip 192.168.1.254

next

end set timezone-option default set tftp-server “172.16.1.2”

next end

DHCP options

When adding a DHCP server, you can include DHCP codes and options. The DHCP options are BOOTP vendor information fields that provide additional vendor-independent configuration parameters to manage the DHCP server. For example, you might need to configure a FortiGate DHCP server that gives out a separate option as well as an IP address, such as an environment that needs to support PXE boot with Windows images.

The option numbers and codes are specific to the application. The documentation for the application indicates the values to use. Option codes are represented in a option value/HEX value pairs. The option is a value between 1 and 255.

You can add up to three DHCP code/option pairs per DHCP server.

To configure option 252 with value http://192.168.1.1/wpad.dat using the CLI:

config system dhcp server edit <server_entry_number>

set option1 252 687474703a2f2f3139322e3136382e312e312f777061642e646174 end

For detailed information about DHCP options, see RFC 2132, DHCP Options and BOOTP Vendor Extensions.

Option-82

DHCP option 82, also known as the DHCP relay agent information option, helps protect FortiGate against attacks such as spoofing (forging) of IP addresses and MAC addresses, and DHCP IP address starvation.

FG3H1E5818900749 (1) # show config reserved-address edit 1 set type option82 set ip 100.100.100.12 set circuit-id-type hex set circuit-id “00010102” set remote-id-type hex set remote-id “704ca5e477d6”

next

end

FortiGate-140D-POE (1) # set type

mac      Match with MAC address. option82 Match with DHCP option 82.

FortiGate-140D-POE (1) # set circuit-id-type hex      DHCP option in hex. string DHCP option in string.

FortiGate-140D-POE (1) # set remote-id-type hex      DHCP option in hex. string DHCP option in string.

Option-42

This option specifies a list of the NTP servers available to the client by IP address.

FortiGate-140D-POE # config system dhcp server

FortiGate-140D-POE (server) # edit 2

FortiGate-140D-POE (2) # set ntp-service local   IP address of the interface the DHCP server is added to becomes the client’s NTP server IP address. default      Clients are assigned the FortiGate’s configured NTP servers. specify       Specify up to 3 NTP servers in the DHCP server configuration.

FortiGate-140D-POE (2) # set ntp-service

FortiGate-140D-POE (2) # set ntp-server1

<class_ip>   Class A,B,C ip xxx.xxx.xxx.xxx

FortiGate-140D-POE (2) # set ntp-server1 1.1.1.1

FortiGate-140D-POE (2) # set ntp-server2 2.2.2.2 FortiGate-140D-POE (2) # set ntp-server3 3.3.3.3

FortiGate-140D-POE (2) # end