Articles

FortiGate Address Object Cleanup: Audit and Remove Stale IP and FQDN Definitions

FortiGate configurations accumulate unused address objects for years, creating policy noise and audit risk. This checklist walks operators through identifying zero-reference objects, safely purging them, and preventing future bloat.

R
Retrievy Team
3 min read
FortiGate Address Object Cleanup: Audit and Remove Stale IP and FQDN Definitions

FortiGate configurations grow in one direction. Firewall engineers add address objects for projects, migrations, and one-off exceptions, but deletions rarely follow decommissions. After two or three years on a busy FortiGate, it is common to find 40% or more of all address objects referenced in zero active policies. That dead weight complicates audits, slows policy reviews, and creates confusion when engineers misread an old object as authoritative.

This checklist covers the full cleanup cycle: discovery, validation, removal, and prevention. It applies to FortiOS 7.x running on any hardware or VM platform. All CLI commands assume an admin account with read-write access to the firewall policy and object tables.


Before You Start

Take a configuration backup before touching anything. Run execute backup config ftp or pull the backup through FortiManager if you manage at scale. Confirm the backup restores cleanly in a lab or staging unit before proceeding on production.


The Cleanup Checklist

  1. Export the full address object list. Run show firewall address and show firewall addrgrp from the CLI and redirect output to a file. If you manage multiple VDOMs, repeat per VDOM with config vdom / edit <name> context active. This gives you the raw inventory you will cross-reference against policy usage.

  2. Identify zero-reference objects using the built-in unused-objects report. In FortiOS 7.2 and later, navigate to Policy & Objects > Addresses, then use the column filter "Referenced" and set it to 0. In the CLI, diagnose firewall iprope lookup can help spot objects missing from compiled policy tables. For FortiOS versions below 7.2, export the policy table with show firewall policy and write a diff against the address list manually or via a script.

  3. Check references beyond firewall policies. An address object showing zero firewall policy references may still be active in VPN phase-2 selectors, SSL-VPN split tunnels, traffic shaping policies, or SD-WAN rules. Before marking any object for deletion, run:

    grep -i "<object-name>" <full-config-export>
    

    against a full show full-configuration export. Objects appearing only in comment fields are safe to remove; objects appearing in any non-policy stanza are not.

  4. Validate IP and FQDN currency. For IP-type objects, cross-reference against your IPAM or cloud console. For FQDN-type objects, resolve each hostname. FQDNs that no longer resolve, or that resolve to IPs outside your managed ranges, are strong candidates for removal regardless of reference count. A stale FQDN object that still appears in a policy is more dangerous than an unused one, because FortiOS will silently match nothing rather than raise an error.

  5. Stage deletions in a change window, not ad hoc. Batch your confirmed removals into a single change window. Use config firewall address / delete <name> for individual objects or prepare a script using the FortiGate REST API (DELETE /api/v2/cmdb/firewall/address/<name>). Run deletions in a maintenance window with traffic monitoring active so you can catch any unexpected drops within the first 15 minutes.

  6. Remove or flatten stale address groups. After removing individual objects, audit address groups with show firewall addrgrp. Groups that now contain zero members, or groups whose only members were just deleted, must be removed explicitly. FortiOS does not automatically dissolve an address group when its last member is deleted; it leaves an empty group that can cause policy compilation warnings.

  7. Document the baseline. Record the pre-cleanup object count, the post-cleanup count, and the date. Export the cleaned configuration as your new baseline. Retrievy's FortiGate hygiene checks can track object count drift against this baseline on a scheduled cadence, flagging net-new objects that go unreferenced for more than 30 days.

  8. Establish a creation gate going forward. Require a naming convention that embeds a ticket or project identifier (for example, PROJ-4821_webserver-dmz). Set a calendar reminder or automated check to review objects older than 90 days with zero references. The naming convention makes the next audit take minutes instead of hours.


What This Does Not Cover

This checklist addresses address objects and address groups only. Service objects, schedule objects, and application signatures accumulate the same kind of bloat and deserve their own pass. Treat this cleanup as the first phase of a broader FortiGate configuration hygiene programme, not a one-time fix.

Next step

What does Retrievy find on your stack?

Plug it into one cloud account, one identity domain, or one firewall. Under an hour to the first real audit, with findings mapped to every framework you care about.

Read-only by design. One platform for cloud, identity, and on-prem.