The IP Address Spreadsheet Problem

Almost every network team starts with Excel. It makes sense—you already have it, it's flexible, and the first version takes five minutes to create.

Then reality sets in:

• Nobody updates it: The spreadsheet says 10.1.1.50 is available, but someone assigned it last week during a change window and forgot to update the doc

• Version control nightmares: "IP_addresses_FINAL_v3_UPDATED_johns_version.xlsx" sitting in three different SharePoint folders

• Collaboration breaks down: Two people edit different copies, changes get lost, conflicts appear

• Scaling is painful: Managing a /16 means 65,000 potential rows. Excel starts choking around 50,000.

• No validation: Nothing stops someone from entering "10.1.1.500" or duplicating an existing assignment

Why Teams Keep Using It Anyway

The alternatives haven't been great:

• Enterprise IPAM tools: $35,000-300,000/year. Requires dedicated infrastructure, training, and ongoing maintenance. Overkill for most teams.

• Open-source IPAM (phpIPAM, NetBox): Free but requires database setup, web servers, and network scanning infrastructure. Still too much overhead.

• Cloud IPAM services: Monthly fees for features you might not need. Yet another login and integration to manage.

So teams stick with Excel because the alternatives require more effort than the problem seems to justify.

The Real Source of Truth

Here's the thing: your most accurate IP data already exists. It's in your firewall configuration.

Think about it. Your FortiGate or Palo Alto config contains:

• Every address object you've defined

• All subnets and their assignments

• Interface IP addresses

• VIP/NAT mappings

• Static routes showing network topology

This data is always current because the firewall won't work if it's wrong. It's maintained as part of normal operations. It doesn't require a separate update process.

The spreadsheet is always trying to mirror what's in the firewall config anyway—so why not just read the config directly?

Config Parsing vs. Spreadsheets

The Best of Both Worlds

You don't have to give up spreadsheets entirely. Here's a better workflow:

1. Export your firewall config (you should be doing this for backups anyway)

2. Parse the config to extract all IP data automatically

3. Export to CSV for analysis, documentation, or compliance reports

4. Keep the CSV as a snapshot rather than a living document

Need updated information? Just re-export the firewall config and parse again. Takes seconds, always accurate.

When You Actually Need Excel

Config parsing covers what's currently configured. Excel (or a proper IPAM tool) might still make sense for:

• IP planning: Allocating space for future projects before they're configured

• Reservation tracking: Recording IPs reserved but not yet assigned

• Historical records: Tracking who requested what and when

• DHCP ranges: Documenting dynamic pools that aren't in firewall config

For everything else—understanding what's actually deployed—let the config be your source of truth.

Try It Now

SimpleIPAM parses FortiGate and Palo Alto configs and shows you every IP address, subnet, interface, VIP, and route in seconds.

Upload Your Config

No signup. No infrastructure. Just drag, drop, and see your IP space organized.

The phpIPAM Approach

phpIPAM is built around a traditional IPAM model: deploy the software, configure database backends, set up scanning agents, and maintain the infrastructure. It's powerful, but it comes with operational overhead.

Common challenges teams face with phpIPAM:

• Infrastructure requirements: MySQL/MariaDB database, web server, PHP—all need ongoing maintenance

• Network scanning setup: Scanning agents need network access, firewall rules, and credential management

• Data accuracy: Scanning shows what's live on the network, but not what's configured in your firewall

• Update cycles: Database needs to stay in sync with network changes

A Different Approach: Config-Based IPAM

What if you could skip the scanning entirely and get your IP data from the source of truth—your firewall configuration?

Your FortiGate or Palo Alto config already contains:

• Every address object you've defined

• All address groups and their members

• Interface IP assignments

• VIP/NAT mappings

• Static routes and next hops

• Security zone definitions

This is the data that actually matters for understanding your IP allocation—and it's already organized and maintained as part of your firewall management.

When Config-Based IPAM Makes Sense

This approach works particularly well for:

• MSPs managing multiple clients: Upload each client's firewall config, get instant visibility without deploying scanning infrastructure at every site

• Network audits: Document IP allocation quickly without setting up persistent monitoring

