Adding multiple FortiGates to FortiManager with identical objects but different subnets

[Sam_S1]

Hi,

We have a number of FortiGate firewalls which range from SMB 60C (being migrated to 51E) to large 1000D. We have purchased FortiManager and installed version 5.4.3 as it covers most of our firewalls firmware.

I have recently learnt FortiManager can not manages all firewalls which are on different majour and minor release versions and this can only be managed under a single ADOM - is this correct, as I would under the impression FortiManager would provide a single manage plane for all the firewalls?

Around 30% of the configuration on the FortiGates are similar i.e. VPN tunnel to a main FortiGate firewalls. However, the naming convention used to reference these objects is different and in some cases the subnets could be different using identical object naming standards.

My understanding, is if I import the first FortiGate into the FortiManager under the same ADOM it will import the policies and objects within the ADOM database. If I then import the second firewall under the same ADOM, and the objects are named identical but configured with different IP or subnet it will become an issue. This is because FortiManager will replace the object it has within its database from the first firewall import and replace the subnet with the second firewall import. If later down the line, we update the first imported firewall it will change the subnet address on the firewall causing the incorrect subnet to be replace under the object - is this correct? What would be the recommended method on importing these firewalls into FortiManager?

My plan before learning the above was to import the firewalls into FortiManager and then work with making the objects and policies consistent, however, this is going to be impossible unless I check each firewalls for its objects?

Would appreciate any thoughts and advice.

Thanks,

Sam.

[emnoc · Accepted solution]

I have recently learnt FortiManager can not manages all firewalls which are on different majour and minor release versions and this can only be managed under a single ADOM - is this correct, as I would under the impression FortiManager would provide a single manage plane for all the firewalls?

Yes, you need multiple adom

Around 30% of the configuration on the FortiGates are similar i.e. VPN tunnel to a main FortiGate firewalls. However, the naming convention used to reference these objects is different and in some cases the subnets could be different using identical object naming standards.   My understanding, is if I import the first FortiGate into the FortiManager under the same ADOM it will import the policies and objects within the ADOM database. If I then import the second firewall under the same ADOM, and the objects are named identical but configured with different IP or subnet it will become an issue. This is because FortiManager will replace the object it has within its database from the first firewall import and replace the subnet with the second firewall import. If later down the line, we update the first imported firewall it will change the subnet address on the firewall causing the incorrect subnet to be replace under the object - is this correct? What would be the recommended method on importing these firewalls into FortiManager?  

Again, use multi-adoms to get around this or find duplicated objects and rename-them

My plan before learning the above was to import the firewalls into FortiManager and then work with making the objects and policies consistent, however, this is going to be impossible unless I check each firewalls for its objects?  

Some time you have to bite bullet and do the hard-work up front to  have a better solution.

I would  diff and find duplicates across the multiple FGTs

if you stay or want to stay in a  single-adom concept, than standardize on one fortiOSversion

drop all un-used objects

[chall_FTNT]

Sam.S wrote:

My understanding, is if I import the first FortiGate into the FortiManager under the same ADOM it will import the policies and objects within the ADOM database. If I then import the second firewall under the same ADOM, and the objects are named identical but configured with different IP or subnet it will become an issue. This is because FortiManager will replace the object it has within its database from the first firewall import and replace the subnet with the second firewall import. If later down the line, we update the first imported firewall it will change the subnet address on the firewall causing the incorrect subnet to be replace under the object - is this correct? What would be the recommended method on importing these firewalls into FortiManager?

Many objects support dynamic mapping, including firewall address objects. 

In fact, the Import Policy step should automatically enable "Per-Device Mapping" for the relevant objects for you.  (Be sure to save a copy of the Import Policy report so you have a record of the changes made.)

Dynamic mapping allows you to use the same name for those objects but they can map to different IP addresses or subnets.

[Sam_S1]

chall wrote:

Sam.S wrote:

My understanding, is if I import the first FortiGate into the FortiManager under the same ADOM it will import the policies and objects within the ADOM database. If I then import the second firewall under the same ADOM, and the objects are named identical but configured with different IP or subnet it will become an issue. This is because FortiManager will replace the object it has within its database from the first firewall import and replace the subnet with the second firewall import. If later down the line, we update the first imported firewall it will change the subnet address on the firewall causing the incorrect subnet to be replace under the object - is this correct? What would be the recommended method on importing these firewalls into FortiManager?

Many objects support dynamic mapping, including firewall address objects. 

In fact, the Import Policy step should automatically enable "Per-Device Mapping" for the relevant objects for you.  (Be sure to save a copy of the Import Policy report so you have a record of the changes made.)

Dynamic mapping allows you to use the same name for those objects but they can map to different IP addresses or subnets.

Hi Chall,

When you say 'many objects support dynamic mapping' are you referring to the same object can have identical names but with a different IP address of which can be used by different firewalls?

Is the Import Policy Report something which is produced when a firewall is imported or when the policy is imported?

[chall_FTNT]

Dynamic mapping -- 1 object (1 name) but the value for that object can vary for each managed device (FortiGate)

Import Policy Report -- is available after completion of "Import Policy"

[ergotherego]

Dynamic objects can be pretty powerful. And in fact you are already using them - all ADOM interfaces are dynamic objects by default - even if "internal1" maps to "internal1" on every firewall.

