About this book

FortiGate from Fortinet is a highly successful family of appliances enabled to manage routing and security on different layers, supporting dynamic protocols, IPSEC and VPN with SSL, application and user control, web contents and mail scanning, endpoint checks, and more, all in a single platform. The heart of the appliance is the FortiOS (FortiOS 5 is the latest release) which is able to unify a friendly web interface with a powerful command line to deliver high performance. FortiGate is able to give users the results they usually achieve at a fraction of the cost of what they would have to invest with other vendors.

This practical, hands-on guide addresses all the tasks required to configure and manage a FortiGate unit in a logical order. The book starts with topics related to VLAN and routing (static and advanced) and then discusses in full the UTM features integrated in the appliance. The text explains SSL VPN and IPSEC VPN with all the required steps you need to deploy the aforementioned solutions. High availability and troubleshooting techniques are also explained in the last two chapters of the book.

This concise, example-oriented book explores all the concepts you need to administer a FortiGate unit. You will begin by covering the basic tools required to administer a FortiGate unit, including NAT, routing, and VLANs. You will then be guided through the concepts of firewalling, UTM inside the appliance, tunnelling using SSL, and IPSEC and dial-up configurations. Next, you will get acquainted with important topics like high availability and Vdoms. Finally, you will end the book with an overview of troubleshooting tools and techniques.

Publication date:
November 2013
Publisher
Packt
Pages
126
ISBN
9781782178200

 

Chapter 1. First Steps

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.

The main advantages of the UTM viewpoint are:

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

Note

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.

 

Administering a FortiGate


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.

Note

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.

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:

  • To troubleshoot problems with the operation of a FortiGate as we are able to use the diagnose debug command 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.

Note

To allow SSH access to the CLI, we have to enable this kind of administrative access on at least one interface. The operation is performed as shown in the section, Selecting the operation mode and configuring the internal and external interfaces.

 

Unboxing the FortiGate and license options


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.

Note

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.

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

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

 

First access to a FortiGate


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:

  • FortiExplorer (a software for Windows and Mac dedicated to the first installation)

  • The CLI through the console port

  • The web-based manager

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

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

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

  • 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

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:

Restoring a device

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.

Note

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.

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:

 

Static routing


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:

  • Directly connected networks: The appliance will use the connected network interface as gateway (no explicit route is required).

  • Remote networks: A gateway is required and it must be on the same subnet of the FortiGate interface from which the traffic is exiting.

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.

Note

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.

Note

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.

 

Policy routing


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:

 

Dynamic routing


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.

Protocol

RIP (v2)

OSPF

BGP

Technology

Distance Vector

Link-state

Distance vector (path vector)

CIDR

Yes

Yes

Yes

Update

30 seconds plus triggered

30 minutes plus triggered

Triggered

Metric

Hop

Cost

Path attributes

Scalability

15 hops

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:

  • Exterior routing protocols: Best used to distribute routes between different companies or organizations (BGP).

  • Interior routing protocols: Designed to distribute routes inside a single organization (RIP and OSPF).

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.

 

Introducing OSPF


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

  • Reachable neighbors

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:

Interfaces

We must define the interfaces that will participate in the OSPF process by exchanging information. The operation takes place (again) in the OSPF pane.

 

Monitoring OSPF routes


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

 

Summary


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.

About the Authors

  • Rosato Fabbri

    Rosato Fabbri, 50 years old, has been the IT Manager for Need s.r.l. for the last 10 years. The company has more than a thousand users spread across eight sites (a national headquarters in Italy and a network of remote offices abroad). Need's network is entirely based on FortiGate appliances and on secure VPNs over the Internet. Rosato used his first FortiGate in 2003 and for him it was "love at first sight". He fully used the competitive advantage of Fortinet technology, both in functionalities and in features and that advantage made Need a use case, enabling the company to gain the trust of its customers and adding a lead over competitors.

    Browse publications by this author
  • Fabrizio Volpe

    Fabrizio Volpe is a Lync MVP and an experienced IT professional, with more than 15 years of experience working in the IT department of large-scale banking and financial companies. He has been working as a network and systems administrator in various firms of the Iccrea Banking Group (one of the top banking groups in Italy) since 2000. From 2011 to 2013, before moving his focus to Unified Communications, Fabrizio received the MVP award for Directory Services.

    Over the past few years, Fabrizio has participated as a speaker at many events and conferences (both Italian and international). He creates IT-focused content on different platforms that have received good feedback. His works are available on YouTube (http://www.youtube.com/user/lync2013), on his personal blog (http://www.absoluteuc.org), and on SlideShare (http://www.slideshare.net/fabriziov).

    Fabrizio has published three books with Packt Publishing: Getting Started with FortiGate,Getting Started with Microsoft Lync Server 2013, and Instant Microsoft Forefront UAG Mobile Configuration Starter. He has also authored a successful free e-book, Microsoft Lync Server 2013: Basic Administration, available in the TechNet Office gallery (http://bit.ly/1jbzpfo), which has been downloaded more than 25,000 times.

    Browse publications by this author
Book Title
Access this book, plus 7,500 other titles for FREE
Access now