• Migration planning: Understand the current state before making changes

• Compliance documentation: Generate accurate IP inventories from authoritative config files

• Small teams: Get IPAM functionality without dedicated infrastructure

When phpIPAM Is Still Better

To be fair, phpIPAM and similar scanning-based tools have strengths that config parsing doesn't cover:

• Live network state: Scanning shows what's actually responding on the network right now

• DHCP integration: phpIPAM can integrate with DHCP servers for dynamic IP tracking

• DNS management: Some tools integrate DNS record management

• Rogue device detection: Scanning can find unauthorized devices

If you need these capabilities, a scanning-based tool makes sense. But many teams discover they primarily need visibility into their planned IP allocation—what's configured—rather than continuous live monitoring.

Quick Comparison

Try Config-Based IPAM

SimpleIPAM takes the config parsing approach. Upload your FortiGate or Palo Alto config file and see your entire IP address space in seconds—no database setup, no scanning agents, no ongoing maintenance.

Try SimpleIPAM Free

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

The NetBox Experience

NetBox (originally built by DigitalOcean) combines DCIM and IPAM into one platform. It's powerful, well-maintained, and has a great API. But here's what comes with that power:

• Database setup: PostgreSQL required

• Redis cache: Needed for background tasks

• Web server: nginx/Apache with WSGI

• Data model complexity: Sites, racks, devices, interfaces, cables, circuits—even when you just want IPs

• Manual data entry: All information must be entered or imported through API

A common sentiment from the community: "DCIM has been immediately appreciated; but, IPAM has been lacklustre." NetBox is a DCIM tool with IPAM bolted on—not an IPAM tool first.

What Small Teams Actually Need

If you don't have a data center to manage—or you have one but just need IP visibility—you probably want:

• A clear view of what IP addresses are allocated

• Which subnets are in use and where

• Address objects and their relationships

• Documentation you can export and share

• Minimal setup and no ongoing infrastructure

You don't need to define rack elevations or track patch panel ports. You need to know what IPs are used where.

The Manual Entry Problem

Both NetBox and phpIPAM share a fundamental challenge: data has to get into the system somehow. Options are:

• Manual entry: Tedious and error-prone

• CSV import: You have to build the CSV first

• API scripts: Requires development effort

• Network scanning: NetBox doesn't even include this

The irony: the most accurate IP data in your environment is already structured and maintained—in your firewall configuration files. Every address object, group, interface, and route is defined there, kept current because the firewall won't work otherwise.

Config-Based IPAM: Skip the Data Entry

What if you could extract IP information directly from your firewall config? Your FortiGate or Palo Alto backup file contains:

• Every IP address object you've created

• Address groups with full member lists

• Interface assignments and subnets

• VIP/NAT mappings

• Static routes

• Zone definitions

Upload the config, get immediate visibility. No data entry, no sync issues, no infrastructure.

When NetBox Is Still the Right Choice

NetBox makes sense when you genuinely need DCIM capabilities:

• Managing physical rack layouts across data centers

• Tracking cables and cross-connects

• Circuit and provider management

• Maintaining relationships between physical and logical infrastructure

• Running automation pipelines that need NetBox as source of truth

If you're at that scale, NetBox is excellent. But if you're a small team managing a few firewalls and need IP visibility—you're using a sledgehammer for a nail.

Quick Comparison

Try the Simpler Approach

SimpleIPAM extracts IP data directly from your firewall configuration. Upload your FortiGate or Palo Alto config and see your IP space organized and searchable in seconds.

Analyze Your Config Free

No database. No Redis. No data entry. Just upload and see results.

Why Audit IP Configuration?

Firewall configurations accumulate technical debt over time. Address objects get created for one-off projects and never removed. Subnets get allocated and forgotten. VIPs stay configured long after servers are decommissioned.

Regular audits help you:

• Identify unused address objects cluttering your config

• Spot IP conflicts before they cause outages

• Document actual IP allocation for compliance

• Plan capacity for new projects

• Prepare for migrations with accurate inventory

The Audit Checklist

1. Address Object Inventory

