Description
This article describes how to verify and troubleshoot what objects are referenced to a system object on an interface or a VDOM.
Scope
FortiGate.
Solution
FortiOS uses a structured, tree-like syntax and object location definition, for example, the path for a Firewall Address Object will be: Firewall/Address/<name>.
The CLI Syntax to enter this name (or context) is the following:
config firewall address <name>
Objects, once created within FortiOS, can be referenced and thus be used in other areas such as a Firewall Policy or an Address-Group. In the FortiGate web GUI, these references can be seen in the 'Ref.' column (typically at the far-right of the page, though sometimes the column needs to be added to the table).
In the following screenshot, Firewall Address objects are configured in Policy & Objects -> Addresses, and the 'FAC' object shows a value of 3 under the Ref. column (indicating that this object is referenced in three places), whereas the 'ipsec_subnet' object shows zero references. To show the specific references in the configuration, select the 'Ref.' number associated with the object.
Another way to find the references is to edit that object and select the References button, as shown below:
In this example scenario, the 'FAC' address object's references show that the object is used in several Firewall Policies:
Important Note 1: If objects are referenced elsewhere in the configuration, then it is generally not possible to delete them or assign them to certain new use-cases. Here are two such examples of this behavior:
- The FortiGate may not show a particular interface when attempting to add it to a Hardware/Software Switch interface. Attempts to do so from the CLI will also terminate with an 'object in use' error, and this is because there are outstanding references to the interface.
For example, the interface (for example, internal1) might have existing IP addresses assigned, DHCP servers configured, static routes, etc., that are referencing the interface. - An admin attempts to delete an unused Address‐Object but is not able to do so. In the GUI, the reference number may not be visible next to the object, and in the CLI, an error that the 'Object is in use' is received, and it cannot be deleted.
If the references are not easily found in the GUI, then the alternative is to use the CLI to locate references to the object.
Important Note 2: The CMDB (which is the system that manages the FortiGate configuration and the list of object references) can only list references for objects that exist within the same VDOM. While the vast majority of configurations are confined within a given VDOM, some specific areas can cross between VDOMs.
For example, Administrator accounts are defined within the Global VDOM (even when not using multi-VDOM mode), whereas User Group objects can only exist within non-Global VDOMs such as root. When a User Group is referenced in an Administrator configuration (for example, an admin entry of type 'Match all users in a remote server group' is created), the User Group will not include this in its list of References (neither in the GUI nor the CLI). Furthermore, attempting to delete that User Group will fail with an error message stating 'The user group cannot be deleted because it is in use by other settings' until it is removed from the Administrator entry.
How to verify the object dependency for a system interface on the CLI:
The main CLI command to identify object dependencies on a given interface within FortiOS is the following:
diagnose sys cmdb refcnt show <path.object.mkey>
The <path.object.mkey> is a combination of the section where an object is stored as well as the primary key used to identify the specific object being searched for. In the following example, the command is used to show all references to a network interface stored under config system interface whose name is wan2:
diagnose sys cmdb refcnt show system.interface.name wan2
entry used by child table members:seq-num '2' of complex system.sdwan:members.interface
entry used by table firewall.sniffer:id '1'
entry used by child table interface:interface-name 'wan2' of complex system.acme:interface.interface-name
In the above example, the system interface 'wan2' has been used for the firewall sniffer, ACME settings, and for SD-WAN setup, which are current object dependencies of this system interface.
Important Note 3: How to locate the 'mkey' attribute for a given object.
As noted above, the above command requires the admin to specify the object they are interested in using a <path.object.mkey> format. While it is easy to identify the path and object fields (for example, config firewall address = firewall.address), it is not as straightforward to identify the particular mkey field used by that object (it is not always 'name').
One useful method for locating the mkey is to use the tree command. The tree command operates similarly to the show command and can be used to locate the mkey for a given config section:
tree system sdwan members
-- [members] --*seq-num (0,512) <------ The * marks the primary key for a given type of object (aka the mkey).
|- interface (15)
|- zone (35)
|- gateway
[...]
In the above example, the path is system.sdwan, the object would be members, and the mkey would be seq-num. With this info, the refcnt command can now be used to locate references to that specific object. In the following example, an admin wants to find all references to SD-WAN member 1 in the configuration (since SD-WAN members are referenced by their ID number in the configuration, not by their interface name):
diagnose sys cmdb refcnt show system.sdwan.members.seq-num 1
entry used in complex system.sdwan:health-check.members.seq-num child table health-check:name 'TEST_172.16.1.101' entry members:seq-num '1' (From VDOM: 'root')
Another useful method is to use the get command, as that can also list the mkey associated with a given object:
get firewall address
== [ all ]
name: all
== [ SSLVPN_TUNNEL_ADDR1 ]
name: SSLVPN_TUNNEL_ADDR1
== [ 10.10.1.4 ]
name: 10.10.1.4
[...]
Example: How to verify an object dependency for a firewall.address.
diagnose sys cmdb refcnt show firewall.address:name all
entry used by child table source-address:name 'all' of complex vpn.ssl.settings:source-address.name
entry used by child table dst:name 'all' of table service:id '1' of complex system.sdwan:service.dst.name
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '10'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '25'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '20'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '2'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '23'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '13'
entry used by child table srcaddr:name 'all' of table firewall.policy:policyid '12'
This output shows that the Address Object 'all' is being used as the source address in several firewall policies.
How to identify a potential object with a dependency:
It is also possible to be even more generic when running this command. To find out the general possible dependencies for a certain object, it is possible to leave the object name empty. This will show the potential objects that could have a dependency:
diagnose sys cmdb refcnt show firewall.address:name
may used by table firewall.addrgrp.member.name
may used by table vpn.ssl.web.portal.widget.ip-pools.name
may used by table vpn.ssl.web.portal.widget.split-tunneling-routing-address.name
may used by table vpn.ssl.settings.tunnel-ip-pools.name
may used by table vpn.ipsec.phase2.src-name
may used by table vpn.ipsec.phase2.dst-name
may used by table vpn.ipsec.phase1-interface.ipv4-split-include
may used by table vpn.ipsec.phase2-interface.src-name
may used by table vpn.ipsec.phase2-interface.dst-name
may used by table firewall.policy.srcaddr.name
may used by table firewall.policy.dstaddr.name
may used by table firewall.interface-policy.srcaddr.name
may used by table firewall.interface-policy.dstaddr.name
may used by table firewall.sniff-interface-policy.srcaddr.name
may used by table firewall.sniff-interface-policy.dstaddr.name
Common Objects to look up:
diagnose sys cmdb refcnt show system.interface.name <interface name> (**1)
diagnose sys cmdb refcnt show firewall.address:name <address name> (**2)
diagnose sys cmdb refcnt show firewall.profile: <profile name>
diagnose sys cmdb refcnt show firewall.service.group:name <servicegroup name>
(**1) <interface name> An interface can be either physical or virtual, including options such as VLANs, switch groups, IPsec tunnels, and 802.3ad links.
(**2) <address name> can be written within single/double or without quotes.
Separator Tags between path.object and mkey:
The refcnt command may use either periods ('.') or colons (':') to separate the <path.object.mkey> elements. For example, the following will all work equally well:
diagnose sys cmdb refcnt show system.interface.name wan1
diagnose sys cmdb refcnt show system.interface:name wan1
diagnose sys cmdb refcnt show system:interface:name wan1
Notably, the output of the command always follows a path.object:mkey format:
entry used in table firewall.policy:policyid '39' entry srcintf:name 'wan1' (From VDOM: 'root')
entry used in table firewall.policy:policyid '4' entry srcintf:name 'wan1' (From VDOM: 'root')
entry used in table firewall.policy:policyid '24' entry dstintf:name 'wan1' (From VDOM: 'root')
Virtual Domains – VDOM:
The above commands may be used in all VDOMs (Global and otherwise).
Related article:
