If you are running a huge amount 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 could save respective time. For this and with the beginning of firmware release 7.2.2, this can be achieved by setting multiple Control Centers into a master-to-slave relation.
Limitations for Relating Master to Slave CCs
With a Barracuda Control Center, master to slave hierarchies are always in a 1:many relation. This means that there is one dedicated Control Center configured as a master and numerous slave Control Centers that inherit special configurations from the master. This relation is not nestable, which means that a master CC cannot be a slave CC at the same time. However, there may be multiple master CCs at the same time where each master CC manages its own subset of its respective slave CC configurations. Each of such slave CCs can be bound to only one master CC, as illustrated in the following figure:
When configuring a master-to-slave configuration, you must configure the CC by its IP address. If a CC is located inside a private network—which also applies to VPN connections—you 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 master CC to the slave CC. To accept the relation on both sides, you must configure both the master and slave CC IP address with a public key to accept connections from the respective CC.
Master-to-Slave Relations within the Control Center Configuration Tree
Master-to-slave CC relations are displayed only in the Status Map of the master CC:
Synchronizing Control Centers
Synchronizing a master-to-slave CC is achieved by pushing information from preconfigured CC configuration nodes from the master CC to all associated slave CCs. After the master-to-slave relations are set, synchronizing is done automatically in the background if a change is made on a configured node on the master CC. During this process, all nodes on a slave CC receive the configuration from the same node of the master CC. Therefore it is straightforward that nodes on a slave CC are overwritten in case a related master CC propagates a node to its subordinate CCs. To protect a node on a slave 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:
Global Firewall Objects
|Global Firewall Objects already carry information that is shared commonly on managed firewalls.|
|Yes||Firewall Objects in Ranges/Clusters||Firewall Objects in Ranges or Clusters also hold information for grouping purposes.|
|Yes||Repositories||Repositories already concentrate functions of configurations in Control Centers and therefore are well suited for synchronizing.|
|Partly||VPN tunnels||VPN tunnels configurations must be treated special via a VPN hub because they are treated differently on all slave CCs.|
|No||Services||Services are not suited for sharing because a box is always bound to its own Control Center.|