SimpleIPAM
Try It Free
Back to Blog
6 min read

Parsing FortiGate Configs: What We Extract and Why

FortiGate firewalls use a hierarchical config structure that's both powerful and complex. Here's exactly what SimpleIPAM extracts and how we make it useful.

The FortiGate Config Structure

FortiGate configs use a config / edit / next / end syntax. Everything is hierarchical, and sections can be deeply nested (especially with VDOMs).

SimpleIPAM parses six key sections from your FortiGate configuration:

  • Firewall Address Objects
  • Firewall Address Groups
  • System Interfaces
  • Virtual IPs (VIPs)
  • Static Routes
  • Security Zones

1. Firewall Address Objects

Address objects are the foundation of your firewall's IP management:

config firewall address
    edit "Server-Web-01"
        set subnet 10.1.1.10 255.255.255.255
        set comment "Production web server"
    next
    edit "Internal-Network"
        set subnet 10.0.0.0 255.0.0.0
    next
    edit "External-DNS"
        set type fqdn
        set fqdn "dns.google.com"
    next
end

What we extract:

  • Name: Object identifier (e.g., "Server-Web-01")
  • Type: host, subnet, range, fqdn, geography, dynamic
  • Value: IP address, CIDR, FQDN, or range
  • Subnet: Parent subnet calculated from value
  • Comment: Description field
  • Category: Auto-categorized as private, public, external, etc.

Why it matters: Address objects are reused across firewall policies, NAT rules, and routing. Knowing what each object represents is critical for understanding your firewall's logic.

2. Firewall Address Groups

config firewall addrgrp
    edit "Web-Servers"
        set member "Server-Web-01" "Server-Web-02"
        set comment "All web servers"
    next
    edit "Database-Cluster"
        set member "DB-Primary" "DB-Replica-01" "DB-Replica-02"
    next
end

What we extract:

  • Group name
  • Member list: All address objects or groups in the group (nested groups supported)
  • Member count
  • Comment

Why it matters: Groups help you understand logical server clusters, network segments, and service groups. When troubleshooting a policy, knowing what's in "All-Internal-Networks" is essential.

3. System Interfaces

config system interface
    edit "port1"
        set vdom "root"
        set ip 203.0.113.1 255.255.255.252
        set allowaccess ping https ssh
        set type physical
        set alias "WAN"
    next
    edit "port2"
        set ip 10.1.1.1 255.255.255.0
        set allowaccess ping https
        set type physical
        set alias "LAN"
    next
end

What we extract:

  • Interface name (port1, port2, VLANs, tunnels)
  • IP address and netmask
  • CIDR notation (calculated from IP/netmask)
  • Alias (human-readable name like "WAN" or "LAN")
  • Type: physical, vlan, tunnel, aggregate, etc.
  • VDOM (for multi-tenant configs)

Why it matters: Interfaces define your network boundaries. Understanding which subnet lives on which interface is fundamental to IP address management and routing decisions.

4. Virtual IPs (VIPs)

VIPs map external (public) IPs to internal (private) IPs for inbound NAT:

config firewall vip
    edit "VIP-WebServer"
        set extip 203.0.113.10
        set mappedip "10.1.1.5"
        set extintf "port1"
    next
    edit "VIP-HTTPS"
        set extip 203.0.113.10
        set mappedip "10.1.1.5"
        set extintf "port1"
        set portforward enable
        set extport 443
        set mappedport 8443
    next
end

What we extract:

  • VIP name
  • External IP: The public-facing address
  • Mapped IP: The internal server address
  • External interface
  • Port mapping: If portforward is enabled, we capture external to mapped port translation

Why it matters: VIPs are critical for understanding how your public IPs map to internal servers. When you see traffic to 203.0.113.10, you need to know it's actually going to 10.1.1.5.

5. Static Routes

config router static
    edit 1
        set gateway 203.0.113.1
        set device "port1"
        set comment "Default route to ISP"
    next
    edit 2
        set dst 10.2.0.0 255.255.0.0
        set gateway 10.1.1.254
        set device "port2"
        set distance 10
    next
end

What we extract:

  • Destination network: CIDR block (0.0.0.0/0 for default route)
  • Gateway IP
  • Egress interface
  • Administrative distance: Route priority
  • Comment

Why it matters: Static routes determine how traffic reaches remote networks. If you're managing multi-site networks or branch offices, routes show you how subnets are interconnected.

6. Security Zones

config system zone
    edit "WAN"
        set interface "port1" "port1-vlan100"
        set description "External zone"
    next
    edit "LAN"
        set interface "port2" "port3"
        set description "Internal zone"
    next
    edit "DMZ"
        set interface "port4"
        set description "DMZ servers"
    next
end

What we extract:

  • Zone name (WAN, LAN, DMZ, etc.)
  • Member interfaces
  • Description

Why it matters: Zones group interfaces by trust level. Understanding which interfaces belong to which zones is critical for interpreting firewall policies.

What We Don't Parse (And Why)

SimpleIPAM is focused on IP address management, not firewall policy analysis. We intentionally skip:

  • Firewall policies: We're developing a separate tool for policy analysis and audit workflows
  • Service objects: TCP/UDP ports aren't relevant to IP management
  • SSL VPN users: Not IP-related
  • IPS/AV signatures: Security profiles are out of scope

How We Handle VDOMs

If your FortiGate uses Virtual Domains (VDOMs), we extract the VDOM context for each object. This helps you understand which objects belong to which virtual firewall instance.

All extracted data includes a vdom field (defaults to "root" for single-VDOM configs).

Try It Yourself

Upload your FortiGate config and see what we extract:

Analyze Your FortiGate Config

No registration required. Config is processed in your browser and not stored.

Tagged: fortigate, parsing, technical