Top 10 FortiGate mistakes we see in our daily support life

According to this title you are expecting some click-bait content, right? Nope. We’re still the Boll Engineering Tech team here… The configuration inputs below are problems we face frequently in our daily support life. Also some of the points mentioned below are frequently asked questions that pop up during our Fortinet Trainings.

Please write a comment if you were already aware of all ten possible configuration mistakes mentioned below.

Mistake 1: Backup the configuration from a non-“super_admin” account

In the following CLI output you can see, that the user “backup” does not have the “super_admin” profile assigned. Instead this user has been created with a “backup-admin-profile”. This profile has read only right on all selectable sections. Unfortunately, only administrator accounts that are assigned with the “super_admin” profile are allowed to access, change and backup the whole configuration of a FortiGate.

So even when all selectable sections are enabled, not the whole configuration is exported. The whole global configuration can only be exported by an administrator with super_admin rights.

config system accprofile
   edit "backup-admin-profile"
      set secfabgrp read
      set ftviewgrp read
      set authgrp read
      set sysgrp read
      set netgrp read
      set loggrp read
      set fwgrp read
      set vpngrp read
      set utmgrp read
      set wifi read
   next
end
config system admin
   edit "backupadmin"
      set accprofile "backup-admin-profile"
   next
end

Beneath using a limited adminstrator account to backup the configuration, it is also crucial to use a “super_admin” equipped admin account for troubleshooting. Some troubleshooting tools like downloading “debug logs” are only available for super_admin privileged administrator accounts.

Mistake 2: Add a DNS suffix when using public DNS servers

config system dns
   set primary 208.91.112.53
   set secondary 208.91.112.52
   set domain "mydomain.com"
end

A DNS suffix is (depending from the system) being appended to every DNS query that’s made. In theory, the DNS suffix should only be appended if not a FQDN is queried. As example, the DNS Query for “host-a” is being changed to “host-a.mydomain.local”. In some cases (as example .local domains) DNS lookups are not possible anymore over public DNS servers. Some products append the DNS suffix for all requests (also for FQDN). That makes “www.boll.ch.mydomain.com” out of “www.boll.ch”. In this case, the query is being directed to the NS for the domain “mydomain.com” to query “boll.ch” what is not the fastest way and therefore adds unnecessary latency (if the DNS server even sends an answer to this query).

Mistake 2, part 2: Mixing internal and external DNS servers

Also, it is unfortunately pretty common to mix internal and external DNS servers or DNS servers of different providers. Since it is not a problem to use DNS servers from different providers, we have only one recommendation here: Use DNS servers that respond with the same answer. If you follow this rule, you are never in the situation that a service is handled differently depending which DNS server is being queried.

Mistake 2, part 3: Also, we recommend to use DNS servers that are located near you.

Some provider use DNS based global load balancing to distribute traffic to the next datacenter. This means, that the DNS server in New York sends answers to servers based near New York, the one in Zurich sends answers to servers based in Zurich and so on. If you now use a DNS server based in New York for your offices in Zurich, the NY based DNS server may answer with NY based servers what adds unnecessary latecy to your connections.

Mistake 3: Change the session TTL system-wide

Only in very rare cases it is necessary to change the TCP session TTL value. In even rarer cases it is necessary to change this setting per VDOM or system wide.

config system session-ttl
   set default 6789
end

In most cases it is sufficient to change this setting only for the few sessions where a bigger ttl value is really needed. On FortiOS it is possible to set this feature on four different elements: Globally, per service object, per firewall policy and per port number. Also, the UDP Idle timeout can be set on all four of those elements as documented in this blog post:

Mistake 4: Let the WAN-facing DHCP-client interface override the manually configured DNS Servers

This causes your manually configured DNS servers to be ignored from the FortiOS and it overrides them with the DNS servers provided from the provider received over DHCP. In most cases, when someone manually overrides the DNS servers, they want the manual configured DNS servers to be queried. The DHCP option overrides this concious decision.

Mistake 5: Operate an Active-Active FortiGate HA Cluster with only two devices in the Cluster

There are two reasons why this may not be the best solution:

• In an active-active cluster, some of the traffic to be inspected is being sent to the secondary unit. This adds latency to the roundtrip time of the session and bandwith on the interfaces.
• There is a chance, that you overload your cluster. If FGT A is working with 60% system-load and FGT B is working with 60% system-load, the remaining appliance will not be able to handle the now 120% load of the cluster by itself in the case of the loss of a unit. The remaining device will then enter conserve mode and the availability of the cluster is not ensured anymore.

