FortiGate Firewall policies, NAT, Load Balancing, Debug

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

Note: In the Fortinet documentation, the term Firewall Policy and Security Policy are (in my opinion randomly) used, and they (probably) mean the same thing. In the GUI, Security Policy is used when switching to NGFW mode.

Firewall Policy - policies

Documentation Policies (6.0.0), Policies (6.2.3), Firewall policies (6.0.0), CLI Reference - Configure IPv4 policies

• (VDOM) > Policy & Objects

The main feature of the Firewall is traffic management. By default, all communications are denied (Implicit Deny) and we create policies that allow communication from a specific source to a specific destination and a defined service. Alternatively, certain security checks are performed on the traffic. We manage the traffic by defining Firewall Policy (or Security Policy), which determine the action Accept or Deny. Every traffic that passes through FortiGate must be assigned to a policy.

The policy determines the direction from which the traffic (traffic flow/session) is initiated. If it is necessary to establish a session from both sides, two opposite policies need to be created. FortiOS does not perform Reverse Path Check for responses, the request may leave from one interface and the response may return from another. Reverse Path Lookup is performed, where it is checked whether the source IP is accessible through the incoming interface for the incoming packet.

Policies are applied (selected) using the First Fit method. The defined policies are traversed from top to bottom (in the specified order, which we can change) and if the entire policy matches, it is used and no further search continues. Only one policy can be applied to each packet. Therefore, how the policies are ordered is important. If we create a more specific policy, we must place it above the more general one, so that it is applied. On FortiGate, we can move policies by dragging and dropping them up and down.

Firewall Policy are of various types. The main ones are IPv4 Policy and IPv6 Policy, more specific Local InPolicy, Multicast Policy, Proxy Policy. For translating IPv6 and IPv4, we have NAT64 Policy and NAT46 Policy. And finally, specific IPv4 DoS Policy and IPv6 DoS Policy. Alternatively, there is a simple blocking of certain communications using IPv4 Access Control List.

We will further focus on policies of type IPv4 Policy.

Viewing policies

• (VDOM) > Policy & Objects > IPv4 Policy

On the page we see the list of policies. If we have the Implicit Firewall Policies display turned on, it is terminated by the Implicit Deny policy. On which we can enable logging of blocked traffic.

We can switch the display (top right) between two types.

• Interface Pair View - policies are sorted in the order they are traversed, and grouped by pairs of incoming and outgoing interfaces
• By Sequence - policies are sorted in the order they are traversed, we can create named groups and place policies in them (Insert Sequence Grouping) for organization and overview

In the table header, we can set filtering (another option is searching Policy Lookup) and select the displayed columns of the table, including their placement.

If we use multiple interfaces in a policy (Incoming or Outgoing Interface more than one item or the any option, which must first be enabled in Feature Visibility - Multiple Interface Policies), the Interface Pair View will no longer work and it will automatically switch to By Sequence. FortiGate justifies this by saying that it would not be clear when the given policy should be used (in what exact order it is located), so it must be placed in the entire list.

But what seems like a mistake to me. If we have addresses assigned to an interface, and create a policy with multiple interfaces (Incoming or Outgoing), we still cannot assign an address (Source or Destination) with a specified interface, but only one that has any. Yet every address that has one of the specified interfaces assigned should be able to be included there.

Basic policy parameters

According to the main parameters (Incoming Interface, Outgoing Interface, Source - IP address, Destination - IP address, Schedule, Service - port number), the matching policy is searched for. The first policy in the list where all parameters match is used.

Based on the interface from which the packet came, the incoming interface is determined. The source and destination IP address and destination port are taken from the packet header. The destination address is looked up in the routing table, which determines the destination interface.

Main policy items

