FortiGate configuration, upgrade, modes of operation, network interfaces, CLI

Note: The description in the article is based on the FortiGate FG-300E with FortiOS version 6.2.3, which is configured as an FGCP cluster and uses VDOM.

I described many things and configurations of the FortiGate in the article Fortinet FortiGate, which was about version 5.6.3. In this article (and others), I will not describe everything again, so for some information, you can refer to the old version.

Documentation

Fortinet adds many new features and changes the principles of operation or configuration in the new versions. Unfortunately, the documentation lags behind. For version 6.2.3, there is no comprehensive documentation available. The documentation for each subversion describes something different, so it is really difficult to find any information (you have to go through a number of documents).

• FortiOS 6.2.3 Cookbook
• FortiOS 6.0.0 Cookbook
• FortiOS 6.0.0 Handbook
• FortiOS 6.2.3 CLI Reference
• Fortinet Knowledge Base
• Index of Knowledge Base articles
• YouTube David Adams FortiGate videos

Installation / Initial Configuration

The HW appliance FortiGate has a certain version of FortiOS installed and has a default IP address set on the MGMT interface. We connect to this interface and use the web interface (or CLI) https://192.168.1.99 to access the configuration. The user is admin without a password. Connecting using a web browser

We perform the basic settings, where we also set the interface for management, and then we connect the FortiGate to the network as usual.

• Network > Interfaces - setting the IP address and Administrative access
• Network > Static Routes - Default Gateway
• System > Settings - device name

FortiOS Upgrade

Documentation Performing a firmware upgrade, Firmware upgrade cluster.

• (Global) > System > Firmware

It's a good idea to read the FortiOS Release Notes, as there are sometimes major changes. Of course, create a backup. Have the current firmware version available in case you need to roll back.

Possible versions are offered, sometimes you need to upgrade to a lower version first and then to a higher version. It installs a patch within the version or a new version. The upgrade is fast, then a reboot of the device is required, which takes 2 to 3 minutes (FortiOS 5.6 in VM about 1.5 minutes).

Note: New versions are not always offered in the GUI (but we can download them manually from Support). I encountered an article Troubleshooting Tip: No firmware available from FortiGuard under firmware management. After several tests on two FortiGates, it seems the problem is more likely with the availability of the FortiGuard servers. Commands often return Timeout or Error, but occasionally list firmware.

In the case of an HA cluster, the upgrade also takes place automatically. First, the slave units are upgraded (Slave Node), restarted, the primary unit (Master) is switched, and its upgrade is performed. In the default setting (override disable, ha-uptime-diff-margin 300), the primary unit is often switched back. The Master is chosen based on the longer HA uptime, but it is ignored if the difference is less than 5 minutes (can be changed in the configuration). In the Active-Active cluster, Load Balancing is disabled at the beginning of the upgrade.

If we use Virtual clustering, the Master for Virtual cluster 2 is first switched (so that one physical FortiGate is the primary unit everywhere), and the upgrade of the Slave unit is performed. After the upgraded unit starts up, it waits (looks like 10 minutes). Then the Master is switched to the upgraded unit, and the second FortiGate is upgraded. Cluster synchronization occurs, and HA override ensures the Master-Slave setting on the virtual clusters. In the case of a cluster, the Firewall is almost constantly available, but each switch interrupts the established sessions (e.g., VPN).

After the upgrade, it's a good idea to perform a check to see if all policy objects have been transferred. The check is done by a command in the CLI (Technical Tip: After FortiOS upgrade, some of the ISDB objects in the policy are missing).

diag debug config-error-log read

Basic Configuration

If we use VDOM, some settings are global (Global) and affect the entire FortiGate. But most are set within the VDOM. These configurations must be performed in all created VDOM. It is necessary not to forget, for example, Feature Visibility.

• (Global) > System > Settings - Idle timeout, System Time (we must set our own NTP in CLI), Email Service
• (Global) > System > Settings - Administration Settings HTTPS port - a warning is often written here that port 443 is in conflict with SSL VPN, but if we have allowed admin access on another interface than SSL VPN (or not using it at all), we can ignore this
• (VDOM) > System > Feature Visibility
• (Global) > Network > DNS
• (Global/VDOM) > System > SNMP
• (Global/VDOM) > Log & Report > Log Settings
• (VDOM) > Log & Report > Email Alert Settings

