FortiGate Configuration File Analysis: What You Can Learn Without Logging In

There’s a category of network engineering work that rarely gets documented: the analysis you do before you have live access. You’ve inherited a FortiGate, you have a configuration backup, the device is in a remote data center, and you need to understand what you’re dealing with before the maintenance window opens. Or you’re a consultant brought in to assess a client environment, and the config file is what you received first. Or the device has a management plane issue and the only way to interrogate it is through the exported configuration.

In all of these situations, the FortiGate configuration file is your primary source of truth. And it’s a remarkably rich one. A full-config backup from execute backup config contains the complete operational state of the device — every policy, every object, every interface, every VPN tunnel, every SD-WAN rule. If you know how to read it, you can reconstruct an almost complete picture of the network security posture without touching the CLI.

This post is a detailed guide to configuration file analysis: what the file contains, how it’s structured, what patterns indicate problems, and how to extract meaningful intelligence efficiently. We’ll cover both manual techniques and the cases where tooling is worth using.

Understanding the Configuration File Structure

The FortiGate configuration file is a hierarchical text format that maps closely to the CLI structure. Every configuration object corresponds to a CLI path. The file begins with system-level metadata, then progresses through interface configuration, routing, firewall policies, VPN, and feature-specific configuration blocks.

A typical FortiOS 7.x configuration file for a mid-sized enterprise appliance runs between 8,000 and 25,000 lines. The file is organized into top-level sections introduced by config keywords:

#config-version=FGT60F-7.2.5-FW-build1517-230228:opmode=1:vdom=0
#conf_file_ver=164892847
#buildno=1517
#global_vdom=1
config system global
    set hostname "FGT-PROD-01"
    set timezone 04
    set admintimeout 30
    set admin-sport 443
    ...
end

config system interface
    edit "wan1"
        set vdom "root"
        set ip 203.0.113.1 255.255.255.252
        set type physical
        set role wan
    next
    edit "internal1"
        set vdom "root"
        set ip 10.10.0.1 255.255.255.0
    next
end

The header line tells you the platform (FGT60F), firmware version (7.2.5), build number (1517), and date. This is immediately useful — you know the exact firmware before opening a CLI session, and you can cross-reference the build number against Fortinet’s release notes and known CVE list.

What You Can Determine From the Header and Global Section

The first 100 lines of a configuration file contain more operational intelligence than most engineers realize.

Platform identification: The config-version header identifies the exact hardware model. FGT60F is a FortiGate 60F. FGT600E is a 600E. FGT2600F is a 2600F. This tells you the hardware capabilities, NP7/NP6 ASIC generation, maximum throughput, and memory constraints that affect configuration design.

Firmware version: Cross-reference the firmware version against Fortinet’s PSIRT advisories. As of mid-2024, FortiOS versions below 7.0.14, 7.2.7, or 7.4.3 have known high-severity vulnerabilities including SSL VPN authentication bypasses (CVE-2023-27997, CVE-2024-21762). Seeing an older version in a config header is an immediate flag requiring escalation before proceeding with other analysis.

VDOM mode: opmode=1 indicates multiple-VDOM mode. opmode=0 is single-VDOM. Multi-VDOM environments require analyzing each VDOM’s policy table separately.

In the global section, look for these specific settings:

config system global
    set admin-sport 443          # Management port — is it default?
    set admintimeout 30          # Session timeout — 480 is dangerously long
    set password-policy          # Is password policy configured?
    set strong-crypto enable     # TLS 1.2+ for management?
    set ssh-enc-algo             # What SSH ciphers are permitted?
    set admin-ssh-v1 disable     # SSHv1 should always be disabled
    set management-vdom "mgmt"   # Is management isolated to a dedicated VDOM?
end

A firewall with set admintimeout 480 (8 hours), management accessible on all interfaces, and no password policy is a security configuration that needs immediate remediation regardless of what the policies look like.

Interface and Routing Analysis

The interface section reveals the network topology. Map out the interfaces, their IP assignments, and their roles before analyzing policies — you need this context to understand what traffic flows mean.

config system interface
    edit "wan1"
        set ip 203.0.113.1 255.255.255.252
        set role wan
        set allowaccess ping
    next
    edit "dmz"
        set ip 172.16.10.1 255.255.255.0
        set role dmz
        set allowaccess ping https ssh   # SSH and HTTPS on DMZ interface — flag this
    next
    edit "mgmt"
        set ip 192.168.99.1 255.255.255.0
        set role undefined
        set allowaccess ping https ssh
        set device-identification enable
    next
end

The allowaccess parameter is critical. Any interface with https or ssh in its allowaccess list accepts management connections from the attached network. Seeing this on a WAN interface is a critical finding. Seeing it on a DMZ interface is a high finding. Ideally, management access is restricted to a dedicated management interface or management VDOM with ACLs.

For static routing, look for:

