Fortimanager Question

[berukmano]

So I have a 501E and 301E at 2 different sites. I got the FMG well after having these two units in the wild so I was able to import them in hopes of managing them, however I'm hitting a problem after import. The configs at the actual units were changed (objects added, settings tweaked) after being added to FMG. FMG doesn't know about these additional settings so if I ever go to run the Install Wizard, the Install Preview shows that it would delete all of the items created at the units. I guess that makes sense since FMG will only install what it knows about. (The people who edited outside of FMG are to be restricted to the FMG only.)

Question is, how do I ensure that FMG updates what it knows about a unit's objects (addresses, interfaces, etc.) if changes are ever made outside of FMG? In my labs, I've deleted the unit from FMG and re-added it to reflect such changes but I don't know if there'd be any weird side effects that might affect the FGT in a production environment. I'd like to start using FMG going forward but seeing all those "delete xxx" lines the Install Preview makes me hesitate to push the policy package down to the FGT.

Also, I have regular backups of these units - wouldn't I be able to easily restore these configs if the install messed up something? (given I can still access the unit).

[distillednetwork]

If you change policies or objects directly on the fortigate you will need to do a new import on fortimanager before making any other changes. Otherwise fortimanager thinks those changes should not be there since it is supposed to be the source of truth. 

it’s best practice to do all configuration on Fortimanager once it’s setup. 

[Toshi_Esumi]

not necessarily "all configuration". Unless you define some lower level config like port speed/duplex in a CLI template and sync it with the device, it's more practical to change like speed/duplex settings directly at the device while troubleshooting it on-site with a tech or a circuit vendor. Then once got troubleshot, all you need is to retrieve the config (if it doesn't do automatically) then resync/push other higher/logical level of config like the policy package and all templates.

So the key is to be aware what part of config is regulated by the policy package (policies and objects) and templates. For those parts, you need to change, or clone&modify to create a new one, at the FMG then push them to devices. Especially when you use a common policy package or templates for multiple devices because most of the config is the same among them.

Toshi

[sw2090]

yep device config can be retrieved from the FGT.

Policy package can only be reimported. 

If you use one policy package for all (like we do here) reimport doesn't make sense. In this case you will have to configure the additions in FMG to prevent it from deleting the objects.

[Debbie_FTNT]

To condense the excellent advice above a bit:

The way to get changes made on FGT into FMG is a two-step process, consisting of retrieving the configuration, and then importing the policy:

https://docs.fortinet.com/document/fortimanager/7.2.2/administration-guide/556889/retrieve-configura...
https://docs.fortinet.com/document/fortimanager/7.2.2/administration-guide/337348/importing-policies...
Retrieving the config gets all changes made on FortiGate into FMG Device Manager, and importing policy gets all policy/object changes from Device Manager into the ADOM database.

-> system setting changes (interface stuff, local admin stuff, etc) are not part of the Policy Package; those changes can be synced with just a config retrieve (if FGT does not update changes automatically to FMG, which it should by default after the admin logged out on FGT)

-> policy (or related object) changes would also be synced to the Device Manager component automatically or via config retrieve, but any install from a policy package will overwrite them

Please be aware, if you have not pushed ANY installation from FortiManager as yet: The first installation will contain a lot of deletions, as FortiManager removes any objects (addresses, users, groups, services...) that are unused, that is, not relevant to any policy or other configuration directly or indirectly.