Technical Tip: FortiManager is trying to unset administrative allow access for the VLAN interfaces after firmware upgrade to v7.6.5

When per-device dynamic mapping is configured for VLAN's defined in FortiSwitch Manager -> FortiSwitch VLANs, after a firmware upgrade, the per-device mapping will be blank by default, without having administrative access set, which results in unsetting allowaccess when config is pushed from FortiManager to FortiGate.

Below is an example of an install preview showing FortiManager trying to unset allowaccess for all the VLAN interfaces defined under FortiSwitch Manager -> FortiSwitch VLANs.

config system interface
    edit "LAN-VLAN10"
        unset allowaccess
    next
    edit "LAN-VLAN11"
        unset allowaccess
    next
    edit "LAN-VLAN13"
        unset allowaccess
    next
    edit "LAN-VLAN14"
        unset allowaccess
    next
    edit "LAN-VLAN15"
        unset allowaccess
    next
    edit "LAN-VLAN17"
        unset allowaccess
    next
    edit "LAN-VLAN18"
        unset allowaccess
    next
    edit "WAN-VLAN21"
        unset allowaccess
    next
    edit "LAN-VLAN27"
        unset allowaccess
    next
    edit "LAN-VLAN12"
        unset allowaccess
    next
end

In the 7.2 version, there is no administrative access section in per-device mapping; hence, it uses the values from the parent entry, and after the upgrade to v7.6, the administrative access is present in per-device mapping with blank selection by default. Hence, when pushing config to FortiGates, it will try to unset allowaccess because nothing has been selected in per-device mapping.

Per-device mapping with blank selection for administrative access:

It is difficult to modify the per-device mapping for each VLAN interface when there are a lot of devices, and in this case, the cdb upgrade manual fix command will be useful and easy to fix the issue quickly.

This issue is resolved in 7.4.9, 7.6.5 GA versions, where engineering provided a cdb upgrade manual fix command to let dynamic mappings inherit allowaccess settings from the parent entry:

diagnose cdb manual-fix adom root fspvlan-dyn-ipv4allowaccess.

Parent entry having administrative access selected:

After upgrading to v7.6.5 and facing this problem, it is recommended to run the manual fix command mentioned below for the respective ADOM: 

FMG-VM64 # diagnose cdb manual-fix
adom Manually repair adom configuration database

FMG-VM64 # diagnose cdb manual-fix adom
Input adom name or "Global":

FMG-VM64 # diagnose cdb manual-fix adom 6X-DXX_STATIONS_XXX
cli-templates-path update cli template working path
fw-policy-match-vip Fix firewall policy match-vip after adom upgrades from 7.0 to 7.2
generate-adom-ca Re-generate ADOM CA
fspvlan-dyn-ipv4allowaccess FSP vlan interface dynamic mapping ipv4 allowaccess inherit settings from the parent entry

FMG-VM64 # diagnose cdb manual-fix adom 6X-DXX_STATIONS_XXX fspvlan-dyn-ipv4allowaccess

Changes will be made to the database, however it is recommended to perform a backup first.
Do you want to continue? (y/n)y

Upgrading: FSP vlan interface dynamic mapping ipv4 allowaccess inherit settings from the parent entry

Database upgrade complete.

After running the cdb upgrade manual-fix command, ping, and security fabric is copied from parent entry to per device mapping, and now when the config is pushed from FortiManager to FortiGate, it will not unset allowaccess.