Getting Started with FortiGate: This book will take you from complete novice to expert user in simple, progressive steps. It covers all the concepts you need to administer a FortiGate unit with lots of examples and clear explanations.

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.

We are able to open the CLI from the browser as a part of the web-based manager or using a terminal connection that requires an RJ-45 to DB-9 serial cable and a terminal emulation client like PuTTY.

While the graphical interface is easier to manage and does not require knowledge of specific commands, the command line has some advantages:

Usually the package we receive contains at least the device, a quick start guide, a power cord, a CD-ROM containing software, and an RJ-45 to DB-9 serial cable.

Depending on the kind of license we have purchased, the device will have some or all of the available features:

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:

The basic configuration of a FortiGate can be performed using:

We will perform the basic configuration using the web-based manager. This requires:

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):

There is no mandatory order, so the following list is just a suggestion to have a checklist of things we need to do with a new FortiGate:

Changing the admin password, name of the host, time, and time zone

From the web-based manager use the System Information widget (by going to System | Dashboard | Status). Then perform the following steps:

1. Select the Change Password option in the Current Administrator row and insert the new password.

2. 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.

3. Navigate to System Time | Change | Set Time and set the FortiGate system date and time. Select your time zone and then click on OK.

See the following screenshot for the aforementioned options in the System Information widget:

Note

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.

Note

By default, FortiOS has the daylight savings time (DST) configuration enabled. To disable DST when daylight saving time ends, we have to use CLI with the following commands:

config system global | set dst disable | end

Selecting the operation mode and configuring the internal and external interfaces

The FortiGate unit can run in two modes: Network Address Translation (NAT)/Routing mode and Transparent mode. Both the modes are explained in the following list:

• 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:

Note

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.

Registering your FortiGate

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).

Note

Registration of our first FortiGate unit will also require a one-time registration on the Fortinet website with our company information.

Updating the system firmware

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:

Updating definitions and services

The previous steps have enabled the FortiGate unit to reach the Fortinet services and to acquire updates for all the services we are subscribed to.

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:

All the services should show a green flag, like the ones we can see in the following the screenshot:

Note

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.

VLANs and logical interfaces

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:

Note

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:

As mentioned, once the VLANs are defined, we can aggregate multiple ports into a single logical entity. Such a combination is a logical interface defined as a software switch.

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.

Usually we have two kinds of networks:

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.

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.

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:

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:

The following table contains a comparison of three widespread routing protocols: RIP, OSPF, and BGP.

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 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).

Configuring OSPF on a FortiGate

On each router that uses OSPF we will have to configure:

• Router ID

• Area

• Network

• Interfaces

OSPF router ID

Navigate to the Router | Dynamic | OSPF pane, router ID is defined here as we can see in the following screenshot:

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.

OSPF area

In the aforementioned OSPF pane we are able to create one or more OSPF areas. The configuration screen is shown in the following screenshot:

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.

• Cryptographic Authentication: Use a shared secret key based on the open MD5 (Message Digest type 5) standard encryption to authenticate all router traffic on a network.

Network

Here we will add all the networks that we want to communicate on OSPF and the area to which they will be associated, as shown in the following screenshot:

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.