• ☐ Export all address objects with their values

• ☐ Count total objects by type (host, subnet, range, FQDN)

• ☐ Identify objects with missing or outdated descriptions

• ☐ Flag objects not referenced in any policy (potential cleanup candidates)

• ☐ Check for duplicate objects pointing to the same IP

2. Address Group Analysis

• ☐ List all groups and their member counts

• ☐ Identify empty groups (zero members)

• ☐ Expand nested groups to see full membership

• ☐ Check for circular group references

• ☐ Verify group naming follows conventions

3. Interface and Subnet Review

• ☐ Document all interface IP assignments

• ☐ Verify no overlapping subnets on different interfaces

• ☐ Check interface descriptions match actual usage

• ☐ Identify interfaces without IP assignments

• ☐ Verify zone assignments are correct

4. VIP/NAT Mapping Review

• ☐ List all VIPs with external→internal mappings

• ☐ Verify internal servers still exist for each VIP

• ☐ Check for VIPs pointing to decommissioned IPs

• ☐ Document port mappings (external port → internal port)

• ☐ Identify unused public IPs in VIP pool

5. Route Table Analysis

• ☐ Export all static routes

• ☐ Verify next-hop IPs are reachable

• ☐ Check for routes to decommissioned networks

• ☐ Identify overlapping routes with different metrics

• ☐ Document default gateway configuration

6. RFC 1918 and Public IP Review

• ☐ Categorize all IPs as private (RFC 1918) or public

• ☐ Verify public IPs are actually owned/assigned to you

• ☐ Check for accidental use of public IPs internally

• ☐ Identify CGNAT ranges (100.64.0.0/10) if applicable

• ☐ Document link-local addresses (169.254.x.x)

Common Issues to Look For

Stale Objects

Address objects created for projects that ended years ago. Look for objects with old naming conventions, references to decommissioned systems, or descriptions mentioning past dates.

Overly Broad Definitions

Objects like "any" or "0.0.0.0/0" used in places where they shouldn't be. Also watch for /8 or /16 subnets when more specific ranges would be appropriate.

Naming Inconsistencies

Mixed naming conventions: "Web-Server-01" vs "WEBSRV_01" vs "web-server-1". This makes maintenance harder and indicates config accumulated from multiple admins over time.

Missing Documentation

Objects without descriptions or with unhelpful descriptions like "temp" or "test". Every object should explain what it's for and who owns it.

Automating the Audit

Manually reviewing a firewall config with hundreds of address objects is tedious and error-prone. Here's a faster approach:

1. Export your firewall config backup

2. Upload to SimpleIPAM for automatic parsing

3. Export the structured data as CSV

4. Use the CSV to work through this checklist

5. Document findings and remediation actions

Start Your Config Audit

After the Audit

Once you've identified issues, prioritize remediation:

1. Critical: IP conflicts, incorrect VIP mappings, routing issues

2. High: Unused objects referenced in policies, stale NAT rules

3. Medium: Missing documentation, naming inconsistencies

4. Low: Completely unused objects (safe to remove but not urgent)

Make config changes during maintenance windows, and always have a rollback plan.

Getting Your Palo Alto Config

First, export your running configuration. You have two options:

Via GUI:

1. Navigate to Device → Setup → Operations

2. Click "Export named configuration snapshot"

3. Select "running-config.xml"

4. Save the downloaded XML file

Via CLI:

> show config running

Copy the output and save as an .xml file.

Palo Alto XML Structure

Unlike FortiGate's text-based config, Palo Alto uses hierarchical XML. The structure follows this pattern:

<config>
  <devices>
    <entry name="localhost.localdomain">
      <vsys>
        <entry name="vsys1">
          <address>
            <!-- Address objects here -->
          </address>
          <address-group>
            <!-- Address groups here -->
          </address-group>
        </entry>
      </vsys>
      <network>
        <interface>
          <!-- Interfaces here -->
        </interface>
        <virtual-router>
          <!-- Routes here -->
        </virtual-router>
      </network>
    </entry>
  </devices>
</config>

1. Address Objects

Address objects are the building blocks of your firewall policies. They're stored under each vsys:

