It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda CloudGen Firewall

This Firmware Version Is End-Of-Support

Documentation for this product is no longer updated. Please see End-of-Support for CloudGen Firewall Firmware for further information on our EoS policy.

Control Centers in Parent-to-Child Relation

  • Last updated on

If you are running a large number of Barracuda Control Centers to manage an even greater number of firewalls, processing equal tasks on all Control Centers can become very time consuming. In cases like this, harmonizing such similar tasks into a single and centralized task can save time. Starting with firmware release 7.2.2, you can do so by setting multiple Control Centers into a parent-to-child relation.

Limitations for Relating Parent-to-Child CCs

With a Barracuda Control Center, parent-to-child hierarchies are always in a 1:many relation. This means that there is one dedicated Control Center configured as a parent and numerous child Control Centers that inherit special configurations from the parent. This relation is not nestable: a parent CC cannot be a child CC at the same time. However, there may be multiple parent CCs at the same time where each parent CC manages its own subset of its respective child CC configurations. Every such child CC can be bound to only one parent CC, as illustrated in the following figure:

cc_conf_topo.png

Configurational Concepts

When configuring a parent-to-child configuration, you must configure the CC by its IP address. If a CC is located inside a private network—which also applies to VPN connectionsyou must configure the private IP address. If a CC is located behind a border firewall, you must configure the public IP address of the border firewall and create an access rule to forward traffic for port 810 UDP from the parent CC to the child CC. To accept the relation on both sides, you must configure both the parent and child CC IP address with a public key to accept connections from the respective CC.

For proper communication between the parent and child CC, a firewall rule must be created on the child CC. This firewall rule must allow traffic from the parent CC to the child CC on the ports UDP 801 and TCP 809.

Parent-to-Child Relations within the Control Center Configuration Tree

Parent-to-child CC relations are displayed only in the Status Map of the parent CC:

status_map_master_CC.png

Synchronizing Control Centers

Synchronizing a parent-to-child CC is achieved by pushing information from preconfigured CC configuration nodes from the parent CC to all associated child CCs. After the parent-to-child relations are set, synchronizing is done automatically in the background if a change is made on a configured node on the parent CC. During this process, all nodes on a child CC receive the configuration from the same node of the parent CC. Therefore, nodes on a child CC are overwritten in case a related parent CC propagates a node to its subordinate CCs. To protect a node on a child CC from overwriting, the node must be locked via Firewall Admin.

Synchronization should only be done for node types that hold shareable information. The following table gives an overview of which nodes are recommended for synchronizing:

Recommended
Node Type
Comment
Yes

Global Firewall Objects

Global Firewall Objects already carry information that is shared commonly on managed firewalls.
Yes Firewall Objects in Ranges/ClustersFirewall Objects in ranges or clusters also hold information for grouping purposes.
Yes RepositoriesRepositories already concentrate functions of configurations in Control Centers and therefore are well suited for synchronizing.
Partly VPN TunnelsVPN tunnels configurations must be treated specially via a VPN hub because they are treated differently on all child CCs.
No ServicesServices are not suited for sharing because a box is always bound to its own Control Center.
 
Node types not listed here should be treated with caution and are subject to your own risk.