Poland
GRANDMETRIC Sp. z o.o.
ul. Metalowa 5, 60-118 Poznań, Poland
NIP 7792433527
+48 61 271 04 43
info@grandmetric.com
UK
Grandmetric LTD
Office 584b
182-184 High Street North
London
E6 2JA
+44 20 3321 5276
info@grandmetric.com
US Region
Grandmetric LLC
Lewes DE 19958
16192 Coastal Hwy USA
EIN: 98-1615498
+1 302 691 94 10
info@grandmetric.com
BlogSecurity
LAN SecurityFortiGate Configuration: How to Avoid Common Mistakes? A Practical Engineer’s Perspective Below, I’ve summarized the most common issues we see during FortiGate audits for customers and in everyday operations.
In practice, configuration errors with this popular firewall rarely stem from a lack of knowledge of network protocols, but more often from a misunderstanding of the FortiOS philosophy and the differences between local configuration and the one centrally managed by FortiManager (FMG).
I hope the following summary encourages you to review your own devices.
Let’s get started.
GROUP 1 – General Errors in FortiGate Configuration
GROUP 3: Local Firewall Configuration Errors, Without FortiManager
GROUP 4: Errors in configuring FortiGate with FortiManager (FMG)
FortiGate processes policies top to bottom. If it finds the first matching policy, it executes it and completes the decision-making process.
If we place rules relevant to traffic filtering at the end of the policy processing list, FortiGate may never reach them. It will execute an earlier, “broader” rule and route traffic accordingly. Often, the default “Interface Pair View” policy view doesn’t show the actual order of rules, which can be confusing.
How to follow the policy processing order on FortiGate?
Src:any dst:any service:any rules often start life as “test” rules and end up as the main traffic conduit in production. As a result, the firewall acts as a better router, at the expense of its advanced traffic filtering capabilities.
How to manage any-any rules?
If you don’t divide interfaces into zones, you risk multiplying policies and mixing traffic with different security requirements. Each time you expand your infrastructure, you have to “click” through new combinations of interfaces, and mistakes are easy to make.
Best practices for dividing interfaces into zones:
Even an engineer with a good understanding of FortiGate, without a process and tools, will start “putting out fires” instead of building a stable environment. Changes without change management, a lack of a lab, ignored logs, and a hit-count policy mean that problems only come to light during major outages or audits.
Best change management practices:
P.S. If you don’t have FortiGate but want to avoid common configuration mistakes, you can check my article on things to avoid when configuring a firewall.
Fortinet is one of the most popular firewall vendors in the world and, as such, is regularly attacked.
If the firmware isn’t updated, no one monitors Fortinet’s security advisory, and there’s no procedure for responding to critical CVEs, the administrator reacts only after an incident, not during the preventative phase.
How to update FortiGate?
A lack of active vendor support means you don’t have access to critical bug fixes, security updates, and timely incident response. Your network becomes vulnerable to known vulnerabilities, and it’s harder to respond to new threats.
Failure to validate FortiGuard server access configurations can prevent the FortiGate from downloading signature and security policy updates. As a result, the device operates on outdated data, increasing the risk of missing new threats and attacks.
FortiGuard best practices:
Using weak encryption allows attackers to easily decrypt or eavesdrop on transmissions, even if other security mechanisms are working properly. As a result, sensitive and confidential data becomes vulnerable to theft or manipulation. It’s worth remembering that guidelines such as NIS2 and the GDPR require current, strong cipher suites.
Default DoS policies, especially in cloud firewalls, which are sometimes enabled out-of-the-box (as opposed to on-premises), can cause difficult-to-diagnose communication issues. Leaving default SD-WAN policies in place means the traffic isn’t optimally routed or controlled according to business needs and application priorities. This can result in inefficient bandwidth utilization, latency, and availability issues with critical services.
If you’re making configuration changes via the GUI, from multiple administrative accounts, without history and without backups, you might run into problems sooner than you think. Often, after a firmware update, something “breaks”, but no one is sure what the previous configuration looked like or what exactly changed.
What do I recommend regarding FortiGate backups?
Configuring a firewall using the copy-and-paste method ends up being a real mess. Transferring configuration fragments by eye is prone to making mistakes and is difficult to maintain configuration consistency.
What do we recommend if you already have multiple FortiGate devices?
The lack of object standardization most often backfires in two situations:
Object addressing best practices:
Improper RBAC permission allocation allows users to access functions or configurations they shouldn’t have access to. This increases the risk of erroneous changes, accidental security disablements, or unauthorized access to critical resources.
Ignoring the Security Rating causes known configuration vulnerabilities and weak settings to go undetected, even though FortiGate itself identifies them. As a result, the device operates below its actual security level, and risks are only known after an incident or audit.
The Security Rating itself reveals:
A practical tip for Security Rating:
Without Automation Stitches, FortiGate responds only passively, and many incidents require manual intervention by the administrator. Using them allows for automatic event detection and enforcement, shortening response times and limiting the impact of incidents. They also enable email notifications when critical events occur on the firewall.
With External Block Lists, FortiGate leverages external knowledge of current threats and responds only after detecting an attack locally. Threat Feeds allow you to proactively block known malicious IP addresses and domains, significantly reducing the attack surface.
An incorrectly configured remote access VPN often bypasses key control mechanisms (MFA, split-tunnel, access policies) or grants users excessive privileges. As a result, VPNs become one of the easiest entry vectors into internal networks. Controlling VPN traffic, for example, using static routes, can cause problems with user communication with websites.
Furthermore, the lack of 2FA and geolocation policies for VPNs leaves remote access vulnerable to account takeovers and brute-force attacks. As a result, unauthorized users can enter the network even with a properly configured VPN.
Exposing the FortiGate management interface directly to the internet exposes the device to brute-force attacks and takeover attempts. As a result, even correctly configured security policies can be bypassed by accessing the administration panel.
Protect the admin panel:
Keeping logs only on the FortiGate means that after an incident, you only have as much history as can fit in the device’s memory.
Best practices for collecting logs:
A lack of understanding of the separation of responsibilities between FortiManager and the local FortiGate leads to changes being made in parallel in two places, leaving no one sure which policy version is actually in effect.
Classic errors:
Best practice:
When you use a single ADOM for everything (production, test, and lab) and mix global and local objects, you lose a clear boundary between environments. In this configuration, it’s very easy to accidentally push test policies to production, create conflicts during change deployment, and end up in a situation where debugging a network issue becomes a tedious search for a needle in a haystack.
Installing 100+ changes at once, across all devices, is a recipe for difficult error identification and lack of quick rollback.
Smaller changes = more control
FortiGate itself is just a tool. A well-configured device can effectively defend against attempted attacks, but a poorly configured device won’t fully utilize its capabilities. The 22 errors cited above are the essence of the problems we see in real-world deployments: from simple “any-any” traps to an organizational lack of process and testing.
You can consider this article as a starting point for a self-review of your own devices or a pretext for a professional security audit.
The most common errors we see during configuration audits include:
– Lack of understanding of the policy processing order and “catching” traffic with overly general rules before they reach the appropriate UTM policies
– Permanent “any-any” rules that started life as “temporary”
– Lack of a consistent zone concept and haphazard interface assignment
– Click-and-go configuration without backups, documentation, or versioning, often on several firewalls independently
– Chaos in address objects/services (different names for the same networks) and orphaned objects that are not cleaned up
– Ignoring Security Rating, Threat Feeds, and Automation Stitches
– Lack of FortiOS updates and signatures, lack of connectivity to FortiGuard, and lack of vulnerability notifications
– Poorly designed remote access VPN (no 2FA, overly broad permissions, routing issues)
– Lack of hardening, poor RBAC, exposed management interface to the internet, no logs on an external collector – local changes on FortiGates managed by FortiManager, incorrect ADOMs, and “blast radius” of giant installs
Policy misconfiguration causes the firewall to:
– allow traffic that no one intended – for example, through broad any-any rules that “cover” more specific rules,
– not apply UTM/SSL inspection because traffic falls into a simple rule without security profiles,
– not block addresses with a poor reputation when deny rules are too low on the list and never hit,
– not be auditable – the lack of comments and expiration dates makes it difficult to understand why a given policy exists and whether it is still needed.
The effect is simple: from the outside, “we have a FortiGate,” but in reality, access control is flawed and unpredictable.
Common problems we see with NAT rules include:
– NAT enabled where it shouldn’t be (e.g., on LAN→LAN / VPN→LAN policies), which limits traffic visibility and causes asymmetry,
– incorrect or incomplete VIP (Virtual IP) configuration – the VIP is configured, but the firewall policy doesn’t match the direction/port, so the service is “appearing exposed but not working,”
– inconsistency between static routes, SD-WAN, and policies – “default” SD-WAN policies are left unanalyzed, causing traffic not to follow the optimal or expected path,
– careless routing of VPN traffic with static routes, which can cut off user access to parts of the internet due to incorrect route preferences.
From the user’s perspective, this manifests itself in “magically disappearing” traffic, random behavior of services from the internet, and VPN access issues.
1. Run and analyze the Security Rating – this is a built-in checklist that shows configuration weaknesses (old ciphers, overly broad rules, no logging, no updates).
2. Check FortiGuard status – whether IPS/AV/URL signatures are up-to-date and there are no connectivity issues.
3. Review policies for: any-any, order, comments, expiration dates, orphaned rules.
4. See if traffic and events are being logged to an external collector (FortiAnalyzer/SIEM/syslog).
5. Assess the VPN: MFA/2FA, address range, geopolitics, routing method.
6. Go through the device using a checklist or perform a full configuration audit with an external observer.
The most common are:
– IPS/AV/Web/DNS profiles attached to policies that don’t receive the appropriate traffic – e.g., DNS Filter on a policy where DNS is not physically transmitted,
the same, generic profile applied “everywhere,” without differentiating between users, servers, DMZs, or backups,
– disabled logging on UTM policies – something appears to be filtering, but there’s no visibility,
– lack of up-to-date signatures (FortiGuard issues, expired licenses),
– lack of Threat Feeds / External Block Lists – the firewall doesn’t use additional IOC feeds.
If interfaces are assigned to zones haphazardly or there are no zones at all, then:
– The same type of traffic (e.g., users from different locations) is mixed with traffic with different requirements (servers, DMZ), making it difficult to enforce security policies.
– As the network expands, additional ad hoc policies are added between individual interfaces, which facilitates the creation of “side gateways,”
– It is easier to accidentally allow traffic between segments that were intended to be separated,
– The management/MGMT interface is exposed to the internet, creating direct access to the admin panel, bypassing all segmentation.
Zones are used to group interfaces by function – if we don’t do this, we’re inviting leaks in the segmentation.
Several things typically occur at once:
– Any-any rules, which disrupt the entire concept of “who has access to what,”
– Lack of or improper use of zones – policies are built between individual ports instead of between logical segments,
– Chaos in address objects (different names for the same subnets) and orphaned objects that no one cleans up,
– Lack of policy comments and expiration dates – no one remembers who created a given rule or whether it’s still needed,
– Poor RBAC permissions – too many admins with full rights can quickly add exceptions that become permanent.
– In such an environment, segmentation exists only in diagrams, while real-world access is full of exceptions and “temporary” workarounds.
A poorly configured remote access VPN most often:
– bypasses key control mechanisms such as MFA/2FA and geopolitics, facilitating account takeovers and brute-force attacks,
– gives the user full access to the LAN instead of just specific applications/segments, meaning a single account gives the user broad access to the network,
– uses static routes or incorrectly configured split-tunneling, which causes problems with access to the internet and SaaS services,
– can be bypassed by logging/monitoring – logs don’t show what the user is actually doing after establishing the tunnel.
The result: from a security perspective, the VPN becomes the weakest link, and from a user perspective, it becomes the source of “magical” access problems.
The lack of updates and monitoring of new versions/vulnerabilities leads to:
– FortiGate operates with publicly known vulnerabilities, often already actively exploited in attacks,
IPS/AV/Web Filter engines rely on outdated signatures, so they don’t detect new malware families and attack techniques.
– The organization fails to meet basic security and regulatory requirements (NIS2, ISO, industry requirements) because it lacks a patch management process.
– The administrator responds only after an incident, rather than proactively after the advisory is published.
A good FortiGate configuration audit does four things:
1. It inventories the actual state – policies, objects, VPN, UTM, logging, FortiGuard, FMG, processes.
2. It maps this to risks – showing which errors are just “administrative clutter” and which ones actually open the network (any-any, no 2FA, MGMT issued, no logs, no updates).
2. It provides a prioritized remediation plan – quick wins (e.g., logs, 2FA, comments, disabling junk mail), then architectural changes (zones, segmentation, FMG), and finally, “nice to haves.”
4. It also forces a discussion about processes: testing, change management, log monitoring, which are usually as important as the device configuration itself.
Incorrect policy configuration causes the firewall to:
– allow traffic that was not intended, for example, by using broad any-any rules that “cover up” more specific rules,
– not use UTM/SSL Inspection because traffic falls into a simple rule without security profiles,
– not block addresses with a bad reputation when deny rules are too low on the list and never hit,
– not be auditable. The lack of comments and expiration dates makes it difficult to understand why a given policy exists and whether it is still necessary.
