Fortinet FortiGate and more

FortiGate is Fortinet's advanced firewall (security gateway), referred to as the Next Generation Firewall (NGFW). There are a number of models that are either physical (hardware appliance) or virtual (for different hypervisors - VMware vSphere, Microsoft Hyper-V, Citrix XenServer, OpenXEN, KVM). Here we are focusing on the virtual version, but it doesn't matter too much because all FortiGates are running the same FortiOS operating system. This article describes how to get the virtual version of the Fortinet FortiGate VM00 up and running. The following is a brief description of the main operations, settings and creation of communication rules. Various advanced features are briefly mentioned at the end.

FortiAnalyzer is a centralized logging tool, primarily for FortiGate, but also supports other Fortinet devices. It allows you to collect logs from multiple devices (and group or split them), perform analysis on them and generate reports. The focus is on security and providing insight into threats. It has broader capabilities than logging locally on FortiGate and most importantly supports much longer data history. It can be a HW appliance or a virtual machine.

The firewall at the perimeter of the network is our central point for access to the Internet and other networks. We certainly don't want it to be a Single Point of Failure, so we need to address redundancy and preferably a cluster to ensure High Availability. The cluster solves for us a unified configuration and switching of units in case of failure (not only devices, but also lines). When we have purchased two devices, we may want to make the best use of them. Virtual Domains (VDOMs) can be useful for some situations. These allow us to divide FortiGate into several parts that work independently. Thus, to create several virtual firewalls from one device (or cluster).

FortiGate supports different types of users and user groups. Users can authenticate not only locally, but also to external servers. Authentication against an LDAP server is useful, so we can use users in a Microsoft domain (Active Directory Domain Services). We can use users and groups in security policies or if we are creating a VPN connection. Even FortiGate unit administrators can log in with a domain account.

Last time, we described user accounts on FortiGate and authentication locally or against remote servers (LDAP). Today, we'll take a look at multi-factor authentication (MFA) options. Specifically, the use of a digital certificate to log into an SSL VPN. We'll show how we can use the more common user certificate as well as a computer certificate.

Another sequel that looks at the possibilities of multi-factor authentication (MFA) on FortiGate. We will look at two-factor authentication (2FA) using an OTP (One-time Password) sent to an email or as an SMS message. The use case is for logging into an SSL VPN, but we can use it elsewhere as well.

After a few introductory articles that covered user authentication, there is an extensive piece on SSL VPN configuration. I tried to make the description very comprehensive, as I find the official documentation insufficient. A few simple steps are all you need to create a basic VPN connection (examples are in the official documentation). This article should also show all the special options we can set up. It focuses on the links between the different parts of the configuration. And it tries to take a global view that goes into describing the details.

In this article, we'll add a final section to the previously described creating an SSL VPN on FortiGate. We'll cover client checks when connecting to an SSL VPN. We can check a number of things on the client and decide whether or not it can connect to the VPN based on the result of the check. We can only perform the checks on a Windows operating system (a little bit on a Mac). We can check the operating system version, the presence of antivirus and firewall, the client MAC address, the existence of a certain file, process or key in the registry.

The article deals with the basic configuration (installation and upgrade) of the physical appliance Next Generation Firewall Fortinet Fortigate. It describes the possible modes of operation (operational mode, inspection mode and NGFW mode). It discusses the physical and virtual network interfaces. Mentions the basics of using the command line interface (CLI). Finally, the ability to automatically back up the configuration.

Connecting a company to the internet is nowadays essential and is usually required to be fail-safe (within reason). We can use one ISP that solves high availability (redundancy) by its own means (e.g. by bringing two independent fiber optic routes). Or have two (or more) different ISPs, then we have to deal with line usage and possible switching ourselves. We may also have two lines to the internet and want to manually split the traffic. FortiGate has several options to deal with these situations. Most of our focus is on SD-WAN. Quite important is the question whether we only deal with Internet access or also publish some services on public IP addresses.

The basic feature of the Firewall is network traffic control. This is done by defining security policies. In this article, we look at the basic properties of policies. Next, we will discuss Network Address Translation (NAT) options. First, translation of the source address for client communication to the Internet. Then also the translation of the destination address for server publishing. This is also related to Server Load Balancing. Let's describe the basic objects for policies such as services and addresses. Finally, there is a brief mention of traffic troubleshooting capabilities.

I am gradually adding to the article and also testing various things on newer versions. So it's not just FortiOS 6.2.3, but 6.2.x and 6.4.x in general. We deployed FortiGate Firewalls a few months ago, and I've been dealing with a number of issues ever since. I think many of them are not due to my ignorance or configuration error, but a bug in FortiOS itself. I even contacted Fortinet Support with one thing and will share my bad experience here. I decided to write down the issues I can recall, and for the biggest one, describe the steps I took to determine the cause of the problem.