Personally I try to use them sparingly, because it be hard for people to remember to adjust the mappings properly.

What we do instead for just regular address objects is create a hierarchical grouping structure like this:

ALL.Citrix-Servers     NYC.Citrix-Servers         10.10.10.0/24     LAX.Citrix-Servers         10.20.20.0/24     DEN.Citrix-Servers         10.30.30.0/24

Then on every firewall where you have Citrix servers you can reference "ALL.Citrix-Servers".

Pros:

> don't have to remember to adjust mappings > easier to create IT/firewall guidelines for support staff - "Use the ALL objects for these things"

> one master object to edit. If you add another Citrix server, just update the site-level group accordingly, FMG will push those changes everywhere

Cons:

> creates objects on firewalls that never get used. Ie, NYC Citrix servers will never exist on LAX firewall

Security concerns:

It doesn't actually create a security risk. URPF will prevent NYC firewall from allowing someone trying to spoof LAX IPs locally - since NYC already has a route for LAX from its VPN (or whatever). And that subnet doesn't live locally, so TCP 3-way handshake won't complete (return routing won't complete) - so at worst you open yourself to UDP syn flooding - which can be prevented in other ways.

And lastly ... the biggest benefit of doing it like above, is eventually every organization is going to need a hub-and-spoke setup - if they grow large enough. And having "super groups" like the above make that sooo much simpler to implement, where your inter-site filtering is done just on the hubs.

[emnoc]

Cons:   > creates objects on firewalls that never get used. Ie, NYC Citrix servers will never exist on LAX firewall  

I have to disagree.

1:  object that don't get use eats resources or limits tables-values.

" granted something like an address object which are  over  2K objects  in most models and version of fortios but is something to consider "

but   service objects or  groups  which are way smaller in value , could be wasted on unused  services.

2: 2nd you have objects that are unused and in fwpolicies that  would raise a flag from a plain security.audit  A true fwpolicy under any security.audit  should be looked at the need for the two traffic_flow

Security concerns:   It doesn't actually create a security risk. URPF will prevent NYC firewall from allowing someone trying to spoof LAX IPs locally - since NYC already has a route for LAX from its VPN (or whatever). And that subnet doesn't live locally, so TCP 3-way handshake won't complete (return routing won't complete) - so at worst you open yourself to UDP syn flooding - which can be prevented in other ways.   And lastly ... the biggest benefit of doing it like above, is eventually every organization is going to need a hub-and-spoke setup - if they grow large enough. And having "super groups" like the above make that sooo much simpler to implement, where your inter-site filtering is done just on the hubs.

And on this one, this is not 100% true.

Take a address or service group that was for inbound traffic  ( from a  untrust internet  ) and you had objects that you really don't need in that address group. You now just blindly  " accept|denied " them from a security observation which might not be the desired effected.

So be cautious when doing what your suggested and making that  statement ;) and be aware of the potential doors you can open or close depending on how you approach it ;)

[ergotherego]

emnoc wrote:
 

1:  object that don't get use eats resources or limits tables-values.

" granted something like an address object which are  over  2K objects  in most models and version of fortios but is something to consider "

but   service objects or  groups  which are way smaller in value , could be wasted on unused  services.

Yep that is the cost of doing it that way. You pay for it one way or the other. Either human-overhead by creating and maintaining dynamic mappings or pay for it with object table usage on your firewalls.

emnoc wrote:
  

2: 2nd you have objects that are unused and in fwpolicies that  would raise a flag from a plain security.audit  A true fwpolicy under any security.audit  should be looked at the need for the two traffic_flow

As mentioned, you would want to update your internal IT/AUP/etc policies and guidelines to account for doing it that way. That is the first hurdle with any compliance audit - "Are you doing things the way you say you do them?". The second of potential security risks associated would also need to be documented in detail in those same policy documents. It would likely require some additional explanation to the auditors and for PCI environments have QSA approval. Depends on the environment and what makes the most sense. But doing it the way above can and does pass audits, I can tell you that much ;)

emnoc wrote:

Take a address or service group that was for inbound traffic  ( from a  untrust internet  ) and you had objects that you really don't need in that address group. You now just blindly  " accept|denied " them from a security observation which might not be the desired effected. 

 

I should've clarified a bit more:

1) I wouldn't recommend doing it that way for service groups, just address groups.

2) I would only do it for internal addresses, not external.

3) And just for internal-to-internal traffic. For things facing out or in, you can make use of the site-specific groups nested in the larger super-group.

As always, it really depends on your environment and what your particular needs and restrictions are :)

[emnoc]

agreed

I've  worked in many  environment that has done exactly this,  and open something up, that was not expected.

In fact most internet  breech are from "inside" or hosts already compromised  { hence inside again } , that I'm even  not  100%  confident in doing the above suggestion under any policy or established as a set practice.

I've seen  everything from  person who mistakenly add a firewall.address with NO subnet or ip-range and open up an un-expected  "ANY"  or set an another condition.

So walk & thread with caution is all of the advice I can give ;)

For PCI_DSS compliance I would suggest reading this article and firewall rule_sets requirement. A auidtor will have a blast at policy that allows for traffic on a just a "ignore this line it really won't work " approach.

https://www.sans.org/reading-room/whitepapers/auditing/methodology-firewall-reviews-pci-compliance-3...

Ken