GMS best practices when pushing firewall policies to groups

02/02/2022 0 People found this article helpful 52,222 Views

Description

When pushing firewall policies (NAT/Access Rules/Address object/group/etc) within a GMS group to multiple firewalls it is important to note that the firewall zone settings will be modified to match the group zone settings. All zone settings will be modified on that firewall's zone to match the GMS group setting for that zone.

If there are different firewalls that do or do not use certain security services, or SSLVPN, it is important to group those firewalls into their own separate groups.

If not, there is a potential to toggle off or on SSLVPN on the WAN zone when pushing a WAN zone address object to the group.

Resolution

In this example the GMS group settings have SSLVPN enabled and different security services toggled on.

When we look at the first firewall within the group, we can see that SSLVPN is disabled.

As an example, If we create a WAN zone object in the group and push it to this firewall using forward inheritance, it will toggle SSLVPN on within that firewall's WAN zone, to match the other security services settings within the WAN zone.

This is by design and expected behavior.

If you have a deployment that runs different zone settings among different firewalls it requires you to split those into different groups within GMS.

Best Practice Scenario

In this scenario we have one deployment that has SSLVPN disabled and the rest enabled.

The second group has SSLVPN enabled.

With these broken down into two separate groups this ensures pushing address objects to each respective group. They will continue to operate with the same zone settings after the address object push to the firewalls.

For instructions on creating new groups and views click the link below

https://www.sonicwall.com/support/knowledge-base/creating-a-custom-view-in-gms/170502944462349/

Configuration Changes

Before making global or group level configuration changes and firmware upgrades, a GMS administrator should apply the change at a unit level, and then test it with a group node that has two to three firewalls. If both tests lead to expected results without causing any side effects or bringing down management access to the remotely managed units, the GMS administrator can push the changes to a larger group or global level node in GMS.

Related articles below on how to push group settings to multiple firewalls within GMS

https://www.sonicwall.com/support/knowledge-base/how-to-create-an-inheritance-filter/170502333163818/

https://www.sonicwall.com/support/knowledge-base/how-to-use-forward-inheritance/170502594863192/

https://www.sonicwall.com/support/knowledge-base/how-to-use-reverse-inheritance/170502466760286/