It is generally not recommended to use any form of address translation (NAT) for IPv6. It would be better to use, for example, Dual Stack and have IPv6 addresses on the Front End servers along with IPv4. But there may be situations where we need to make an existing service available over IPv6 in the simplest way possible. We have NAT64, where we publish an address to the IPv6 network that we translate to an existing internal IPv4 address. No change is needed on the servers. Unfortunately NAT64 Policy on FortiGate has a number of limitations, mainly it does not support any Security Profiles.

I've tried to put together a brief description of how the IPsec protocol works for establishing VPNs. Primarily the article focuses on Site to Site VPN using IKEv2 (and ESP). I have not studied the RFC, the information is from various articles on the internet, mostly from manufacturers (focused on Fortinet). The theory focuses on individual terms and point descriptions. The following is a tentative description of how to configure an IPsec VPN on FortiGate. The rest of the article covers how to perform monitoring, troubleshooting, and debugging. It also mentions problems I have encountered.

The article builds on the previous descriptions of user authentication and adds authentication against an external RADIUS server. We can also use it for users in the Microsoft domain (Active Directory Domain Services), for example for authentication to SSL VPN. Let's take a brief look at the Network Policy Server (NPS) configuration. Mainly on the way to transfer information about the user's inclusion in the group.

Let's take a look at an old known issue where FortiClient connecting to the SSL VPN on FortiGate gets stuck or terminates at 98 percent. This issue should have been resolved in FortiClient 5.6.0. However, according to discussions, it still occurs in newer versions. There are various hints to solve it, but in our environment, the one I haven't seen mentioned anywhere helped in the end. Disable DTLS and connect classically using TLS. We'll also take a look at the SSL VPN debug on FortiGate.

FortiGate supports the SAML protocol, which we can use for user authentication. One of the places where we can use it is to log administrators into the web interface (GUI). And one source of identity can be Microsoft Azure Active Directory (Azure AD). Authentication against Azure AD allows us to use Conditional Access. For example, we can use it to set up multi-factor authentication (MFA). Or requiring a managed device for access.

FortiGate supports the SAML protocol, which can be used to authenticate users to a remote server (similar to how we use LDAP or RADIUS). We can use such authenticated users in different places. Here we will focus on SSL VPN and use Microsoft Azure AD as Identity Provider (identity source - external authentication server). These can be On-Premises AD DS domain users that we sync to Azure AD Tenant (or pure cloud accounts). Authentication against Azure AD allows us to leverage cloud security. For example, Multi-Factor Authentication (MFA) and Conditional Access in general.

In a previous article, we discussed the ability to authenticate users against Azure AD when logging into an SSL VPN. SAML was used and Multi-Factor Authentication (MFA) could be requested. However, client certificate authentication could not be used at the same time. There is another option where you can use MFA in Azure AD, even together with a certificate. However, it has a number of other limitations. Microsoft Network Policy Server (NPS), RADIUS, and the NPS Extension for Azure MFA (NPS Extension for Azure MFA) are used.

On FortiGate, we can use the Fortinet Single Sign-On (FSSO) technique, which Fortinet refers to as an authentication protocol for transparent user authentication. With it, it associates the IP address with the name of the user who logged in from it. In communication where the source IP address is used, we can use users and groups instead of IP addresses. FSSO has a number of different options and uses. However, here we will focus on linking to an Active Directory domain and using it only to identify users in folds.

FortiClient Endpoint Management Server (FortiClient EMS) is used to centrally manage endpoints. It uses a FortiClient agent on the hosts to configure and retrieve information. According to the license, we have remote access features, now called Zero Trust Network Access (ZTNA). Or also Advanced Threat Protection (ATP), where there is Antivirus, Firewall and more. Here we will take a brief look at EMS management and the use of a basic license (we will not cover the true ZTNA principle and use).

This article is about a situation where we have a Fortinet FortiGate and we use SSL VPN on it. We want to make the VPN connection more secure. So we decide to require multi-factor authentication when users log in. We also want to allow connections to the VPN only from company-managed devices. These are the computers that are included in the AD domain. We use Microsoft 365 cloud services, where we replicate accounts. So the solution is to connect FortiGate to Azure AD / Entra ID using SAML 2.0. And using Azure AD / Entra ID MFA along with Conditional Access Policy.

We will describe the behavior and possible configurations of a somewhat specific situation. If a device on the LAN (behind the FortiGate) accesses another device on the same or adjacent network (connected to the FortiGate) through an external IP address (network). Destination (Destination) and possibly source (Source) address translation (NAT - Network Address Translation) is used. This situation is referred to as NAT Hairpinning, Hairpin NAT, NAT loopback or NAT reflection. What matters is when and how FortiOS uses Source NAT.

We have a situation where for some application, here we will show for SSL VPN on Fortinet FortiGate, we are using Microsoft Entra ID user authentication using SAML 2.0. When we set up SAML Single sign-on in the Enterprise Application, a self-signed certificate with a validity of 3 years was generated. This is used for communication between the application and Entra ID. We will describe the procedure for renewing (replacing) a certificate when it expires.