It is worth to clarify if your cluster can be built on two devices or if more appliances (maximum of four) are needed. If there is a need for more than two hardware appliances, in most cases it is more cost effective to build an active-passive cluster on the next bigger hardware model.

Mistake 6: The options session-pickup and session-pickup-connectionless are disabled

This setting is only relevant if you are operating a FortiGate HA cluster in your environment.

In case of a failover, all sessions going to the cluster need to be re-established. This means, that an interruption will be noticed on a failover. Also, when the sessions have to be re-established after a failover event, the load is increasing on the new primary appliance of the cluster sind all session decisions (routing, nating, policy lookup, rpf, …) have to be done again. This may cause a short spike in the system load after a failover.

The “connectionless” setting enabled the session sync for stateless protocols like ICMP and UDP.

By enabling those two settings, you can prevent this:

config system ha
    set session-pickup enable
    set session-pickup-connectionless enable
end

Mistake 7: Logging too much

Logging is a performance intensive task on the FortiGate.

Writing Logs is a reasonable decision on a Firewall. Also, for security reasons, it may be a good decision to write the logs to a second server. Out of a performance view, this secure decision is a bad decision that leads to a higher system load.

We see a lot of FortiGate, on which blocked local traffic and outgoing traffic is being logged. Since blocked traffic in general can not cause any harm (beside of DoS attacks), it is not important to log those requests. In regards of a DoS attack it is even better to not log the requests since a higher load causes an even earlier DoS – denial of service.

config log setting
   set local-in-allow enable
   set local-in-deny-unicast disable
   set local-in-deny-broadcast disable
   set local-out disable
end

Mistake 8: Configure Traffic Shaping only on the FortiGate (for TCP Traffic)

Traffic Shaping is a very complex matter. In most cases it is not done by just creating “Traffic Shaping Policies” on the FortiGate. No, it may be even worse: Configuring traffic shaping policies on the FortiGate unit without properly implementing them can expose the FortiGate unit to a self-generated DoS attack. Yes, you read that correctly.

You can find more information about this topic in those two blog posts:

Mistake 9: Locally configured LDAP authenticated users with FortiToken assigned …

… are a very common configuration mistake we see on the FortiGate.

The administrator includes the user in a LDAP group and also locally on the FortiGate as user object with an LDAP password. This is a usual configuration since it is only possible to use FortiToken in this configuration. Unfortunately, the user is still member of the LDAP group and therefore able to log in without a FortiToken. Fortinet has described this behaviour in this KB article: Technical Tip: Correctly configuring Two-Factor Authentication for LDAP users using SSL VPN

It is also necessary to ensure, that usernames are written in correct upper/lower case writing. Fortinet has a KB article published covering this topic in detail: Local user, username case sensitivity and accent sensitivity

Mistake 10: Deny Policies are in order before VIP Policies

… and match-vip is not set to enable. In this case, the deny policy will just not be applied. The FortiGate respects all Firewall Policies with a DNAT set as destination or with the CLI command “match-vip enabled” before the rest of the Firewall Policies. This is caused by the platform design of the FortiOS which handles DNAT as first action in the kernel.

To solve this issue, you can either set the VIP-SERVER as destination object in the BLOCK policy or enable the “match-vip” option on the policy “WAN to LAN” over CLI:

In this screenshot, you can see the BLOCKLIST element, which contains some ip addresses to block them from accessing the VIP-SERVER. This example will ALLOW traffic from a host present in the BLOCKLIST to VIP-SERVER!

In this screenshot, you can see the BLOCKLIST element, which contains some ip addresses to block them from accessing the VIP-SERVER and the VIP-SERVER element has been added as destination to the BLOCK policy. This example will block traffic from a host present in the BLOCKLIST to VIP-SERVER!

config firewall policy
    edit 1
        set name "BLOCK"
        set srcintf "WAN"
        set dstintf "LAN"
        set srcaddr "BLOCKLIST"
        set dstaddr "all"
        set schedule "always"
        set service "ALL"
        set match-vip enable
    next
end
config firewall policy
    edit 2
        set name "WAN to LAN"
        set srcintf "WAN"
        set dstintf "LAN"
        set action accept
        set srcaddr "all"
        set dstaddr "VIP-SERVER"
        set schedule "always"
        set service "HTTPS"
    next
end

You know more tricky configuration mistakes worth to mention? Let us know by writing a short comment. We look forward to hear from you what smaller or bigger mistakes you were facing on your FortiGate setup.