Prevent local address objects from being overwritten

[rsm]

Hi

We have a Fortigate that is managed by Fortimanager. We want to block the large number of random IPs that are attempting to login to our SSL VPN.

I have created an automation stitch to dynamically create address objects and put these in to an address group, which is then referenced in the local-in policy. The local-in policy is created on Fortimanager because if it was create locally on the Fortigate, it would get overwritten. 

I now have a similar issue with the address objects and group created by the automation stitch. Each time I install policy, it overwrites the group and removes the address objects, since these don't exist on Fortimanager. 

So, is it possible to prevent local address objects from getting overwritten by Fortimanager? If so, how do I do this?

Thanks
Roy

[Jean-Philippe_P]

Hello rsm, 

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible. 

[Jean-Philippe_P]

Hello,

We are still looking for an answer to your question.

We will come back to you ASAP.

[Jean-Philippe_P]

Hi again Roy,

I found this solution. Can you tell us if it helps, please?

To prevent local address objects from being overwritten by FortiManager, you can follow these steps:

1. Reference Objects in Policies: Ensure that the address objects and groups created by the automation stitch are referenced in a policy or rule on FortiManager. FortiManager only installs objects that are referenced in policies. If they are not referenced, they will be removed during the installation process.
   
   

2. Use Per-Device Mapping: Utilize per-device mapping in FortiManager to manage specific configurations for individual FortiGate devices. This allows you to maintain certain configurations locally on the FortiGate without them being overwritten by FortiManager.
   
   

3. Exclude Objects from Synchronization: If possible, configure FortiManager to exclude certain objects from synchronization. This can be done by adjusting the synchronization settings to ignore specific local objects.
   
   

4. Manual Synchronization: After making changes locally on the FortiGate, manually synchronize the configuration with FortiManager to ensure that the local changes are recognized and preserved.
   
   

5. Custom Scripts: Consider using custom scripts or automation to reapply the local configurations after a policy installation from FortiManager.
   
   

By following these steps, you can manage local address objects and prevent them from being overwritten by FortiManager.

[farhanahmed]

Just to add to what Jean-Philippe_P mentioned:

When the automation stitch updates the objects on the FGT directly, that change is autoupdated in FMG device db (Device Manager will show: Auto Update for the FGT in question) at that time you can Import the config to update the addrgrp in ADOM DB, so the next time when you install the policies via FMG it will NOT overwrite the addrgrp.

[Toshi_Esumi]

yea, the problem is the update by automation stitch could happen any moment based on the @rsm's description. So probaly email notification or something needs to be added to the stitch to let somebody know the DB change happened so that a human intervention/manual operation can import the updated objects can be imported to the policy package side.
Can't this part be done by something on the FMG side automatically? If that's possible, that would help many other situations as well.

Toshi

[farhanahmed]

True, email notification can help in this situation.

But - unfortunately - as of now I think there is no mechanism to do auto Import.

A possible solution would be to use API (Postman or Ansible playbook) which will check the status of the Config, if its 'Auto Update' then run the next API request to do the Import. 

- Checkout the attached Postman Collection. Set the required variables (FMG IP, credentials, ADOM name, FGT Name, vdom name) and run the Collection.

- Then I think you can set some sort of auto run timer to run this every few minutes.

The workflow's logic is:

• 1. Retrieve Timestamps: The workflow queries the FMG for two key times, converting both to Unix Timestamps (UTC):

  • Last Task End Time: The completion time of the last successful configuration import.

  • Latest Revision Time: The time the FGT's most recent change was recorded by the FMG.

• 2. Apply Condition: It checks if the Last Task End Time is older than the Latest Revision Time.

  $$\text{Last Task End Time }<\text{Latest Revision Time}$$

• 3. Determine Action:

  • If TRUE: Meaning there is new autoupdate - The workflow proceeds to run the Import Config query.

  • If FALSE: Meaning the import timestamp is after the autoupdate - The workflow stops.

You can take this further: to check if the autoupdate change is only for the address object, only then run the import config query.

[farhanahmed]

+ This type of automation becomes easy if you have FortiSOAR :)