config status shows conflict in Fortimanager

[NIS]

Hi Team,

We have a fortigate 3200D - v6.0.10 manage via Fortimanager v6.2.8. 

We have noticed the config status as "conflict" in Fortimanager and a popup of "device config out of sync".

Could someone advise what can be done to resolve this issue?

I have attached a screenshot for ref.

[Toshi_Esumi · Accepted solution]

When that happens to our FMG, which happens time to time, we Retrieve Config, then re-apply whatever went out-of-sync because of the retrieval, like CLI template, Policy Package, etc.

And always check "no change" would happen with install preview. <edit> Or, at least any changes that would happen wouldn't impact normal operation, like deleting unused objects.</edit>

We always assume it's a bug.

Toshi

[Debbie_FTNT · Accepted solution]

Hey NIS,

in your case, it looks like the password for the admin 'admin' was changed on FortiGate, which changed it's expire time, but this information was not updated to FortiManager.

If you retrieve the configuration from FortiGate, that should fix the sync issue.

However, the policy package status will be unknown - to fix that, you might have to trigger a poilcy install. This shouldn't cause any further changes on the FortiGate though, it's just to let FortiManager know that FortiGate's policies are still the same as policy package.

-> FortiManager loses this knowledge when a config is retrieved from FortiGate.

[Toshi_Esumi · Accepted solution]

When that happens to our FMG, which happens time to time, we Retrieve Config, then re-apply whatever went out-of-sync because of the retrieval, like CLI template, Policy Package, etc.

And always check "no change" would happen with install preview. <edit> Or, at least any changes that would happen wouldn't impact normal operation, like deleting unused objects.</edit>

We always assume it's a bug.

Toshi

[Debbie_FTNT · Accepted solution]

Hey NIS,

in your case, it looks like the password for the admin 'admin' was changed on FortiGate, which changed it's expire time, but this information was not updated to FortiManager.

If you retrieve the configuration from FortiGate, that should fix the sync issue.

However, the policy package status will be unknown - to fix that, you might have to trigger a poilcy install. This shouldn't cause any further changes on the FortiGate though, it's just to let FortiManager know that FortiGate's policies are still the same as policy package.

-> FortiManager loses this knowledge when a config is retrieved from FortiGate.

[Toshi_Esumi]

Shouldn't "auto-update" happen if the admin password was changed at the device? Instead of showing "conflict"?

Toshi

[Debbie_FTNT · Accepted solution]

Hey Toshi,

this depends on if FortiGate is configured to update the changes to FortiManager or not.

If the FortiGate is supposed to update changes to FortiManager -> yes, status should be auto-update, you are correct.

If the FortiGate is not supposed to update changes to FortiManager automatically -> status would in fact be conflict.

In addition, sometimes for some reason the FortiGate does not perform auto-update even though it should, and in that case the status will also be conflict. It's hard to say what the case was here - but good point!

@NIS If you frequently see the conflict status, it might be worth opening a ticket with Technical Support, because that would indicate changes are happening on FortiGate that FortiGate is not sharing back to FortiManager, and something in the connection between FortiManager and FortiGate might not be quite healthy.

[Kimaru]

Ran into a similar issue after attaching a FortiAnalyzer and used a CLI template + provisioning template to keep the FortiManager in synch. Not sure if this is best practice.