• ID - policy identifier, used in CLI
• Name - unique policy name within the VDOM, unfortunately there is a limit of 35 characters (which is really too few, so we can use Comments)
• Incoming interface - incoming communication interface (we can use zones), if Multiple Interface Policies is enabled, we can choose multiple interfaces or any (any)
• Outgoing interface - outgoing communication interface
• Source - source address, user identity or internet service, multiple values or all sources (all) can be specified
• Destination - destination address or internet service, multiple values or all destinations (all) can be specified
• Schedule - we can select a schedule when the policy is valid, the default is always (always)
• Service - services and protocols, it's a TCP/UDP/SCTP port, IP protocol or ICMP type/code, we can allow everything (ALL), for more detailed protocol control (higher layer) Application Control needs to be used
• Action - the main policy action is ACCEPT to allow traffic to the next analysis stage, DENY to drop the traffic
• Log Allowed Traffic - whether the traffic that matches this policy is logged and whether it's only security events or all (All Sessions)
• Enable this policy - the policy must be enabled to be used

Special Deny Policy and Virtual IP behavior

If Virtual IP (Destination NAT - DNAT) is used in policies, they are applied differently. If we have a preceding general policy with DENY action, and a policy with Virtual IP is behind it, the traffic will not be dropped, but the subsequent policy will be applied. The policy is not applied to DNAT packets (Do not match DNATed packet).

We either need to create a policy where the destination is the given Virtual IP and the action is DENY. Or add a CLI command to the general DENY policy. Description Technical Note : DENY Policy for Virtual IP Firewall Policy.

config firewall policy
    edit 1
        set match-vip enable
    next
end

Internet Service - Internet services

• (VDOM) > Policy & Objects > Internet Service Database

Internet services are defined in the database (Internet Service Database - ISDB, also contains the IP Reputation Database), provided by FortiGuard and continuously updated. It contains information about many services, what public IP addresses, ports and protocols they use, as well as IP address reputation ratings, geographic location, ownership and more. Examples of services Microsoft-Office365, Amazon-AWS, Google-Gmail, Facebook-Web. But also a list of Botnet-C&C.Server, which contains a list of known Botnet command and control servers.

We primarily use Internet services as the Destination, but some can also be used as the Source. When we use an Internet service as the destination, we no longer specify the Service. Using CLI, we can define our own services config firewall internet-service-custom or modify existing ones config firewall internet-service-extension.

Public IP addresses are categorized into 5 reputation levels, where 1 are known malicious addresses and 5 are known verified services. Using CLI, we can specify the minimum reputation in the Firewall Policy, but then we cannot define a number of other parameters in the policy.

Traffic Logging

On each policy, it is set whether the traffic that matches the given policy should be logged. Most policies use the ACCEPT action to allow traffic, then we can enable logging by checking Log Allowed Traffic and choosing one of two options:

• Security Events - only logs messages that correspond to security events caused by traffic allowed by this policy
• All Sessions - logs all messages that correspond to traffic allowed by the policy

If we want to log blocked traffic, we either need to create a policy with the DENY action for certain traffic, or set logging on the default Deny policy and check the Log Violation Traffic option.

Inspection Mode

Documentation Inspection mode per policy (6.2.3), Inspection modes (6.2.3), Inspection modes (6.0.0), Inspection mode (6.0.0)

Since FortiOS 6.2.0, the inspection mode is set per policy, not globally. The default is Flow-based. The inspection mode primarily concerns the Security Profiles.

