Questions about one of the NSM FAQ statements
Larry
All-Knowing Sage ✭✭✭✭
In the SW NSM FAQ (https://www.sonicwall.com/support/knowledge-base/sonicwall-network-security-manager-nsm-faq/200803090636870/), one entry reads:
- What will happen when a unit is changed local does NSM pick-up this change?
Yes, it will. The device will become unmanaged in NSM and admin will need to synchronize to bring the new configurations.
Does this mean that if I log directly into a client's TZ600 and make a change, that I'm also going to have to log into NSM and perform an additional function? If so, what function would that be (i.e., synchronize)? What, exactly, does "unmanaged" mean? And what are the implications of an "unmanaged" device? How does that appear in the dashboard? Will there be a one-click synch button? Will an alert be issued to the admin when a local change is made?
Best Answer
-
CORRECT ANSWER
Istvan
Newbie ✭
Hi Larry,
When you acquire GMS/NSM the concept is NOT to manage the units from their own management interfaces but only use GMS/NSM.
Exceptions and accidents happen but it is always the operators' responsibility to review the changes causing the out-of-snyc state and to decide which config is correct and instruct NSM to act accordingly.
I think you can avoid this by limiting the local (on-box) administration group rights.
Please check out the NSM docs online you can see the conflicting config section review screen example:
If you would get such feature automation you should send an RFE to SonicWall but in my opinion this would imply serious risks to the management.
Regards,
István
6
Answers
I'll be honest with you: I have not had the time yet to read the nearly 150 pages of the NSM documentation before I read through the FAQ.
Previously, when working at a client's location it was easy to get to the local IP address of the device, log on, perform the necessary modifications, and log off.
Now, I will have to access the cloud website (and remember my password for that), [at some point in the future confirm that with MFA], click the drop-down to access the client's site, click the NSM function tile, click the Management icon, and THEN get around to performing the necessary modifications, before logging off.
And all of this is predicated on forcing the sale of an additional license to my client so that I can take over cloud management of the device.
It is obvious that - going forward - to use any SonicWall device with NSM will also require an organizational and structural change to over a decade's worth of my SOPs.
I'm trying to understand how this is a good thing....
@Larry , the main advantages of NSM is the ability to do zero touch deployments, use templates, group level management and scheduling of changes. For example, you can pre-define your security settings/objects/DPI-SSL exceptions etc.. and bring up a customer in a fraction of the time you do today and any changes can be pushed to as many firewalls as you want at once. You can also easily update and manage the firmware for each one without doing your current workflow of logging into every unit after looking up documentation.
@MasterRoshi I appreciate that explanation.
I've got lots of reasons for not needing NSM, but I'm not going to air them in a public forum.