Certificate Upload

• (Global/VDOM) > System > Certificates - Import - Local Certificate

As a local certificate, we upload server certificates, usually including the private key (we can also generate a request and upload a signed certificate). We use these certificates directly for FortiGate, SSL inspection, or server publishing.

Another option is remote certificates (Remote certificate). These are public certificates without a private key.

• (Global/VDOM) > System > Certificates - Import - CA Certificate

If the FortiGate does not know a certificate authority (CA), such as an internal one, it's a good idea to upload its certificate. When we import a CA certificate, its name is automatically set. We can change it only in the CLI

FW1 (global) # config certificate ca
FW1 (ca) # show 
config certificate ca
    edit "G_CA_Cert_1"
    next
end
FW1 (ca) # rename "G_CA_Cert_1" to Firma_Root_Authority

If we have uploaded and are using a Local Certificate, we need to have the certificate of its root CA in the system. In the case of a multi-level CA, the certificates of all CAs in the chain. Otherwise, we may get the error

fortigate certificate chain is incomplete

If we import a local certificate from PFX, which also contains Root and Intermediate CA certificates, we still need to manually upload the CA certificates.

More info Technical Note: How to avoid certificate error message by chaining Root CA and Intermediate CA certificates on FortiGate.

FortiGate System Operation Modes

Documentation Inspection modes (6.0.0), About inspection modes (6.2.3), Profile-based NGFW vs policy-based NGFW (6.2.3)

The way the FortiGate processes traffic and applies security functions is determined by several operation modes. These are the operation mode, inspection mode, and NGFW mode (or other related parameters). Previously (up to version 6.0.9), all modes were set globally for the entire FortiGate, or for each VDOM (if activated). From version 6.2.0, there was a major change, and the inspection mode is set per FW policy. Previously, a major change occurred in version 5.6.0, when the NGFW mode was added.

System Operation Settings

• (Global) > System > Settings - System Operation Settings

Global settings are located in the system settings in the System Operation Settings section. If we use VDOM, some configurations are in Global > System > VDOM. The choice is also found here

• VLAN switch mode - enables the ability to use VLAN switch, Virtual switch support for FortiGate 300E series

Operating Mode

We set the operating mode for the entire FortiGate, or for each VDOM in case of VDOM usage. The default is NAT/Route.

• NAT/Route - the standard mode for most situations, FortiGate acts as a gateway or router between networks, allows the use of NAT (or routing) and hides internal addresses
• Transparent - in transparent mode, FortiGate does not change IP addresses, it only performs security scanning of traffic, and it is placed between the internal network and the router

The switch is performed using the CLI

config system settings
    set opmode {nat | transparent}
end

Inspection Mode

• (VDOM) > Policy & Objects > IPv4 Policy

From version 6.2.0, the inspection mode is set in each policy (Firewall Policy) and the default is Flow-based. Previously, it was set globally for FortiGate (System > Settings) or VDOM (Global > System > VDOM) and the default was Proxy-based. Brief info Inspection Mode Per Policy.

• Flow-based inspection - compares patterns with a packet snapshot to identify security threats, provides greater performance, the packet content is checked packet by packet as it passes through the policy (not buffered), the last packet is held and waits for the test result, if a violation occurs, a reset is sent
• Proxy-based inspection - reconstructs the content passing through the policy and checks it for security threats, supports more configuration options, but is slower, the traffic passing through the policy is buffered for inspection (e.g., when downloading a file, receiving an email, all the packets of the file/message are stored, then checked as a whole), if a violation occurs, it is discarded and replaced with a replacement message, otherwise it is released to the destination, we need to handle large files

Note: In older versions, if we wanted to use Virtual Server with HTTPS (and other SSL protocols), we had to set the mode to Proxy-based. Now we set it per policy, so we just need to have a certain policy in this mode (for any Virtual Server to be used, the mode must be Proxy).

config firewall policy
    edit <policyid>
        set inspection-mode {proxy | flow}
    next
end

NGFW Mode - Next-Generation FireWall Mode

The NGFW mode is set globally for the FortiGate (System > Settings) or for the VDOM (Global > System > VDOM). The default is Profile-based. Previously, it was only available for the Flow-based Inspection Mode. The options are