Note: When using Security Profiles and a certain inspection mode, I have encountered issues (I would call them bugs). Searching online, I found that many people are struggling with this. The advice is to try the other mode or disable (limit) security features, which doesn't seem like a good solution to me. For example, Proxy-based with SSL Deep inspection doesn't establish any HTTPS connections from Java 11 (it tries TLS 1.3 and doesn't get a response), while everything passes from the browsers. This is resolved by switching to Flow-based, but then some other connections time out occasionally.

Flow-based inspection

• compares patterns with a packet snapshot to identify security threats
• provides greater performance, utilizes hardware acceleration
• packet content is inspected packet by packet as it passes through the policy (not buffered), the last packet is held and waits for the test result, if a violation occurs, a reset is sent
• supports fewer features than Proxy, but ensures faster response
• does not support Security Profile Web Application Firewall, CIFS Inspection, ICAP, has limited features for Antivirus, Data Leak Prevention, Email Filter, Web Filter
• for SSL Deep Inspection we need to enable inspection of all ports

Proxy-based inspection

• reconstructs the content that passes through the policy and checks it for security threats
• supports more configuration options, but is slower
• traffic passing through the policy is buffered for inspection (e.g., when downloading a file, receiving an email message, all the file/message packets are stored, then checked as a whole), if a violation occurs, it is discarded and replaced with a replacement message, otherwise it is released to the destination
• we need to handle large files
• if we want to use a Virtual Server in the policy, this mode is required

NAT - Network Address Translation

Documentation Policy with source NAT (6.2.3), NAT (6.0.0)

For communication between networks, a device (typically) Router or Firewall is used. The routing method can be used, which does not change the IP addresses of the packets (it changes the L2 header - MAC addresses). Within the internet, only public IP addresses can be routed. If we use non-public network ranges in the internal network, we can route them within the local network, but not to and from the internet. In this case, we need to use the address translation (NAT) method. It replaces the source or destination IP address with another and maintains a connection table to properly route the responses.

Network Address Translation can be divided into basic types:

• Source NAT (SNAT) - changes the source IP address, typically when communicating from LAN to the internet, a range of different non-public addresses is changed to one from the public range
• Destination NAT (DNAT) - changes the destination IP address, typically we use a public address and forward the communication to an internal non-public address of a server

Source NAT

Source NAT can operate in various modes. FortiGate supports

• Static SNAT - all source (internal/private) addresses are mapped to one (public/external) address, it is called Port Address Translation (PAT), because the source port is also changed (at the beginning of communication, a certain port is assigned to a certain internal IP address and source port, on the response the FW knows where to send the packet), 60416 ports are available (5117-65533), so it can be used for a maximum of 60416 internal address conversations, FortiGate typically uses the IP address of the outgoing interface
• Dynamic SNAT - source addresses are mapped to an address pool in a defined way, the IP Pool can contain one address or a range of addresses, we can thus define a different outgoing address than the interface address, FortiGate allows to create four types of IPv4 IP Pool
  • Overload - similar to Static NAT, if we assign more addresses, after exhausting the ports of the first IP address, the next one will be used
  • One-to-one - addresses are mapped one-to-one, no PAT is performed, but the source ports remain the same, we can service as many internal addresses as we have external ones
  • Fixed port range - we specify internal and external address ranges, PAT is performed, the ratio of addresses determines which external addresses and port ranges will be assigned to the internal address (for 1 external and 10 internal, the same external address and 6040 port range will be used for each internal address)
  • Port block allocation - uses PAT, we define port blocks that are assigned to internal addresses

FortiGate allows to set Preserve Source Port for Source NAT. This is for applications that require incoming communication from a specific port. In this case, however, only one simultaneous connection is possible through this policy.

SNAT Configuration and Central SNAT

Source NAT is configured on individual policies in the Firewall / Network Options section. When we enable NAT, the source address is translated. Otherwise, routing is performed.

• (VDOM) > Policy & Objects > IPv4 Policy

Central SNAT allows you to define detailed SNAT rules centrally, not on individual policies (where we only enable NAT). It is implicitly enabled for Policy-based NGFW mode. For Profile-based NGFW mode, it is disabled by default, but we can enable it in System > Settings or (if using VDOM) Global > System > VDOM. The configuration of Central SNAT rules is then performed in

• (VDOM) > Policy & Objects > Central SNAT

Note: According to some mentions, it seems that Central SNAT is not used very often and has certain limitations.

Destination NAT - Virtual IP and Virtual Server

Documentation Policy with destination NAT (6.2.3), Virtual IPs (6.0.0), CLI Reference - Configure virtual IP for IPv4

In Destination NAT, the destination IP address is translated, and we choose how to handle the destination ports. Either Port Forwarding is performed, where the destination port is preserved and mapped to the destination address. Or Port Translation, where the destination port is translated to a different one. Port Forwarding can map all ports or only a specific port or range of ports.

Note: The following behavior is important when using both Source NAT and Destination NAT (the documentation doesn't mention this much). A typical situation is when we have multiple public IP addresses. We NAT the outgoing communication using the interface IP address. For another public IP address, we create a Virtual IP, translate it to the internal server address, and map all destination ports. Then the outgoing communication from this server will leave from the public IP address used in the VIP. This makes sense, but we need to keep in mind that not all communication may be leaving from a single IP address. If we need all communication to leave from one IP address, we can use a dynamic IP Pool with a specified address.

FortiGate uses the term Virtual IP address (VIP) for Destination NAT, and often talks about VIP instead of DNAT. This is quite misleading, as this term is commonly used for Load Balancing. A special case of a Virtual IP is a Virtual Server.

Virtual IP

The created Virtual IP is then used in the policy as the destination (Destination). The configuration is done in

• (VDOM) > Policy & Objects > Virtual IPs

Using the GUI, we always create a Static DNAT, where we define a static one-to-one address translation. Using the CLI, certain special types can be created.

For a Virtual IP we need to set at least

• External IP address - the address that the communication will come to
• Mapped IP address - what it will be translated to

Using a hyphen, we can specify a continuous range of external addresses, then we enter the first mapped address and the range will be used automatically. We can also specify the Interface where the external addresses are located.

If we don't enable the Port Forwarding option, all destination ports are mapped to the destination IP address (for communication to work, there must be a corresponding policy). If we check this option, we enter

• Protocol - the communication protocol
• External service port - the destination port, with a hyphen for a range of ports
• Map to port - we can enter the same port or a different one, and the translation will occur

Note: In the policy where we use a Virtual IP, we must allow the service that contains the destination port used in the VIP (for the communication to work). If we translate the external port to a different internal one (Map to port), we allow the translated port.

In the Optional Filters section, we can set restrictions on the source addresses (Source address). And as a new feature, we can select Services, which will replace the External service port input.

Note: I tested the following behavior. As soon as we create a Virtual IP, and haven't even used it anywhere yet, FortiGate already responds to ARP requests for the External IP address.

Virtual Server - Server Load Balancing

Documentation Virtual server, Server load balancing, CLI Reference - Configure virtual IP for IPv4, CLI Reference - Configure server load balancing health monitors

A special type of Virtual IP is a Virtual Server. In the GUI, the configuration is separate, but in the CLI it is configured with the same command config firewall vip and we choose a different type set type server-load-balance. Destination NAT is also performed, but it allows translating the external address to multiple internal addresses (servers) and distributing the communication in different ways (Load Balancing).

For selected encrypted protocols, SSL Offloading is performed. The connection is terminated on FortiGate and decrypted (we must upload the server certificate with the private key), so security checks can be performed. The connection to the destination server may no longer need to be encrypted, so the server's load is also reduced.

The created Virtual Server, just like the Virtual IP, is then used in the policy as the destination (Destination). The policy must be in Proxy-based inspection mode for us to be able to use the Virtual Server in it.

I also came across a note that a Virtual Server cannot be used if we have Central SNAT enabled.

Virtual Server can be used as a simpler Reverse Proxy for securing a web server. The traffic is terminated on FortiGate and inspected before being sent to the server. Unfortunately, features like Server Name Indication (SNI) are not supported, so routing traffic from one IP address to different target servers based on hostname (this routing is possible based on the HTTP header) is not possible.

• (VDOM) > Policy & Objects > Virtual Servers
• (VDOM) > Policy & Objects > Health Check

Note: To make the Virtual Servers option available in the GUI, the Feature Visibility - Load Balance must be enabled.

Virtual Server allows distributing traffic to backend servers using a variety of methods (Load Balancing Method), such as Static (failover), Round Robin, Weighted, Least Session, Least RTT, First Alive, HTTP Host. All methods only send traffic to available and enabled servers. For FortiGate to recognize that a server is available, a Health Check Monitor must be defined.

It supports various protocols (Type), either general IP (L3), TCP or UDP (L4), or specific protocols HTTP, HTTPS, IMAPS, POP3S, SMTPS or SSL (L7), for which it allows the use of some advanced features, such as Persistence and HTTP Multiplexing.

Virtual Server - Virtual Server configuration items

• Virtual Server IP - corresponds to the External IP Address, the address that receives the communication
• Virtual Server Port - corresponds to the External service port, the port that the communication comes in on
• Real Servers - corresponds to the Mapped IP Address & Map to port, the addresses and ports that the communication is translated to, we can define up to 8 internal servers to distribute the load to, for each server we enter
  • IP Address - the target (translated) IP address
  • Port - the target port (we can use Port Translation)
  • Weight - if we set the Load Balancing Method to Weighted, we can specify the server's weight
  • Max Connections - we can limit the number of connections to the server (if the limit is reached, the communication is sent to the other servers), 0 means unlimited
  • HTTP Host - if we set the Load Balancing Method to HTTP Host, we can enter the domain name (Host)
  • Mode - Active accepts traffic, Standby or Disable do not accept

• Persistence - ensures that communication within the same session is always routed to the same server, we can identify it using SSL Session ID or HTTP Cookie
• Health Check - we assign a pre-defined server health (availability) check method, if the check fails for a server, traffic will not be sent to it, we define how often the check is performed (Interval), the maximum response time (Timeout) and the number of attempts (Retry) before the server is marked as dead, we can use a simple ICMP ping, availability of a TCP port or HTTP/HTTPS
• HTTP Multiplexing - allows using one TCP connection for multiple requests, reducing the load on the web server (FortiGate allows sending separate incoming sessions through the same internal session to the server)
• Preserve Client IP - inserts the item X-Forwarded-For in the HTTP header with the original client IP address (using the CLI, we can specify a different header item)
• SSL Offloading - we choose the used certificate and the mode, which determines whether the encrypted communication to the target server is
  • Client <-> FortiGate - called Half Mode, the connection from FortiGate to the server is unencrypted
  • Full - Client <-> FortiGate <-> Server, all communication is encrypted (using the CLI, it allows using a different protocol version or cipher for client communication and communication to the internal server)

Many detailed settings can only be done using the CLI, some are mentioned in Additional SSL load balancing and SSL offloading options and in CLI Reference - Configure virtual IP for IPv4.

Virtual Server - Load balancing by domain name

A special Load Balancing Method is HTTP Host. HTTP host-based load balancing. It uses the mandatory HTTP header item Host, where the domain name from the server's URL (Host) and optionally the port number are specified. We assign a name to the Real Server and then the requests coming to one public IP address can be routed to different internal servers based on this name (actually the web server address). Example of a header item

Host: www.company.com

Note: When this option is available, it's a shame that Server Name Indication (SNI) is not supported. Because in the case of HTTPS, the communication must first be decrypted in order for us to look into the HTTP header. When using SNI, the client inserts the domain name (hostname) into the TLS negotiation (the ClientHello message), so it is unencrypted.

Virtual Server - Redirect HTTP to HTTPS

Already in FortiOS 5.6, I was unsuccessfully looking for a way to redirect traffic from HTTP to HTTPS (this does not mean forwarding port 80 to port 443). I came across the CLI command set ssl-http-location-conversion enable, but it is used for a situation where we use SSL Offloading Half Mode. The client connects to FortiGate using HTTPS, but FortiGate uses HTTP to connect to the server. If the server redirects to another of its pages, it may include the HTTP protocol in the Location header. This command rewrites it to HTTPS.

But in FortiOS 6.2.1, a new CLI command has been added that performs the redirection. HTTP to HTTPS redirect for load balancing

config firewall vip
    edit "virtual-server-http"
        set http-redirect enable
    next
end

The command is available only for a Virtual Server of type HTTP, with parameters:

        set type server-load-balance
        set server-type http

We need to create two Virtual Servers, one for HTTP and one for HTTPS with the same public and internal address. In the configuration of the HTTP server, we enable the redirection. Then we need to create a Firewall Policy that allows HTTP and HTTPS and has both virtual servers as the Destination.

If the client sends a Request to HTTP, FortiGate will respond with a status code 303 (maybe 301 would be better) and insert the HTTPS URL in the Location header. The client will then establish a new TCP connection.

Monitoring Virtual Server

• (VDOM) > Monitor > Load Balance Monitor

Here we see a list of Virtual Servers and the associated Real Servers. For them, the status, number of events (up/down), active sessions, Round Trip Time (RTT) - we must have ping monitoring set up, and traffic volume are displayed. Using the right-click menu, we can switch the server mode and stop/start routing traffic to it.

Virtual IP and SSL Inspection

Documentation Protecting an SSL server

If we want to publish a web server and perform checks on encrypted traffic (HTTPS), we can use a Virtual Server. We enter one target server and choose the certificate to be offered to the clients. At this point, the communication is decrypted, and the selected security checks (Security Profiles, we'll talk more about them next time) can be performed.

(VDOM) > Security Profiles > SSL/SSH Inspection

But there is also the option to create a simpler Virtual IP and configure an SSL inspection profile (SSL/SSH Inspection). In the profile, we choose the SSL inspection type Protecting SSL Server (Fortinet refers to this as Inbound SSL Deep Inspection) and the certificate for the server. This solution may have some advantages. The Virtual IP can also be used in the Flow-based inspection mode. The Virtual IP can also forward all ports to the target server.

I performed some tests, and it seems the behavior is the same for the Virtual Server and the Virtual IP with SSL Inspection (of course, there is no Load Balancing to multiple servers here). In some older Fortinet article, they also mention using a Virtual Server with SSL Inspection, but I don't know if it has any significance. In any case, the certificate set in the Virtual Server (not in the SSL Inspection) is offered to the client.

Objects

When defining a policy, we don't enter values directly for individual parameters (such as the source IP address), but we select pre-defined objects. We can usually create a new object even while creating the policy. We've already talked about some objects, such as network interfaces (Interfaces, including zones (Zone), users and groups (User & User Groups), internet services (Internet Service) and virtual IPs and servers (Virtual IP & Server).

Firewall Services

Documentation Services

• (VDOM) > Policy & Objects > Services

A Service (here we're talking about FW services, another option is Proxy services) is, from Fortinet's perspective, a specification of the communication protocol (L3/L4) and the port. The protocol can be from the Layer 3 OSI IP or ICMP and from the Layer 4 OSI TCP, UDP, SCTP. For TCP/UDP/SCTP, we enter the destination port (one, multiple, or a range). We can also enter the destination address and source port. For ICMP, we enter the ICMP Type number and the ICMP Code. For IP, the Protocol Number.

If we want to inspect application protocols at Layer 7 OSI, we need to use the Security Profile Application Control.

We can categorize services into Service Category for more organized management. We can also group them into Service Group.

Many well-known services are already configured on FortiGate, and we can add more. Transport protocols TCP, UDP, SCTP, DCCP use ports that are identified by a port number (indicating the application or service). The available port numbers are divided into categories:

• 0 - 1023 - system or well-known ports
• 1024 - 49151 - user or registered ports (assigned by IANA - Internet Assigned Numbers Authority)
• 49152 - 65535 - dynamic or private/ephemeral ports

Addresses

Documentation Addresses, Objects

• (VDOM) > Policy & Objects > Addresses

Firewall addresses define the source and destination of network traffic. They are used in policies and serve to simplify and clarify the configuration. On FortiGate, there are several categories of addresses and within them, various types. The categories are

• IPv4/IPv6 Addresses
• Multicast Addresses
• Proxy Addresses
• IP Pools (IPv4/IPv6)
• Virtual IP Addresses

Here we'll look at IPv4 Addresses, which contain the following types:

• Subnet - IP address and subnet mask
• IP Range - range of IP addresses using a hyphen
• FQDN - Fully Qualified Domain Name (FQDN) address
• Geography - geographic address using a country/region
• Dynamic - allows using Fabric Connector Address, FSSO, ClearPass
• Device (MAC Address) - one MAC address or a range
• Address Group - a grouping of various addresses

Note: I'm missing an address type where we could specify multiple individual IP addresses. We have to create a separate object for each address and group them into an Address Group. But the individual objects must have unique names, and the whole process is cumbersome. BTW, there isn't even a separate object for a single IP address.

When defining an address, we determine the interface (Interface) behind which the address may appear. If it can be seen behind multiple interfaces or we don't want to restrict it, we can choose any. The recommendation is to specify the given interface, as it will help in configuring the policy, where only addresses for the selected interface will be offered. It will also prevent the mistake of using an address that cannot communicate here.

Fortinet recommends using FQDN addresses. Of course, the advantage is that when the IP address changes, we don't have to update the Firewall, just fix the DNS record. I'm probably old-fashioned, but for identifying internal servers, this doesn't seem like a reliable, secure, and efficient solution to me.

The most used address type is Subnet (IP/mask), which we use to define a network / subnet or also a single computer (one IP address, mask /32). We can thus specify all addresses 0.0.0.0/0 or no address 0.0.0.0/32 (such objects are already pre-defined). We can enter the mask in CIDR format or dotted decimal.

For some addresses (Subnet, IP Range, FQDN), we can enable the Static route configuration option. Such addresses can then be used in defining a Static Route with a Destination type of Named Address.

In FortiOS 6.2.0, there was a change in the definition of devices/MAC addresses. A new address type MAC Address was added, where we can define one address or a range. We can use this object in the policy as the Source (if we have NAT mode).

Addresses are a pretty crucial object that is used a lot in the Firewall configuration. It seems a shame to me that FortiGate treats all addresses as one object. It only distinguishes them by an icon, which doesn't help much with orientation. We can set a color for each address, which seems like the minimum that should be done for an overview. But the usage is complicated (remembering the colors).

When selecting the source or destination in the policy, we are presented with a list of ADDRESS where there will be thousands of items. ADDRESS GROUP, VIRTUAL IP/SERVER, and Internet Service are listed separately on a separate tab. I was used to a system where the individual categories were displayed, and I only then selected the address. And there were more of these categories (for easy orientation) - network, network group, subnet, computer (given IP address), computer group, address range, URL group, domain name group.

Troubleshooting Connection / Traffic Issues

Documentation Troubleshooting Tip : First steps to troubleshoot connectivity problems to or through a FortiGate with sniffer, debug flow, session list, routing table

When troubleshooting issues where a certain communication is not working, we first look in the Traffic Log. Either on the FortiAnalyzer or directly on the FortiGate. We can use some FortiView views, logs from Security Profiles or Events, but we'll probably use the Forward Traffic log the most. It's clear that routing between networks and NAT, etc. must work for us first.

In more complex cases, the logs are not enough, and we need to connect to the FortiGate command line and use one of the following commands.

Packet Capture

• (VDOM) > Network > Packet Capture

The simplest option is packet capturing in the GUI. We can set various filters to limit the captured traffic, and then download the PCAP file to open it in Wireshark.

Note: If the policy is in Flow-based mode, we need to disable hardware acceleration on it, otherwise the traffic is not captured correctly.

config firewall policy
    edit 2
        set auto-asic-offload disable
    next
end

Packet Sniffer

Documentation Troubleshooting Tool: Using the FortiOS built-in packet sniffer

Packet Sniffer is used to display (capture) packets or Ethernet frames with varying levels of detail (content).

In the command, we specify the network interface, a filter or none, the detail level, optionally the number of packets (if not specified, we end the capture with Ctrl+C), a means displaying the timestamp.

diag sniffer packet <interface> <'filter'> <verbose> <count> a
diagnose sniffer packet Local none 4 0 a 
diagnose sniffer packet Local 'host 10.0.1.10' 4 10
diagnose sniffer packet any 'ip6 host 2a02:768:9808:29f6:dae4:c69:7cdf:e754' 4 10

FW1 (FWINT) # diagnose sniffer packet Local 'host 10.0.100.10 and host 172.217.23.206' 4 4
interfaces=[Local]
filters=[host 10.0.100.10 and host 172.217.23.206]
3.042984 Local -- 10.0.100.10 -> 172.217.23.206: icmp: echo request
3.044511 Local -- 172.217.23.206 -> 10.0.100.10: icmp: echo reply
3.211586 Local -- 10.0.100.10.57855 -> 172.217.23.206.80: syn 3024290172
3.211613 Local -- 172.217.23.206.80 -> 10.0.100.10.57855: syn 2197092680 ack 3024290173

Debug Flow

Documentation Technical Tip: How to use debug flow to filter traffic

To analyze the behavior of traffic and how it flows through the FortiGate, we can use the Debug Flow.

Disabling (turning off) any potential debugging and clearing the settings (these commands do not need to be used).

diagnose debug disable
diagnose debug flow trace stop
diagnose debug flow filter clear
diagnose debug reset

Setting the capture parameters, protocol TCP, source address (or generally addr, destination daddr), port (we can use sport and dport), displaying function names, displaying timestamp, starting debug and capturing 100 lines, enabling the debug command.

diagnose debug flow filter proto 6
diagnose debug flow filter saddr 10.0.100.10
diagnose debug flow filter port 443
diagnose debug flow show function-name enable
diagnose debug console timestamp enable
diagnose debug flow trace start 100

diagnose debug enable

2020-07-29 10:35:29 id=20085 trace_id=2712 func=print_pkt_detail line=5501 msg="vd-FWINT:0 received a packet(proto=6, 10.0.
100.10:56539->77.75.79.129:443) from Local. flag [F.], seq 3886555563, ack 2621990324, win 1025"
2020-07-29 10:35:29 id=20085 trace_id=2712 func=resolve_ip_tuple_fast line=5581 msg="Find an existing session, id-0f6c0e16,
 original direction"
2020-07-29 10:35:29 id=20085 trace_id=2712 func=npu_handle_session44 line=1139 msg="Trying to offloading session from Local
 to DMZ, skb.npu_flag=00000000 ses.state=00112204 ses.npu_state=0x00003c94"

IPv6
diagnose debug flow filter6 daddr 2001:4860:4860::8888
diagnose debug flow trace start6 100

Session

Documentation Troubleshooting Tip: FortiGate session table information

Displaying the session list with filtering.

diag sys session filter src 10.0.100.10
diag sys session filter dst 216.58.201.100
diag sys session list

session info: proto=6 proto_state=11 duration=8 expire=3591 timeout=3600 flags=00000000 sockflag=00000000 sockport=443
 av_idx=0 use=6
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty ndr npu nlb f00 app_valid
statistic(bytes/packets/allow_err): org=1597/10/1 reply=1075/6/1 tuples=3
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=48->50/50->48 gwy=192.168.50.1/10.0.0.1
hook=post dir=org act=snat 10.0.100.10:56914->216.58.201.100:443(192.168.50.254:56914)
hook=pre dir=reply act=dnat 216.58.201.100:443->192.168.50.254:56914(10.0.100.10:56914)
hook=post dir=reply act=noop 216.58.201.100:443->10.0.100.10:56914(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
src_mac=00:1e:49:8f:3c:00  dst_mac=00:09:0f:09:00:84
misc=0 policy_id=61 auth_info=0 chk_client_info=0 vd=2
serial=0f6df8e0 tos=ff/ff app_list=6003 app=41600 url_cat=0
rpdb_link_id = 00000000 ngfwid=n/a
dd_type=0 dd_mode=0
npu_state=0x003c94 ips_offload
npu info: flag=0x81/0x81, offload=8/8, ips_offload=1/1, epid=2/2, ipid=166/172, vlan=0x0000/0x0000
vlifid=166/172, vtag_in=0x0000/0x0000 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=3/3

IPv6
diagnose sys session6 list