We have about 100 address objects we need to create (this is a recurring thing) and I'm trying to figure out how to do this quickly in bulk.
Now, I know how to bulk-create objects directly in the firewall. I have a script that will spit out text that I can paste into the CLI in the 'Gate that looks like this...
config firewall address
edit 1.1.1.1
set subnet 1.1.1.1 255.255.255.255
next
edit 2.2.2.2
set subnet 2.2.2.2 255.255.255.255
next
edit 3.3.3.3
set subnet 3.3.3.3 255.255.255.255
next
end
That will create three objects the IP address as the object name in my firewall.
What I'm having an issue with is then getting the FortiManager to pull those objects down, and any address groups I've added them to, from the firewall into FMG. I thought the way to do this was to retrieve config but that's not working. The objects never appear in FMG and when I sync it with the Fortigate again, it overwrites what's on the firewall, removing the objects I just created.
So I need to figure out how to either pull these down properly from the firewall or I need to bulk create these in the FortiManager (preferable) and add them to the appropriate groups, then push the config out to all the 'Gates. Anyone know how to do this?
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
First, when you directly configure an FMG managed FGT, it generally trigger "auto retrieve" unless you changed the ADOM setting not to. Then the device config DB increment the revision by one. Did you check the particular config revision that includes what you configured on the FGT? Then if you manually "retrieve" after that, it would increment one more revision although no functional difference from the previous one. If you have a policy package applied to the device, the status of the policy packet would go to "?" and you need to re-install it.
CLI scripts are basically exactly same as scrips you would run on any FGT, unless you're using "dynamic objects" within policy packages. Then the CLI script can be run against either 1) directly at the device, 2) the device DB or 3) policy packages.
So it's totally depending on if you're applying a policy packet to the FGT or not, but can be done in either case with a CLI scrip. Actually that's how I built one of our customers' policy package 100% by CLI scripts.
toshiesumi wrote:First, when you directly configure an FMG managed FGT, it generally trigger "auto retrieve" unless you changed the ADOM setting not to. Then the device config DB increment the revision by one. Did you check the particular config revision that includes what you configured on the FGT? Then if you manually "retrieve" after that, it would increment one more revision although no functional difference from the previous one. If you have a policy package applied to the device, the status of the policy packet would go to "?" and you need to re-install it.
CLI scripts are basically exactly same as scrips you would run on any FGT, unless you're using "dynamic objects" within policy packages. Then the CLI script can be run against either 1) directly at the device, 2) the device DB or 3) policy packages.
So it's totally depending on if you're applying a policy packet to the FGT or not, but can be done in either case with a CLI scrip. Actually that's how I built one of our customers' policy package 100% by CLI scripts.
I'm not sure I understood what you're saying. I added the objects via CLI on the FGT. Then I waited and went to the FGM and saw that the revisions incremented. I selected the auto retreive one and looked at the differences and the new address objects showed up as the only differences. Then I retrieved that config to the FGM. But none of the new address objects show up in the FGM.
Why do you need to retrieve again after you saw it's already in the revision at FMG? You should be able to see those new addresses in GUI under CLI only object, which is not "CLI only", as well.
You don't sound like you're using a policy package (Policy & Objects section) to have one set of policies for multiple FGTs. Then you can use CLI script and run it against device DB to do the same. But since you already configured the addresses on the FGT side, I would suggest removing the current FGT entry at FMG and start over registering it to the FMG.
toshiesumi wrote:Why do you need to retrieve again after you saw it's already in the revision at FMG? You should be able to see those new addresses in GUI under CLI only object, which is not "CLI only", as well.
You don't sound like you're using a policy package (Policy & Objects section) to have one set of policies for multiple FGTs. Then you can use CLI script and run it against device DB to do the same. But since you already configured the addresses on the FGT side, I would suggest removing the current FGT entry at FMG and start over registering it to the FMG.
That's just it - I wasn't seeing the new addresses. I ended up using "Import policy" to get the address objects pulled into the FGM and that worked.
You need to understand the DB model of the FMG although no good documentation with diagram available from FTNT. The device DB is basically the mirror image of the entire FGT configuration. Policy&object DB is separated and you can decide not to use it if you don't have multiple FGTs that have common policies among them. To create the first set of policies, you can either import them from the device DB, or create them from scratch using either GUI or CLI scripts.
When you install a set of "policy&object" so called policy package, the FMG populates the policy package to the device DB first, then after that actually installs the device DB config to the FGT.
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1663 | |
1077 | |
752 | |
446 | |
220 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.