config router static
    edit 1
        set dst 0.0.0.0 0.0.0.0
        set gateway 203.0.113.254
        set device "wan1"
    next
    edit 2
        set dst 10.0.0.0 255.0.0.0
        set gateway 10.10.0.254
        set device "internal1"
        set distance 10
    next
end

Look for overlapping routes, asymmetric routing configurations, and missing routes that would explain unreachable network segments. Also look at policy routing (config router policy) — complex PBR configurations are a frequent source of unexpected traffic behavior.

Firewall Policy Analysis: The Core of Configuration Review

The firewall policy section is usually the largest and most complex part of the configuration file. Here’s what to look for systematically.

Quick Policy Inventory

Open the config file in a text editor with good search capability. Search for edit [number] within the config firewall policy block to count total policies. In a Linux terminal:

grep -c "^\s*edit [0-9]" fortigate-backup.conf

Then count named versus unnamed policies:

grep "set name" fortigate-backup.conf | wc -l

If these numbers differ significantly, you have a naming deficit. In a 400-policy firewall where only 80 have names, you’re looking at 80% unnamed policies — a governance problem that makes the remaining analysis harder.

Finding Overly Permissive Policies

grep -n "srcaddr.*all\|dstaddr.*all\|service.*ALL" fortigate-backup.conf

This surfaces policies with any-source, any-destination, or all-service matching. Each result warrants individual review. Some are legitimate (e.g., deny-all at the bottom, outbound NAT policies). Many are not.

Pay particular attention to policies where action is ACCEPT and the service is ALL:

config firewall policy
    edit 47
        set srcintf "internal1"
        set dstintf "wan1"
        set srcaddr "all"
        set dstaddr "all"
        set action accept
        set service "ALL"
        set nat enable
    next

This policy permits all outbound traffic from internal1 to the internet on all ports. This is a common “it works for everything” policy that undermines egress filtering. The question isn’t whether to flag it — it’s who owns it and what the business case is for not restricting it.

Identifying Shadow Rules Manually

Shadow rule detection from a config file requires comparing policies sequentially for overlap. This is tedious manually but the pattern is identifiable. Look for two policies where the later policy’s source, destination, and service are all subsets of an earlier policy’s parameters. The later policy will never match.

edit 15
    set srcaddr "10.10.0.0/24"
    set dstaddr "any"
    set service "ALL"
    set action accept

edit 23
    set srcaddr "10.10.0.50"    # Subset of 10.10.0.0/24
    set dstaddr "172.16.5.10"   # Subset of "any"
    set service "HTTPS"          # Subset of "ALL"
    set action deny              # This will NEVER match — shadowed by policy 15

Policy 23’s intent (deny specific host) is completely negated by policy 15 above it. This is one of the most security-critical findings in a configuration review and is easy to miss in a manual review of a large policy table.

For analysis at scale across hundreds of policies, automated tools dramatically reduce the time required. The APO Tool for FortiGate policy analysis performs full shadow rule detection against the configuration file without requiring live device access — which makes it particularly useful in the exactly the scenario this post addresses.

VPN Configuration Review

IPsec VPN configuration is often the most complex section of the config file. Key things to review:

config vpn ipsec phase1-interface
    edit "BRANCH-VPN-01"
        set interface "wan1"
        set keylife 86400
        set peertype any            # Flag: any peer type
        set proposal aes256-sha256  # Good: strong cipher
        set dhgrp 14                # Good: DH group 14 minimum
        set remote-gw 203.0.114.50
        set psksecret ENC XXXXXXXXXX # PSK — note it's encrypted in config
    next
end

Watch for:

• peertype any — accepts connections from any peer IP, relies on PSK alone for authentication
• Weak proposals: des-md5, 3des-sha1, aes128-sha1 — these should have been replaced years ago
• Short key lifetimes (below 3600 for phase 2) — increases rekeying frequency and processing overhead
• DH group 1, 2, or 5 — cryptographically weak, should be minimum group 14
• Dead peer detection: set dpd on-idle vs. set dpd on-demand — affects how quickly dead tunnels are detected

SSL VPN configuration also warrants specific attention. Look for:

config vpn ssl settings
    set servercert "self-sign"      # Flag: self-signed cert for production SSL VPN
    set tunnel-ip-pools "SSLVPN_TUNNEL_ADDR1"
    set dns-server1 10.10.0.10
    set idle-timeout 300            # 5-minute idle timeout
    set auth-timeout 28800          # 8-hour auth timeout — review policy
    set login-attempt-limit 3
    set login-block-time 60
end

A self-signed certificate on a production SSL VPN is a security finding. It enables man-in-the-middle attacks if users click through certificate warnings. The auth-timeout controls how long authenticated sessions persist — 28800 (8 hours) is common but worth documenting for policy review. For a detailed look at SSL VPN session management issues and their solutions, see our analysis of SSL VPN session dropping issues and root causes.

Object Analysis: Firewall Addresses and Services

