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: 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 (e.g. 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.
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:
diag 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 to this system interface.
Important note: 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 (e.g. 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
diag 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:
diag 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 lookup:
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 articles:
