Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Subscribers 3 subscribers
  • Views 3589 views
  • Users 0 members are here
Options
Suggested

Do not change the configuration locally

bot

Hi there

 I have a few basic questions and how this feature is planned.

 

I have added the firewalls to a new group. Now the following message appears:

> The firewall is managed through Sophos Central. Do not change the configuration locally. It may result in a conflict.

 

Is it the idea that once the firewall has been added to a group, it can only be managed via Central?

 

 

We recently installed a firewall with SFOS v18.
Background:
The customer has a lot of firewalls (50+) and also a lot of objects.

We asked ourselves the following question.
- If we now create objects on the firewall, can we import them later on Central?
- If we start with Central right away, wouldn't we have to duplicate the work for later firewalls?
- If we later add the firewall to a group and distribute objects, are there duplicate objects or can't we overwrite them?

 How exactly does this new feature work with existing firewalls and their configuration and objects (e.g. host, networks, services)?

 

thanks

Bot

Parents
  • +1

    The wording of the message will be toned down a bit, but it's intent is to warn admins that there are risks to changing config locally, that was originally pushed from Central. once configuration has been pushed from Central, Central can't yet verify that the config it expects to be there, is still present at a later time. If you push an object from Central, then later change it locally, then later still, update config from Central that uses that changed object, what do you expect the end result to be? Today, one of two things will happen. 1) the local object will be overwritten with the values from central, or 2) in some edge cases, the config will fail to update fully, and the device will show a sync error, till the discrepancy is resolved, or the error is skipped.

     

    In future, objects pushed from Central will be locked, so they can't be overridden locally, but until then, making changes locally should be done with some caution.  

  • 0 in reply to AlanT

    Then everything is perfect. It was not quite clear that the message only referred to the change of the Central objects.

    Actually I think it makes sense that if you create an object on Central that already exists on the firewall, it will be replaced.
    After that the object should be blocked, so that it can't be changed on the firewall.
    So there are no duplicate items and you can only make changes via Central.

    If Central should not work, you still have the possibility to create a firewall rule or object manually in an emergency and is not dependent on Central.

     

    Objects can be easily blocked. What about settings that you make via Central. Will they then no longer be changeable locally?

  • 0 in reply to bot

    This will be the same as within XG itself. For example, if I create a host group with a name 'xyz' then try to create a host with the name 'xyz' it will fail. Or if I create a service object, and reference it in a NAT rule, then later try to edit that object and change the number of ports it references, it will be blocked. The complication is that if you're making a change from Central, it's not as easy to check that collisions or conflicts haven't been done on an individual firewall. The sync errors you see in Central should make it easier to find any such conflicts, and decide if it's safe to ignore the errors or not. 

Reply
  • 0 in reply to bot

    This will be the same as within XG itself. For example, if I create a host group with a name 'xyz' then try to create a host with the name 'xyz' it will fail. Or if I create a service object, and reference it in a NAT rule, then later try to edit that object and change the number of ports it references, it will be blocked. The complication is that if you're making a change from Central, it's not as easy to check that collisions or conflicts haven't been done on an individual firewall. The sync errors you see in Central should make it easier to find any such conflicts, and decide if it's safe to ignore the errors or not. 

Children
Unfiltered HTML