List the FortiGate appliances this server can reach.

Call this first when several appliances may be configured, since every other tool takes an optional target argument naming one of these. When exactly one is configured, that argument can be omitted entirely.

Credentials are never included in the response.

Report appliance identity and health: model, serial, firmware, load.

The serial and firmware version come from the response envelope rather than the body. FortiOS puts them as siblings of the results object on every cmdb call, and helpers that unwrap straight to results discard them, which is why they appear missing from the API until you read the raw response.

Fields that a given firmware does not report are omitted rather than returned as null, so an absent key means the appliance did not offer the value. FortiOS 7.0.14, for instance, reports no uptime anywhere in the monitor tree.

Search the whole configuration for a term, across every object type.

Looks through address objects and groups, services, interfaces, static routes, and optionally policies, matching names, values, comments, and member lists. This is the tool for an open question such as "where does 203.0.113.0/24 appear" or "what mentions guest", when you do not yet know which kind of object holds the answer.

Check sources_checked before concluding from a zero result. A source that could not be read contributes no matches, so no matches is not the same as nothing found.

List firewall address objects, optionally filtered.

Address objects are the named source and destination values that policies reference. Each is reported with its type and a single readable value, so a subnet object shows CIDR, an FQDN object shows the hostname, and a MAC object shows the MAC addresses.

Compare count against total_available before concluding anything about the whole table. When truncated is present this is one page and next_offset says where the following one begins.

List firewall address groups and their members.

Compare count against total_available before concluding anything about the whole table. When truncated is present this is one page.

List firewall service objects with their protocols and ports.

Compare count against total_available before concluding anything about the whole table. When truncated is present this is one page.

List firewall policies in evaluation order, optionally filtered.

Policies come back in the order FortiOS evaluates them, and each carries an explicit order index so that ordering survives filtering and re-serialization. Order is the entire meaning of a ruleset, and a list position is not something downstream is obliged to preserve.

Three counts appear and they mean different things. count is rows in this page, total_available is rows matching your filters, and total_policies is the size of the whole ruleset. A truncated flag means this is one page of the matches, not all of them, which matters more here than elsewhere: reasoning about a ruleset from an arbitrary prefix of it produces confident wrong answers about what traffic is allowed.

The filters match names exactly and do not expand indirection. A policy referencing a group that contains your address will not match address, and a policy referencing a zone that contains your interface will not match interface. If filtered_out shows a filter removed everything, that is the cue: the object is probably reached through a group or a zone, and find_references answers "what touches this object" properly, walking those containers.

List virtual IPs, which are the destination NAT rules.

A VIP maps an external address, and optionally an external port, to an internal one. FortiOS stores those addresses inline on the VIP rather than as references to address objects.

Compare count against total_available before concluding anything about the whole table. When truncated is present this is one page.

Find what references an address, service, or interface, before changing it.

This answers the question that precedes every firewall change, which is whether something is safe to touch.

The authority is the appliance itself. FortiOS exposes the same reference lookup its web UI uses, which knows every table that can hold a reference, seventy-four of them for a firewall address on 7.0.14. This tool asks that endpoint and reports what it says in references. It also scans policies, groups, virtual IPs, and static routes directly, because those yield readable detail the endpoint does not, such as a policy's name and action.

Read verdict rather than inferring from a count:

• referenced, something points at it

• no_references, the appliance confirmed nothing does

• no_references_in_checked_scopes, the authoritative lookup was unavailable and a partial scan found nothing, which is a fact about four tables rather than about the appliance

• object_not_found, no address, group, service, virtual IP, or interface by this name exists, so the question is probably a typo

• indeterminate, something needed could not be read

safe_to_delete appears only for the first two, because a table this tool could not read cannot support a claim that nothing references the object. A denied read is the likely outcome for a correctly least-privileged token, so an incomplete answer is normal rather than exceptional, and sources_checked names what failed.