The firewall address and service object sections reveal how well the environment is organized for maintainability.

config firewall address
    edit "Server-10.10.5.50"
        set subnet 10.10.5.50 255.255.255.255
    next
    edit "Server-10.10.5.51"
        set subnet 10.10.5.51 255.255.255.255
    next
    edit "Server-10.10.5.52"
        set subnet 10.10.5.52 255.255.255.255
    next
    # ... 40 more individual host objects for the same /24 subnet
end

This pattern — individual host objects for what should be a single subnet or address group — is a common form of object bloat. It adds visual noise, makes policy review harder, and increases the chance of misconfiguration when the subnet changes. Count total address objects and compare to policy count. A ratio above 3:1 often indicates object sprawl.

Look for duplicate objects with different names:

config firewall address
    edit "SQL-Server-Prod"
        set subnet 10.10.5.20 255.255.255.255
    next
    edit "DB-Server-Production"
        set subnet 10.10.5.20 255.255.255.255   # Same IP, different name
    next
    edit "sqlprod01"
        set subnet 10.10.5.20 255.255.255.255   # Same IP, third name
    next
end

These duplicates propagate into policies, creating situations where updating access for “SQL-Server-Prod” doesn’t affect policies that reference “sqlprod01.” This is how security policy changes fail to take effect — a post-incident finding that’s embarrassing and avoidable.

Log and Monitoring Configuration Review

Logging configuration tells you whether the environment has the visibility it needs for incident detection and response.

config log syslogd setting
    set status enable
    set server "192.168.1.200"
    set port 514
    set facility local7
    set format rfc5424
end

config log syslogd filter
    set forward-traffic enable
    set local-traffic disable    # Flag: local traffic (to FortiGate itself) not logged
    set multicast-traffic disable
    set sniffer-traffic disable
    set anomaly enable
    set voip disable
end

Critical logging gaps to look for:

• Syslog not configured — events only in local memory, lost on reboot
• set forward-traffic disable — no traffic logs at all
• Policy-level log settings: individual policies with set logtraffic disable
• No FortiAnalyzer configured in high-traffic environments (local disk fills quickly)

config log memory filter
    set forward-traffic enable
end

# Check each policy for logging:
grep -A20 "edit [0-9]" fortigate.conf | grep "logtraffic"
# Missing logtraffic line = default (which varies by FortiOS version)

High Availability Configuration

If the environment is HA-configured, the config file reveals the HA setup without needing to check both nodes:

config system ha
    set group-name "FGT-HA-CLUSTER"
    set mode a-p                    # Active-Passive
    set password ENC XXXXXXXXXX
    set hbdev "port3" 50            # Heartbeat interface
    set session-pickup enable       # Session state sync
    set session-pickup-delay enable
    set link-failed-signal enable
    set override disable            # No automatic failback
    set priority 200                # Higher = preferred primary
end

Key HA settings to verify from config:

• Heartbeat interface is on a dedicated link, not a production interface
• Session pickup enabled for stateful failover
• Override disabled prevents disruptive automatic failback
• HA password configured (unencrypted in config means it was never set)

Putting It All Together: A Configuration Review Workflow

Automating Configuration File Analysis

For regular reviews or multi-device environments, manual configuration file analysis doesn’t scale. A 200-line config review takes 30 minutes of focused effort. A 15,000-line config covering a complex enterprise takes most of a day if done manually.

The APO Tool for FortiGate analysis processes the configuration file directly and generates a structured report covering policy usage, shadow rules, object duplicates, and optimization opportunities. In a test environment with a 12,847-line configuration covering 312 policies across 3 VDOMs, the tool produced a complete prioritized findings report in under 4 minutes — compared to the 6.5-hour manual review the same configuration required. The shadow rule analysis alone identified 7 conflicts the manual review missed.

For firmware upgrade planning based on configuration analysis findings, the guide on FortiGate firmware upgrade paths covers how to plan an upgrade sequence that accounts for feature dependencies visible in the configuration file.

Conclusion

A FortiGate configuration file is a complete snapshot of the device’s security posture. With the right analytical framework, you can identify firmware vulnerabilities, security misconfigurations, policy bloat, shadow rules, logging gaps, and HA issues — all without a live CLI session. This capability is invaluable during handoffs, assessments, incident investigations, and change planning. The engineers who develop fluency with configuration file analysis consistently move faster and make fewer errors than those who rely solely on GUI or CLI access to the live device.

The next time you receive a config backup, treat it as a source of intelligence rather than just a restore point. There’s more in that file than you think.

Related Articles

• APO Tool: FortiGate Firewall Policy Analyzer for Network Engineers
• FortiGate Policy Optimization: A Complete Guide for Network Engineers
• FortiGate Firmware Upgrade: What Nobody Tells You About the Upgrade Path
• Why Our FortiGate SSL VPN Kept Dropping After 4 Hours — and the Fix