<address>
  <entry name="Web-Server-01">
    <ip-netmask>10.1.1.100/32</ip-netmask>
    <description>Production web server</description>
    <tag>
      <member>Production</member>
    </tag>
  </entry>
  <entry name="Internal-Network">
    <ip-netmask>10.0.0.0/8</ip-netmask>
  </entry>
  <entry name="Partner-DNS">
    <fqdn>dns.partner.com</fqdn>
  </entry>
  <entry name="IP-Range-DHCP">
    <ip-range>192.168.1.100-192.168.1.200</ip-range>
  </entry>
</address>

What SimpleIPAM extracts:

• Name: The object identifier from the entry name attribute

• Type: ip-netmask (host or subnet), ip-range, or fqdn

• Value: The IP address, CIDR, range, or domain

• Description: Documentation text if present

• Tags: Organizational labels

• vsys: Which virtual system contains this object

2. Address Groups

Groups reference address objects by name:

<address-group>
  <entry name="Web-Servers">
    <static>
      <member>Web-Server-01</member>
      <member>Web-Server-02</member>
      <member>Web-Server-03</member>
    </static>
    <description>All production web servers</description>
  </entry>
  <entry name="All-Internal">
    <static>
      <member>Internal-Network</member>
      <member>VPN-Users</member>
    </static>
  </entry>
</address-group>

What SimpleIPAM extracts:

• Group name

• Member list: All referenced address objects

• Member count

• Type: Static (explicit members) or dynamic (tag-based)

• Description

3. Network Interfaces

Interfaces are defined in the network section:

<network>
  <interface>
    <ethernet>
      <entry name="ethernet1/1">
        <layer3>
          <ip>
            <entry name="203.0.113.1/30"/>
          </ip>
        </layer3>
        <comment>WAN Interface</comment>
      </entry>
      <entry name="ethernet1/2">
        <layer3>
          <ip>
            <entry name="10.1.1.1/24"/>
          </ip>
          <interface-management-profile>Allow-Ping</interface-management-profile>
        </layer3>
        <comment>LAN Interface</comment>
      </entry>
    </ethernet>
    <loopback>
      <entry name="loopback.1">
        <ip>
          <entry name="10.255.255.1/32"/>
        </ip>
      </entry>
    </loopback>
  </interface>
</network>

What SimpleIPAM extracts:

• Interface name: ethernet1/1, loopback.1, tunnel.1, etc.

• IP address with CIDR

• Interface type: Ethernet, loopback, tunnel, VLAN

• Comment/description

• Zone assignment (from zone configuration)

4. Static Routes

Routes are defined in virtual-router configuration:

<virtual-router>
  <entry name="default">
    <routing-table>
      <ip>
        <static-route>
          <entry name="Default-Route">
            <destination>0.0.0.0/0</destination>
            <nexthop>
              <ip-address>203.0.113.2</ip-address>
            </nexthop>
            <interface>ethernet1/1</interface>
            <metric>10</metric>
          </entry>
          <entry name="Branch-Office">
            <destination>10.2.0.0/16</destination>
            <nexthop>
              <ip-address>10.1.1.254</ip-address>
            </nexthop>
            <interface>ethernet1/2</interface>
          </entry>
        </static-route>
      </ip>
    </routing-table>
  </entry>
</virtual-router>

What SimpleIPAM extracts:

• Route name

• Destination network: CIDR notation

• Next hop IP

• Egress interface

• Metric

• Virtual router name

5. Security Zones

Zones group interfaces by trust level:

<zone>
  <entry name="Trust">
    <network>
      <layer3>
        <member>ethernet1/2</member>
        <member>ethernet1/3</member>
      </layer3>
    </network>
  </entry>
  <entry name="Untrust">
    <network>
      <layer3>
        <member>ethernet1/1</member>
      </layer3>
    </network>
  </entry>
  <entry name="DMZ">
    <network>
      <layer3>
        <member>ethernet1/4</member>
      </layer3>
    </network>
  </entry>
</zone>

6. NAT Rules

NAT rules map external to internal addresses:

<nat>
  <rules>
    <entry name="NAT-Web-Server">
      <source-translation>
        <dynamic-ip-and-port>
          <interface-address>
            <interface>ethernet1/1</interface>
          </interface-address>
        </dynamic-ip-and-port>
      </source-translation>
      <to>
        <member>Untrust</member>
      </to>
      <destination>
        <member>any</member>
      </destination>
      <source>
        <member>Web-Server-01</member>
      </source>
    </entry>
  </rules>
</nat>

Handling Multi-vsys Configurations

If your Palo Alto uses multiple virtual systems, SimpleIPAM extracts data from each vsys separately and tags objects with their vsys context. This lets you see which virtual firewall owns each address object.

What We Don't Parse

SimpleIPAM focuses on IP address management. We intentionally skip:

• Security policies: That's a different type of analysis

• Service objects: TCP/UDP ports aren't relevant to IPAM

• User-ID configuration: Not IP-related

• Threat prevention profiles: Security profiles are out of scope

• GlobalProtect settings: VPN config is separate from IP allocation

Try It With Your Config

Upload your Palo Alto config and see what we extract:

Analyze Your Palo Alto Config

Works with PAN-OS 10.x and 11.x. No registration required.

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.

The Traditional IPAM Approach

Most IPAM tools work by scanning your network infrastructure:

1. You provide network device credentials (SNMP, SSH, API keys)

2. Agents query devices every few minutes/hours

3. Data is aggregated in a central database

4. You get a dashboard of current network state

This works, but it comes with significant overhead.

The Hidden Costs of Network Scanning

1. Security Risks

Network scanning requires credentials — lots of them:

• SNMP community strings for every device

• SSH keys or passwords for CLI access

• API tokens for REST-based management

• Service accounts in Active Directory

Now you're managing credential rotation, security reviews, and access controls for a tool that's supposed to simplify your life. When the IPAM tool gets compromised, an attacker has credentials to your entire network.

2. Firewall Configuration

To scan your network, the IPAM tool needs access to it. That means:

• Opening firewall rules for SNMP (UDP 161)

• Allowing SSH access (TCP 22) from the IPAM server

• Permitting HTTPS API calls to management interfaces

• Maintaining these rules across firewall upgrades and reconfigurations

Every firewall rule is a potential attack vector. Every management interface exposed is a risk.

3. Performance Impact

Network scanning isn't free:

• SNMP polling adds load to device CPUs

• SSH sessions consume memory

• API queries impact management plane performance

• Large networks can take 30-60 minutes to scan completely

We've seen cases where aggressive IPAM scanning caused management interface slowdowns during critical troubleshooting.

4. Compliance Headaches

Regulatory frameworks (PCI DSS, HIPAA, SOC 2) have specific requirements around:

• Credential management and rotation

• Network access logging

• Third-party tool security reviews

• Data retention and privacy

Scanning-based IPAM tools trigger all of these requirements. Your compliance team will want documentation, audits, and assurances before approval.

The Config-Based Alternative

SimpleIPAM sidesteps all of these problems by using a fundamentally different data source: your firewall configuration files.

Security Benefits

• Zero network access: We never connect to your network. No credentials to store, rotate, or leak.

• You control the data: Redact sensitive information before upload. Remove comments, hostnames, or anything you don't want to share.

• No persistent storage (in preview): Configs are parsed and discarded. Nothing is retained on our servers.