• Profile-based - the traditional way, where we create profiles (Profile) for security functions (such as AV, Web Filter, Application Control, etc.) and apply them to policies (Policy), we define IPv4 Policy
• Policy-based - we can use application and URL categories directly in the policy (without creating a profile), always uses Central SNAT, we define Firewall Policy and Security Policy

We can also enable Central SNAT for the Profile-based NGFW mode. If we use Source NAT, we don't need to define it in each policy, but only centrally in Policy & Objects > Central SNAT.

Note: The documentation states that when switching between Profile-based and Policy-based, the policies will be converted. In practice, a message appears that the policies will be deleted, and this happens.

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

Network Interfaces

Documentation Interfaces (6.0.0), Interfaces (6.2.3)

• (Global/VDOM) > Network > Interfaces

Interfaces allow data flow between networks. Physical interfaces are the physical ports on the device. We can create many virtual interfaces.

Special Interfaces

Some special types are

• Zone - a zone is a group of one or more physical or virtual interfaces, policies then use zones (the interfaces included are not even offered), which can be a simplification (e.g., for grouping network segments), interfaces still have their own addresses and routing (not affected by zones), when using VDOM, zones are configured within VDOM and not globally, so they can have the same names (other interfaces must have a unique name)
• Virtual Wire Pairs - logically binds two physical interfaces, traffic that comes in on one interface can only go out on the other interface (if allowed in the Virtual Wire Pair Firewall Policy)
• VDOM Link - internal connection between virtual domains (VDOM), which enables Inter-VDOM routing

Note: I encountered a recommendation to use zones, even if we don't need to group interfaces. But to include each interface in a Zone. In the policies, we then use zones, if we need to make an interface change, we include a different one in the zone and the policies still work.

Note2: That's how I solved it in practice, I needed to change an interface. Using zones is great, but there are still many places where a zone is not specified, but the interface directly, so a lot of adjustments are needed. For example, static routes and Virtual IP. The reference display feature is useful.

Interface Types

We create most interfaces using Create New - Interface and then choose the Type. We also select a different interface/port (or multiple ports) on which the new interface will be created. Some of the possible types are:

• VLAN - we can connect a physical interface to the network as a trunk (IEEE 802.1Q) and create interfaces (subinterfaces) for individual VLANs on it by VLAN ID, when using VDOM, we include the VLAN interface directly in the VDOM (we don't need to put the interface on which the VLAN is created)
• 802.3ad Aggregate - we combine physical interfaces into an aggregated interface
• Redundant Interface - we combine physical interfaces into a redundant interface
• Software Switch - logical connection of physical ports (we can also connect with a WiFi interface) into a switch, devices on the ports can communicate with each other (policies are not applied), they are in the same subnet, the switch has one IP address, behaves like one interface
• Hardware Switch - connection of ports that are part of an integrated switch
• VLAN Switch - virtual switch that can have ports in different VLANs
• Loopback Interface - virtual interface that is always up (link up)
• EMAC VLAN - Enhanced MAC VLAN allows creating several virtual ones with different MAC addresses on a physical interface
• VXLAN - Virtual Extensible LAN encapsulates L2 frames in L3 packets, creates a VXLAN tunnel terminated on a physical or virtual switch port (VXLAN Tunnel Endpoint - VTEP), configuration only in CLI

The 802.3ad Aggregate and Redundant Interface interfaces are described in more detail in the chapter Redundant Network Connection of the article FortiGate High Availability cluster and Virtual Domains (VDOM).

We can combine interfaces in various ways. For example, we can combine two physical ports into a virtual 802.3ad Aggregate Interface set as a trunk, so we can create several VLAN subinterfaces over it.

Note: Other interfaces include VPN tunnels.

Interface Roles

We set a role for the interfaces, which can be used for a certain identification, and in the GUI causes the display/hiding of certain interface settings.

• Undefined - no specific role, displays everything (except for creating an address object)
• WAN - connection to the internet, many settings are hidden, but Estimated bandwidth is available
• LAN - end devices in the local network
• DMZ - servers in the DMZ

Some Interface Settings

Interfaces have many settings, depending on the type and selected role. Some options are:

• Address IP - for most interfaces, we manually set the IP address (which then serves as the gateway for the given network segment) and the network mask
• Secondary IP address - we can also add multiple IP addresses and specify Administrative access for each
• Create address object matching subnet - the option is usually enabled by default, which creates an address object with the same name as the interface (this is certainly useful, but maybe we want to name it differently)
• Administrative access - we allow various types (protocols) of administrative access through this interface, we want to allow most only for the Management interface
• Security mode - allows enabling Captive Portal for authentication
• Device Detection - passive collection of information about devices behind this interface
• Outbound shaping profile - we can enforce a bandwidth limit for the interface

config system interface
    edit "<Interface_Name>"
        set ...
    next
end

Routing - Static Routes

Documentation Advanced static routing

• (VDOM) > Network > Static Routes

We probably always need to set the Default Gateway (Route) for the destination 0.0.0.0/0.0.0.0. We often need additional specific routes (we don't need to define them for directly connected interfaces).

• (VDOM) > Monitor > Routing Monitor

Here we can view the routing table.

Command Line Interface (CLI)

Documentation CLI Reference - Using the CLI

Everything we set up using the GUI is converted into commands. We can perform the configuration directly in the command line (CLI), which provides a lot more options. We can access the command line directly in the web browser GUI, where there is a button >_ (CLI Console) in the top right corner. Otherwise, we can connect in the usual way, using the local console (serial port) or SSH.

There are a number of rules for using the CLI and the syntax of the commands. When entering commands, we can use:

• Tab - completes the command based on the entered characters, another press goes through the options
• ? - displays the possible commands
• up and down arrows - browse through previously used commands
• \ and ENTER - allows entering a command on multiple lines (goes to the next line without executing the command)

Filtering Output

After the commands get, show and diagnose, we can use the grep command to filter the results. We can display the lines that contain a certain string.

FW1 # get hardware nic mgmt | grep HWaddr
Current_HWaddr      00:09:0f:09:00:01
Permanent_HWaddr    04:d6:90:53:33:0a

We can also use some switches, an interesting one is the contextual output of part of the configuration.

FW1 (INT) # show | grep -f full-access
config vpn ssl web portal
    edit "full-access" <---
        set tunnel-mode enable
        set web-mode enable
        set ip-pools "SSLVPN_TUNNEL_ADDR1"
    next
end

Nested Commands, Using next, end

Commands in the FortiOS configuration are nested into each other, and within a given scope (scope), certain subordinate commands are available. When displayed, the indentation determines the nesting level. To end a block (more precisely, a table item or object), the next and end commands are used.

It's important that when entering commands in a certain block/item, they don't take effect immediately, but only after saving. These commands perform the saving. The next command is used within the same level to end the edit, where we end one table item and another may follow. The end command ends the block and takes us one level up.

If we don't want to save the changes, we can use abort.

Viewing Configuration

We can use the show command at any time, which displays the configuration commands (changes from the default configuration) at the given level (object/table). We can also view the configuration including the default values using the show full-configuration command.

Viewing Logs and Debug

In the command line, we can display and filter logs. Documentation Technical Tip: Displaying logs via CLI.

To troubleshoot, it is useful (and often necessary) to enable debug for a certain area using the diagnose debug command. Documentation Technical Tip: How to use debug flow to filter traffic. It might be helpful to enable displaying the timestamp in the output.

diagnos debug console timestamp enable

Automatic Configuration Backup

Documentation Technical Tip: How to send automated backups of the configuration from a FortiGate and How to add multiple commands in the CLI script, FortiOS CLI execute backup

We can manually perform a configuration backup by clicking on the logged-in user in the top right corner and selecting Configuration - Backup.

Using the CLI, we can create a script that will run repeatedly at a given interval (interval) for a certain time (repeat, 0 is forever). It will execute a command that saves the backup to an FTP server. The example below is when using VDOM.

config system auto-script
    edit "BackupFTP"
        set interval 86400
        set repeat 0
        set start auto
        set script "
config global
execute backup config ftp FortiGate/backup.conf 10.0.0.10 user password"
    next
end

Viewing the script result

FW1 (global) # execute auto-script result BackupFTP 
Script BackupFTP output:
########## script name: BackupFTP ##########

========== #1, 2020-04-16 08:05:41 ==========

Commands that display the status of the scripts or stop a script.

execute auto-script status
execute auto-script stop BackupFTP