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

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.