GMS best practices when pushing firewall policies to groups

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.

Image


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

Image


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.

Image


The second group has SSLVPN enabled.

Image


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/



Related Articles

  • Analytics On-Prem vs NSM Feature Matrix
    Read More
  • Analytics On-Prem End of Life and NSM Transition FAQ
    Read More
  • NSM On-Prem: Backups over SCP to Windows OpenSSH Server
    Read More
not finding your answers?