The two lists count different things, and will disagree without being in conflict. total_references and references count reference sites: a policy using one address as both its source and its destination is two. The detail lists (policies, groups, vips, routes) count objects, so the same policy appears once there, with referenced_as naming both roles. Neither number is wrong; prefer references when reporting what must be changed before a delete, and the detail lists when naming the objects an operator has to open.

Containers are walked through, and the results are kept separate. references holds what the appliance named directly and every row carries depth: 0. transitive_references holds what was reached through an address group, a service group, a zone, or a switch: each row carries the depth it was found at and a via chain of the container names that led to it. The distinction is the remedy. A direct reference is removed from the object holding it; a transitive one is removed by editing a container or a member list, and the policy that stops matching is not the object you edit.

expansion reports how far the walk got. status is complete when the chain ran out, depth_capped when it hit the ceiling with containers still unopened, which are then named in unexpanded, and incomplete when something along the way could not be read. Only complete means the transitive list is the whole blast radius.

List interfaces with their addresses, VLAN tags, and link state.

FortiOS creates bookkeeping interfaces alongside real ones, such as the quarantine interface that accompanies every wireless VAP. Those are hidden by default and named in hidden_internal so the omission is visible.

Which ones count as bookkeeping is decided by the appliance rather than by the name. FortiOS reports whether each interface is offered as a policy endpoint, and anything it offers is shown regardless of what it is called, so this tool cannot hide an interface a policy could name. hidden_internal_basis says whether that lookup succeeded; when it did not, the fallback is the name and the omission is less trustworthy.

Filters narrow the list silently unless you read filtered_out, which names each active filter and how many rows it removed. with_ip_only keeps interfaces carrying an IPv4 address in the configuration, which includes a DHCP interface that has taken a lease, because FortiOS writes the leased address back into the config.

An interface that holds no address reports addressing instead of ip. Use get_routing_table for the runtime view.

List VLAN sub-interfaces with their tags and parent interfaces.

A focused view of the VLAN subset of the interface table, since what VLANs exist and what they attach to is asked far more often than the full interface list. FortiOS quarantine VLANs are excluded, and filtered_out says how many that was.

List configured static routes.

These are the routes an operator configured, which is not the same as the routes in use. A DHCP-assigned default route never appears here because it was never configured. Use get_routing_table for what the appliance is actually forwarding on.

A route whose destination is a named address object is resolved to the underlying CIDR where possible, with the object name kept alongside it.

Show the active IPv4 routing table as the appliance is forwarding it.

This is live state rather than configuration, so it includes connected routes, dynamically learned routes, and routes handed over by DHCP, none of which appear in the static route configuration.

List wireless clients currently associated, enriched with DHCP and ARP.

Each client is joined against the DHCP lease and ARP tables by MAC, which is what turns an anonymous MAC into a recognizable device. The hostname comes from the DHCP lease, falling back to the vendor class identifier when the client sent no name. MAC addresses are reported in one canonical lowercase colon-separated form whatever spelling the source used, since that is what makes the join work at all.

authenticated is true or false only when the appliance said so, and absent when it did not, because inferring "not authenticated" from a missing field would fabricate a security-relevant claim.

List current DHCP leases issued by the appliance.

Read filtered_out before concluding anything from a short list. Both filters here drop rows without saying so otherwise, and an interface name with a typo produces an empty list that looks exactly like an appliance handing out no leases.

Show the ARP table, which is the IP-to-MAC bindings the appliance sees.

ARP catches devices DHCP does not, meaning anything with a static address, so it is the fallback when a device is present but holds no lease. MAC addresses are reported in one canonical form.

Identify a device on the network by MAC, IP, or hostname fragment.

Searches the wireless client list, the DHCP lease table, and the ARP table together, then merges everything known about each matching device into one record. A device seen in several places produces one result rather than three partial ones.

This is the tool for questions like "what is 198.51.100.47", "is that laptop on the network", or "which SSID is this MAC on".

A MAC query matches whatever punctuation the appliance used, so 20-47-47-7d-db-7b, 2047.477d.db7b, and 20:47:47:7d:db:7b all find the same device. An IP query is never treated as a MAC.