• Audit-friendly: Easy to demonstrate to auditors — just show them the config you uploaded (or didn't).

Speed Benefits

• Results in seconds: Parsing a 50,000-line FortiGate config takes 3-5 seconds. No waiting for scan cycles.

• No device impact: Zero load on your production infrastructure.

• Instant updates: Made a config change? Upload the new config and see updated results immediately.

Compliance Benefits

• No credential management: Eliminates an entire category of compliance requirements.

• No network access logging: The tool never touches your network.

• Minimal security review: Upload a config, get results. No agents, no scanning, no persistent connections.

What You Give Up

Config-based IPAM isn't perfect. Here's what you lose compared to scanning:

• Real-time DHCP utilization: We can't tell you how many addresses are currently leased from your DHCP pools.

• Rogue device detection: We won't find devices that shouldn't be on your network.

• Automatic updates: You need to re-upload configs to see changes. No continuous monitoring.

• Layer 2 visibility: We don't see MAC addresses, switch ports, or ARP tables.

For many teams, these tradeoffs are worth it. If your primary pain point is "I don't know what's in my firewall config," SimpleIPAM solves that instantly. If you need real-time DHCP monitoring, you probably still need a traditional IPAM tool.

Future: API-Based Integration (Not Scanning)

We're planning to support API-based cloud integrations for AWS, Azure, and Google Cloud VPC data. You provide credentials, we fetch metadata about your cloud subnets.

Key difference: This is read-only API access to cloud metadata, not network scanning. You're in control of what we can access via IAM policies.

Try It Yourself

The best way to understand the difference is to experience it:

Upload a Config and See Results in 5 Seconds

No registration required. No credentials to provide. Just upload and see what we extract.

The Problem

If you've managed network infrastructure for any length of time, you know this spreadsheet. It has 50+ tabs, one for each site or VLAN. The formulas break randomly. Someone edits it during a change window, and suddenly nobody knows what's assigned where. And it's always out of sync with your actual firewall configs.

Enterprise IPAM tools exist — SolarWinds, Infoblox, BlueCat — but they come with significant overhead:

• $10,000+ annual licensing

• Network scanning agents to deploy

• Credentials to manage and rotate

• Firewall rules to configure

• Security review processes

• 3-6 month deployment timelines

For small and mid-sized networks, this is overkill. Most teams end up sticking with the spreadsheet because the alternative is too complex and expensive.

A Different Approach

SimpleIPAM takes a fundamentally different approach: instead of scanning your network, we parse your firewall configuration.

Your firewall config already contains everything you need to know about your IP address space:

• Address objects (hosts, subnets, ranges)

• Address groups and their members

• Interface IP assignments

• VIP/NAT mappings

• Static routing tables

• Security zones

We extract all of this in seconds and present it in a visual, searchable format. No scanning. No credentials. No agents.

How It Works

1. Upload your config: Drag and drop your FortiGate or Palo Alto configuration file. Or paste CSV/Excel data if that's what you have.

2. Instant parsing: We extract every address object, group, interface, VIP, route, and zone from your config.

3. Visual exploration: Browse your entire IP hierarchy. Click any subnet to see utilization. Search for specific addresses. Spot conflicts.

4. Export results: Download everything as CSV for further analysis or documentation.

The entire process takes 5-10 seconds. No deployment, no infrastructure, no credentials.

What We Support Today

• FortiGate: Full support for address objects, address groups, interfaces, VIPs, zones, and static routes

• Palo Alto: XML parsing for address objects, groups, NAT rules, interfaces, zones, and routing

• Excel/CSV: Import IP address data from spreadsheets (yes, we know you have them)

Coming soon: Cisco IOS/NX-OS router and switch configs, expanding beyond just firewalls to give you complete visibility across your network infrastructure.

Why No Scanning?

This deserves its own post (which we'll publish soon), but here's the short version:

Security: No scanning means no network credentials to manage, no firewall rules to configure, and zero attack surface from the tool itself. You control what you upload.

Speed: Config parsing takes seconds. Network scanning takes minutes to hours, especially for large networks.

Compliance: Need to demo the tool but can't give us network access? Redact sensitive data from your config and upload. Perfect for security-conscious environments.

Try It Now

SimpleIPAM is live and free to use in preview mode. Upload a config and see what you think:

Try SimpleIPAM Free

We're working toward a paid tier with features like saved configs, change tracking, multi-site topology, and team collaboration. The core parsing and visualization will always be free.

We'd Love Your Feedback

We built SimpleIPAM to solve our own IP management problems, but we want to make sure it solves yours too.

Questions we're asking:

• What firewall/network vendors should we support next?

• What features would make you ditch the spreadsheet?

• What's missing from the current implementation?

Send us feedback using the feedback button in the header, or email hello [at] simpleipam [dot] com.