Fortinet FortiGate is a line of products that includes a series of network appliances. An appliance is defined as a discrete hardware device with integrated software, optimized to give specific features. The single device integrates networking and security features to achieve what is called a Unified Threat Management (UTM) approach to security.
Consolidation of security functions on a single device. We are not required to reiterate several times the same filters on different devices.
Consolidated administrative interface based on a single management console.
Consistent updates across all the devices involved in UTM.
Based on the aforementioned approach to security, a FortiGate is able to grant:
Networking services at layer 2 and layer 3 (switching and routing, both static and dynamic)
Network security services (firewalling, secure VPN connection, intrusion detection, and endpoint security)
Application security services (spam and virus controls, web filtering, application control, and data leak prevention)
Fortinet uses proprietary chipsets and a processor known as a Content Processor (CP) ASIC. The main advantage of this architecture is to address the performance issues that could be associated with the UTM approach. For more details see the FortiGate Hardware Guide: http://docs.fortinet.com/fgt/handbook/40mr3/fortigate-hardware-40-mr3.pdf.
We are able to manage one or all the aforementioned security features from one of the administrative tools of the device, a graphical interface (the web-based manager), and a command line (CLI). In the following screenshot, we can see the dashboard of the web-based manager and the CLI paired in the same screen:
Access to the web-based manager requires a browser and an Ethernet connection between the FortiGate unit and the administrator's workstation.
The CLI can be used inside the graphical dashboard or we can detach it to use the command line in a separate window. The CLI is also the only administrative access we have when we access a FortiGate from a Telnet (or SSH) connection.
A Telnet session uses clear text in all transmissions. Everything we type during a Telnet session, including passwords, is basically readable on the network. SSH encrypts information and makes it unreadable. If we have the option to select a connection type, SSH is to be preferred over Telnet.
To troubleshoot problems with the operation of a FortiGate as we are able to use the
diagnose debugcommand in the CLI console. This is something we will see in more detail in Chapter 5, Troubleshooting.
To script and automatize operations.
For accessing configuration items that are only available using the CLI. An example is the FortiGate Session Life Support Protocol (FGSP) explained in Chapter 4, High Availability.
To apply modifications and changes on multiple devices in a reliable and less error prone manner.
The software included in the box is usually older than the one we are able to download from the Internet. After the registration procedure described in this section, we can download the updated release of all the required firmware and software.
FortiCare: It is the less costly option and includes hardware support and software upgrades. This license enables the use of the FortiGate as a networking device with the capability to configure intranets (also using VPNs).
Bundle: This license adds updates for the UTM features like antivirus, web filtering, IPS, and anti-spam.
A third option: Buying one or more single UTM features instead of the full bundle is available for medium and high end devices.
Features can be enabled or disabled based on our needs. We can also buy some features as an additional option to our license later on and activate them as soon as the new options are available. This is done using the Features option in the Config widget. The related pane is shown in the following screenshot:
Depending on the model of FortiGate, we will have different number of interfaces and their disposition will change. Some models have ports labeled as Internal and External, whereas other Fortigate units will have ports labeled port1, port2, and so on. Every FortiGate unit will also have a console port (RJ45 or RS-232 on older models). The console port can be used to directly connect a workstation or terminal server for out-of-band access. An example can be seen in the following diagram, showing and RJ45 management port and WAN interfaces on a FortiGate 100D:
FortiExplorer (a software for Windows and Mac dedicated to the first installation)
The CLI through the console port
The web-based manager
A computer configured with an IP address on the 192.168.1.0 network (with subnet mask 255.255.255.0). For example, 192.168.1.100.
An Ethernet cable to connect the computer to one of the following interfaces (depending on the FortiGate model): internal, port1, or management.
The device should respond on the default IP address 192.168.1.99, then we can open the web-based manager with a browser using the following URL:
https://192.168.1.99. The default user (
admin) does not require password (see the following screenshot):
Name of the host
Time and time zone
Selecting the operation mode and configuring the internal and external interfaces
Registering your FortiGate
Taking a backup of the existing configuration
Updating the system firmware
Updating definitions and services
Select the Change Password option in the Current Administrator row and insert the new password.
Select the Change option in the Host Name row and insert the preferred name (it is a good idea to keep a naming convention that helps identifying the device location and use on our network). Note that as soon as we modify the host name, the CLI prompt will also change to reflect the new parameter.
Navigate to System Time | Change | Set Time and set the FortiGate system date and time. Select your time zone and then click on OK.
Host Name and Serial Number will be required to register the unit with Fortinet. Take note of this information now to save time later.
It is worthwhile to add an NTP (Network Time Protocol) server to keep time synchronization for the FortiGate. We can navigate to the System Time options to select FortiGuard or a specific NTP source as we can see in the following screenshot:
As we have just seen, a FortiGate unit can also act as an NTP server for our network (that makes sense especially if the unit is acting as a gateway between our internal network and the Internet). We have to select the interfaces that will be listening to the clients' NTP queries.
Network Address Translation (NAT) mode: If the FortiGate is deployed as a gateway between different networks, we have to use this mode. Each network interface will need configuration parameters. The appliance will filter the traffic and translate the network address when traffic flows from one interface to the other. This is the default mode for a FortiGate unit.
Transparent mode: In this mode, all the interfaces of the FortiGate are on the same network and the appliance is not visible to the rest of the network. The FortiGate unit acts as a bridge between different network segments. The idea is to perform filtering (anti-spam, antivirus, intrusion protection, and traffic scanning) behind an existing router or firewall on a relatively simple network.
To configure the NAT mode, we need to configure a network address on our interfaces by navigating to the System | Network | Interface menu. Usually we need to configure at least one internal (LAN) interface and an external (WAN) interface. The following screenshot displays the configuration of a WAN interface (with a static public IP address):
Since we are talking about a public network adapter, it is advisable to remove all Administrative Access options (unchecking the appropriate boxes), perhaps leaving only the ping access for testing. As part of this first installation it is recommended that we also set our FortiGate to use one or more public DNS compatible with our providers or accessible from our connection. We can go to the Network | DNS menu and edit the server option as shown in the following screenshot:
To achieve an initial connection to the Internet (or to the rest of the corporate network) we should set up a static route by going to the Router pane | Static Route option as shown in the following screenshot:
The router pane only exists in medium business and higher models. The desktop versions like the 40C model have the routing open under the System pane. This area under the System pane is only for creating static routes. All dynamic routing has to be done through the CLI for desktop models.
As mentioned earlier in this chapter, the administrative interface allows the management of different levels of operation of the FortiGate unit. A good example is the one we have just seen, with the routing layer included in the Router pane and not in System as for the previous parameters.
To configure transparent mode, we need to set a management IP address (the one we will use to administer the FortiGate unit). This makes sense because in transparent mode the appliance has no other network addresses exposed. From the web-based manager we will again use the System Information widget (by navigating to System | Dashboard | Status). In Operation Mode we have to click on Change and then select Transparent. We will immediately be required to add a management IP and a gateway (to make it reachable also from a different subnet). We can see the two steps in the following screenshot:
Then we will have to configure the DNS servers as we have seen for the NAT mode.
We should register our FortiGate at the earliest on the Fortinet support site, following the links that we can see in the following screenshot. There we are able to find all the updates related to our device and to activate the features associated with our FortiGate unit license:
As we stated earlier, host name and serial number are required to register a FortiGate unit (the information is available in the System Information widget).
Device registration entitles us to download the most recent version of the firmware (the base set of instructions stored in our device) and to apply it to our FortiGate unit. Once we have acquired an appropriate software update from the support site we can upgrade the firewall. The operation is made in the Firmware Version widget selecting Update as shown in the following screenshot:
The aforementioned widget is also used to read the current version of our firmware. We must always make a backup of the configuration of the appliance before applying any firmware update (especially if we have to work on a unit that is already operational). Backups (and restores) are performed by navigating to System Information | System Configuration | Backup (or Restore) as shown in the following screenshot:
To restore a device after a faulty update, we can use the CLI from a console connection. The steps are described here: Verifying the current firmware version and upgrading the FortiOS firmware (http://docs.fortinet.com/cb/html/index.html#page/FOS_Cookbook/Install-basic/update_firmware.html). For a detailed description of the CLI commands related to backup and restore use the document available at: http://docs.fortinet.com/fdb/html/fdb-user-guide/index.html?page=source%2Freferences%2Fr_cli_admin_execute.html.
The Release Notes of the different versions of FortiOS and firmware contain a section named Upgrade Information. It is really important to read them because updating from one version to the other may require some intermediate steps. There could be well known issues and limits as well as information about fixed and known bugs.
It is not required to add security policies for this purpose. We can verify that the connection from the appliance to the Internet is working by pinging the name of a public site from the CLI using the command
execute ping <hostname> (for more information see Layer 2 and Layer 3 TCP/IP Diagnostics, in Chapter 5, Troubleshooting).
The updates for the different features and licensing inside our FortiGate are unified inside a single mechanism that is called FortiGuard. We are able to see the status of our license registration by navigating to Config | FortiGuard. Services should be registered automatically and updates should be received from Fortinet by default. We can verify that the Allow Push Update flag is selected (see the following screenshot). In the same screen we are able to force the update process by clicking on the Update Now button:
If an error is shown in the aforementioned menu, probably we will have to get in touch with the Fortinet support at http://www.fortinet.com/support/contact_support.html.
FortiGate supports the segregation (and aggregation) of network interfaces with the use of VLAN (virtual LAN). The basic idea of a VLAN is to keep the traffic of networks that we want to segregate at the physical layer (layer 2) within the same device. We are able to combine multiple logical networks on a single interface and filter traffic between them while retaining the capability. While there are different standards in order to obtain this result, Fortinet has used the international standard IEEE 802.1Q. Each Ethernet frames will have a tag, which indicates a single VLAN membership. Network interfaces will be able to receive data from one or more VLANs, but will discard all communications related to VLAN to which they do not belong. The traffic will pass from one VLAN to another only through layer 3 (routing) thus realizing the physical separation within networks with a single device that we talked about. To define a VLAN in a FortiGate we will navigate to the System | Network | Interface menu and select Create New Interface as shown in the following screenshot:
Now we can specify the network adapter to associate with this VLAN and its ID tag as we can see in the following screenshot:
The interface will be seen as untagged if connected to an untagged device (for example, a PC) and tagged if connected to a port with VLAN enabled, like a layer 2 switch.
Repeating the aforementioned operation with a different VLAN ID, but on the same interface, we will obtain what is commonly referred to as a trunk. A trunk is a way to accept multiple VLANs on a single interface. This is required, for example, when we have a device (let's say a switch) for the upstream of a FortiGate, that receives tagged traffic from different VLANs and then forwards it to the Fortigate. An example is shown in the following diagram:
A software switch groups physical interfaces in a software interface (also called a softswitch). All the interfaces in a softswitch share one IP address and become a single entry on the interface list. This method can be useful to aggregate different interfaces that are on the same subnet without creating a firewall policy. A good example for this would be combining a wired and a wireless interface so that clients on the wireless interface can see devices on the wired network. A softswitch is configured using the interface menu and selecting Type as Software Switch. The base configuration can be seen in the following screenshot:
Talking about logical interfaces like the softswitch, it is also important to introduce the Loopback Interface. It can be generated inside the firewall and does not require a physical interface. Loopback interfaces are always up and reachable and are used, for example, to configure a unique IP for a service that is common to more than one of the networks connected to the FortiGate unit (for example, to deploy a proxy service). Loopback interfaces are also commonly used with dynamic routing. The configuration is shown in the following screenshot:
A loopback interface requires much of the same configuration options that a physical interface does. The menu used to configure an interface contains the options explained in the following screenshot:
After introducing some of the basic concepts related to the network interfaces, it is now necessary to examine the routing of data packets inside a FortiGate. Routing is the process of moving data from one network to another. The easiest method to handle routing is to create static routes that define the next step (gateway or hop) towards a given network. A gateway is a networking device that acts as an entrance to another network. It could be directly connected to the remote network or may know a route to the required network and be able to forward the packets to another gateway.
Static routes can be configured by navigating to the Router | Static | Static Route menu. In the following screenshot we can see a default route that will send all the traffic to networks with no specific route to the default gateway (192.168.1.1 in our example):
Two parameters require additional explanation: Distance and Priority.
Talking about static routing, distance is typically used as an indicator of the quality of a connection. A connection of 100 Mbps will have a distance lower than an ISDN connection. So, if you have two routes to the same destination but with different costs, the lower cost route will be used. The distance can be a value between 0 and 255.
In case we will also use dynamic routing protocols, the dynamically received routes will have their own default administrative distance. In this scenario, not all values will be available. This topic will be addressed in the section Dynamic Routing.
If we have two connections of equal quality (equal distance) but we want to use one of the two, we can adjust the "priority" parameter. The route with the lower priority is considered preferable and will be used. Priority can be a value between 0 and 4,294,967,295.
The workload is automatically balanced on two or more routes having equal distance and priority.
One of the limitations of static routing is the inability to detect network changes and network failures. For example, a backup route (inserted with higher cost) will never be used, unless the link status of the physical interface with the lower cost route is in a status of "link down". Even for load balancing, if the interfaces are seen as "link up", the packets are sent to both, even if the gateway of one of the two is not reachable. We will talk about interface monitoring in the section FortiGate Cluster Protocol (FGCP) in Chapter 4, High Availability.
The policy routing feature allows us to force the traffic on a route different from the static route that we use for a certain destination network. Policy routing is based on a series of parameters such as protocol used, source network, and the input interface of the network traffic. Policy routing adds a lot of flexibility, allowing, for example, to select and direct requests to specific service networks dedicated only to specific functions. The configuration is made by navigating to the Router | Static | Policy Route menu as shown in the following screenshot:
Two of the fields that we can see in the preceding screenshot require additional explanation:
Protocol: Protocol numbers are based on the RFC 5237. You can read a complete list at http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml. Frequently used protocol numbers are 1 (ICMP), 6 (TCP), and 17 (UDP).
Type of Service: Type of service (TOS) is an 8-bit field in the IP header that enables you to determine how the IP datagram should be delivered, with qualities such as delay, priority, reliability, and minimum cost. You can read more details in the document Advanced Routing available at http://docs.fortinet.com/fgt/handbook/50/fortigate-advanced-routing-50.pdf.
Every time you create a policy route, it is added to the bottom of the routing table. The routes and routing policies are applied from top to bottom and the first match is applied. To change the position of a policy route in the table, go to Router | Static | Policy Route and select the Move To option for the policy route we want to move, as shown in the following screenshot:
Unlike static routing, dynamic routing is based on information exchanged between network devices to select the best available route to a certain destination. This adds scalability and adaptability that does not exist in static routing. Dynamic routing uses one or more Routing Protocols that create, maintain, and update the dynamic routing table. The logic and the algorithms used vary from one protocol to the other and in every scenario there is one or more routing protocol that better fits to the networking needs. The protocol that we will select depends on a number of factors. Before we can compare the different protocols with each other it is necessary to introduce three basic concepts: convergence, technology used to calculate the best route, and protocol support for Classless Inter-Domain Routing (CIDR). The concepts are explained in the following list:
Convergence: Each routing protocol has a different method to update the routing table. This will affect the time to converge the routing tables.
Technology: The two main methods are Distance Vector and Link-State. Distance vector protocols use a distance value that is based on the number of hops (devices along the path) to the destination. Distance vector protocols usually send the whole routing table to their neighbors as soon as there is an update. Link-state protocols use information sent from all the connected devices and are related only to the directly connected networks. Link-state protocols also take into account other factors when making routing decisions such as bandwidth. The routing information is sent in incremental form.
Support for CIDR: Routing protocols include classful protocols that do not send subnet mask information with their routing updates. With the other kind (classless routing) a series of addresses can be combined into one entry also because subnet mask information is transmitted.
The following table contains a comparison of three widespread routing protocols: RIP, OSPF, and BGP.
Distance vector (path vector)
30 seconds plus triggered
30 minutes plus triggered
Around 50 routers per area, a few hundred areas
Thousands of routers
Routing protocols are also divided into two categories that determine the most suitable use scenario:
Each of the protocols listed has its own method of operation. RIP is less complex to manage, but due to its characteristics, it can be considered suitable only for networks of very small dimensions. OSPF and BGP are more complex but will give a much greater scalability. Being the most commonly used protocol, OSPF will be the routing protocol explained in the text.
Open Shortest Path First (OSPF) is an Interior Gateway Routing Protocol and uses the concept of Autonomous Systems (AS). AS is either a single network or a group of networks controlled by a common network administrator (or organization). Each router has an identical database that includes information on:
The single router
The current state of a router
The state of the router's interfaces
The aforementioned database is called Link State Database (LSDB) and is built on each OSPF router receiving LSA (Link-state advertisement , the base communication of the router's local routing topology) from every other router in the same AS. To keep track of LSAs in the LSDB, each router is assigned a router ID. It is a 32-bit dotted decimal number that is unique to the AS. The router ID identifies the router in the AS and usually is the largest or smallest IP address assigned to the router. IP addresses are unique so this convention ensures that the OSPF router IDs are also unique.
To minimize the routing traffic and the amount of information required, OSPF allows to group networks into a set, called an area (identified through a 32-bit area ID expressed in dotted decimal notation). The topology of an area is hidden from the rest of the autonomous system. Routing takes place on two levels, entirely within an area (intra-area routing) or in another area (inter-area routing). To link together multiple areas and to allow inter-area routing, OSPF uses the concept of Backbone. An OSPF backbone is made by routers linking the other areas (that is, all the areas must have a direct or virtual connection to the backbone). Such connections are maintained by an interconnecting router, known as Area Border Router (ABR). An ABR maintains separate link state databases for each area it serves and maintains summarized routes for all areas in the network. An OSPF internetwork always has at least one backbone area. The backbone has the reserved area ID of 0.0.0.0 (and is also known as area 0). Inter-area traffic is routed to the backbone, then to the destination area, and finally to the destination host. Routers on the backbone also advertise the summarized routes within their areas to the other routers on the backbone.
A router configured with the OSPF protocol tries to find its neighbors (other routers using OSPF, connected to the same subnet, and that are part of the same area). As soon as their LSDB is synchronized, the two routers are said to be adjacent. Routing protocol packets are only passed between adjacent routers.
The last aspect to be discussed is that when routers are connected to the same broadcast segment (for example, same VLAN on the same switch) only one router maintains adjacencies with all other routers on the segment. This is the Designated Router (DR). Having a single router do all this reduces the network traffic and collisions. For redundancy purposes a Backup Designated Router (BDR) is also elected. An election chooses the DR and BDR from all the available routers. The election is based on the priority setting of the routers and (to resolve any tie) the router with the highest router ID is elected. We are able to configure the priority value so that a router is always or never elected (highest priority will always win on lowest values).
The advanced options enable the router to redistribute directly connected networks, static routes configured on the device, and information coming from other routing process (RIP and BGP) using the OSPF routing updates. The metric of the aforementioned routes can be changed from the default value.
The redistribution of routes, at this level, is not selective, but works on an entire category (for example, re-transmit all the routes directly connected to the router). We'll probably filter some routes using access lists (ACLs). An ACL is a list of rules that are applied from the top of the list. Each rule in an access list consists of an IP address, a subnet mask, and an action (permit or deny). If no matching rule is found, the default action is always a deny. The ACLs are configured from the CLI with the
config router access-list command. A more detailed explanation can be found in the FortiOS CLI Reference for FortiOS 5.0 at http://docs.fortinet.com/fgt/handbook/50/fortigate-cli-50.pdf.
An OSPF area can be a:
Backbone Area (Area 0): This area is always required and is used to link together different areas. Sometimes this is the only OSPF area used.
Not-So-Stubby-Area (NSSA): Propagates external (not OSPF) routers presenting them to the other router as OSPF members.
Stub Area: Stub area can contain a single entry and exit point (a single ABR), or multiple ABRs when any of the ABRs can be used to reach external route destinations.
Regular Area: Area can be connected to the backbone by physical or virtual link. Regular area can contain both internal and external routes.
All OSPF packet traffic is authenticated and we have three options:
Null Authentication: There is no authentication being used (none option).
Simple Password Authentication: We will use a plain text string. It is not a strong form of security because passwords are exchanged in clear text on the network.
By default, all routes are displayed in the routing monitor list. When the OSPF process is active, we can see the route received by navigating to the Router | Monitor | Routing Monitor pane, as we can see in the following screenshot:
The Type column indicates the way we learned a route to a specific network (shown in the Network column). The administrative distance will decide the preferred route if more than one route is available for a destination network, while the Metric value will be used to select the best route among the ones known through a specific routing protocol. For OSPF there is an additional parameter, Subtype. The subtype field shows a value equal to External if the route is from outside of the AS. If the route is received from a not-so-stubby area, the value would be (OSPF NSSA).
In this chapter, we learnt some basic concepts and fundamental tools for management of a FortiGate. We also deep dived into VLANing and routing covering OSPF in particular. In the next chapter we will talk about Fortinet's approach to UTM, including FortiClient and FortiGuard. We will also look into web filters, antivirus, antispam, and endpoint security.