Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Unwanted Parenting - Why does SOPHOS insist on removing features "for our own good"?

SOPHOS markets their XGS product to network administrators, who are professionals in their field. These are expensive devices that owned by the customer, and should be up to the customer how they wish to deploy\configure\use them. 

SOPHOS, however, is intent on "Parenting" their network administrator customers. SOPHOS is removing another feature that some admins are using because I guess SOPHOS "knows better". We've been using the new XGS Firewalls for a few months and this is the second time I've seen this behavior.

While SOPHOS is busy removing functionality and features from their Firewalls to "Parent" their customers who don't need parenting, other functionality is direly needed, however that does not appear to be the focus.

Why don't we work on improving the MANY missing features that XGS needs, before we start making the product less flexible.


This thread was automatically locked due to age.
  • Hello  ,

    Thank you for reaching out to the community, and thank you for the feedback, But for secure access, we recommend one of the following:

    • Add a local service ACL exception rule that only allows access from specific IP addresses and networks.
    • Use Sophos Central.

    Thanks & Regards,

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case

    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • Confirms our choice once more (after the mail thing) not to move to XG.

    Vendor offered us a "free" service to convert the configs to XG (every second word was "central") - we thankfully declined.

    We'll stick to UTM as long as possible and then move on.

  • Recommendations are great. Suggestions are also great. SOPHOS should recommend things, that's a good thing. But SOPHOS is not recommending something here. SOPHOS is deleting a function\option, simply because they don't trust the users of their products to understand the implications of using one option over another. Those that do understand the implications and wish to use this function\option, now must go and re-configure their firewall(s). This costs time to the administrator, time that has a cost, and time that SOPHOS has decided to take from those admins. 

    SOPHOS Spending the time disabling options that some admins may want to use, while there are MANY other interface issues that make the firewall frustrating to deal with is such a waste of time and effort. You should have seen the list of bug fixes on the last firmware update. 

    SOPHOS needs to focus on making the product better, smoother, more functional, cleaner to use, and correct the errors.


    In one place(see below) it says KBits, which should be Kbits. In reality KB = Kilobyte, Kb = Kilobit.

    In another place(see below) it says MB and KB only. So are these Kilobits and Megabits, or Kilobytes and Megabytes? In reality, MB = Megabyte, and KB = Kilobyte, but SOPHOS uses KB in the KBits abbreviation elsewhere, so who knows. It's unusual to have a chart that is actually in Megabytes, because ISPs don't list their internet that way, so then you always are doing math to figure out where you are at.

    Poor interface design... but don't focus on that. Focus on stripping more functions out of the firewall. I can't understand why the focus is on things that will frustrate your admins, rather than provide them with more creature comforts to make admins happier. 

  • Just look at the known issues list of some Central services… No thanks, I do not want any „cool“ central cloud (if it works) features. Don‘t know why Sophos is pushing central so hard (I guess money). If central would be a MUST for essential services, I would not be a customer of Sophos now ;-)

    If Sophos is disabling the users after 30 days inactivity it is no problem, but there are 2 ways to do:

    The „we don‘t care about customers and know all better“ way -> Disabling it and mention it in some release notes.

    The „we care about customers and they will know what they need“ way -> Implement a simple checkbox to disabled it (or not).

    [bearbeitet von: Quallensaft um 5:45 PM (GMT -7) am 22 Aug 2023]
  • "The „we care about customers and they will know what they need“ way -> Implement a simple checkbox to disabled it (or not)."

    That is what their focus should be yes. 

  • One thing is for certain, this is not a decision Sophos should be making on the partners behalf. There is a long history of this happening though it doesnt come as a suprise.

    Why remove SSL VPN client when the Sophos Connect client is far from full featured?

    Whats next? Sophos doesnt like NAT any more so that gets deleted? Why not work on website filtering that actually works?

    Its going to be something to behold when Sophos Central needs an update and no one can access firewalls.

  • The Focus is Security. This is a low hanging fruit and increase the security best practice for a lot of customers. 

    Exposing WAN HTTPS/SSH for no reason is an real security concern. 

    You can workaround this by using the CLI switch:

    What are the use cases for using WAN HTTPS ANY? 

    Or lets rephrase it: Why would you leave your door open if there is nobody using it? The Mechanism checks for successful logins, if there are some, it will be untouched. 

    If you are not using the door for 60Days, it will be disabled per default, increasing the security of a product by a lot. So if you want to use the HTTPS ANY policy, nothing will change for you.

    If you get this alert by the firewall, it means, nobody used it for 30 days - Maybe it is time to "shut it down". 

    See Shodan, how many firewalls are available on Port4444 for "no reason". 
    You can put your reason into the reason to enable WAN HTTPS - But essentially there are better ways to build this access (VPN, Central, ZTNA, ACL). 


  • We don't allow SSH access at all and we have added the ACL for https to most units. Some we will surely not get to and get locked out for numerous reasons.

    That said that is not the point. We should not have to buy yet another product to administer firewalls and this is not a decision for anyone at Sophos to make. This is a decision of the partner and the business owners to make.

    I'm sure the user portal will be next and then what? There is an assumption that we have a VPN access to every firewall sold? Sophos thinks in terms of selling 5 firewalls and the burden it creates. The reality for someone thats sells 1000 units is far far away from that reality.

    Outside of all this Sophos Central has a lot to be desired before that can be touted as the answer.

    I know you have your Sophos underwear on I get that, but there is no way this type of decision should be made by any firewall manufacturer. 

  • So lets unfold your statements here: 

    You have firewalls installed for your customers with HTTPS Access set to ANY. 
    Are they in active use - So people are accessing those Webadmins via this ANY object? Then nothing will change. Every successful access will reset the clock for another 60 Days. 

    You dont have to buy another product for this purpose - Central is free. VPN is free. ACL are free. Only ZTNA, in case you want to use it there. There are people doing it right now - just wanted to add it to the list. 

    The Assumption is not to have a VPN to every firewall - Instead to add the firewall to Central, if you want to manage it. Central Partner Dashboard gives you the option to administrate and login via SSO to the firewall. Just in case you need access for what ever reason to your customer firewalls. 
    If you dont want to do that, an ACL would be a good place to start to limit the access. 
    Your current partner setup is to sell Customer Firewalls and open WAN to ANY for HTTPS? Do you not think, this might be an situation to talk about? 

    I talked to a lot of German Partners in the recent Days/weeks about this changes. Most of them not even concerned about this. What you could do: Build a Import/Export file for an ACL with Internetv4 and HTTPS Enabled. You can upload it to all firewalls and nothing will change. But i would strongly advise not to follow up on such a call. 


  • I am with you but in my eyes another long wanted feature should have been implemented side by side with it to make it much easier for all of us: FQDN for ACL...