Update: V21.0 supports Lets Encrypt onboard:  Sophos Firewall v21 Early Access Announcement  

FINALLY!!!!!!

Now we need the time server back....

What kind of use case would you resolve with an NTP Server in SFOS? 

Just wondering, as i am implementing everything with a simple NAT rule and no changes are required in the deployments. 

There are certain devices I don't want to get out to the internet for any reason (think chinese cameras).  But they need to be sync'd to the same time source for chain of custody reasons. 
I'm currently running a separate time server but I'd rather have it on the FW like the old UTM.
Unless someone can sight a best practice to the contrary?

It is fw job to allow chinese camera only to have access to external ntp source. Less roles is more secure.

Hi,

Sorry, but before you introduce NTP you should first implement the mail functions for quarantine properly.

I can't understand at all how you can't simply send quarantine reports like other manufacturers when a mail ends up in quarantine. This is only possible if the person also has an account. This may work with 5 people but not with 50 or 100 who are not automatically loaded via AD by SFOS.

In the UTM this was simply even automatic, now you need everything extra at SFOS via account for collective mailbox group mail addresses.

Did you had a chance to look into Central Email, which brings all those features (plus additional features as well)? 

UTM customers nowadays are advised to migrate to CEMA (Central Email) instead of using the Email Protection of the firewall.

Email Protection works pretty well I must admit. But its kind of annoying for my team to find reasons for undelivered mail as it is only visible as a tooltip. The use of rbl is very effective and made reports almost obsolet. 

Glad LE finally made it to SFOS. 

Still missing sophos otp for webserver protection though. :(

You could just say, our MTA implementation is crap - and we don't have plans to fix that -> use the cloud product instead.
or move on to solutions that don't get crippled by their successor products.

Currently, all of my customers, when they get to choose between UTM and CEMA, they would go with CEMA all the way, as it is the full fetched email product, coming from the Sophos Email Appliance, which was always the primary Email product of Sophos. 

Nowadays, as Sophos split up the email subscription into an own subscription, everybody can decide what to do with their email product and you are not locked into a bundle. 

The promos of Sophos also include CEMA and not Email on the Firewall. 

The Email protection of Sophos works as it is - and it does it job of scanning and filtering emails. Bugs are getting addressed and fixed as well.

If a customer has certain requirements, you can always interact with Sophos or the Sophos partner to validate the options like moving to CEMA or interacting with another product. 

The only reason not to have an internal NTP server is if you have no internal devices.

Yes, NTP traffic might seem like just bytes moving in and out, but there are significant concerns with exposing this traffic to the internet. NTP traffic is not encrypted, meaning it’s visible to every node it passes through. This not only adds unnecessary latency and traffic on WAN interfaces and routers but also presents a substantial security risk.

Relying on external NTP servers means your time synchronization is vulnerable to man-in-the-middle attacks. Attackers could intercept and manipulate the time data, potentially causing significant disruptions, especially in environments where precise timing is crucial. This vulnerability could impact time-sensitive applications, mismatching log-times are only the start of problems...

It’s puzzling, to say the least, that a security provider like Sophos would suggest its customers expose their devices to third-party NTP servers for something as fundamental as time synchronization. The fact that Sophos collects telemetry from sophos.pool.ntp.org only highlights the irony...

The real issue here is that Sophos had a very good UTM product - one with great usability and a comprehensive feature set. But you chose to abandon it in favor of a new product that is inferior in many ways. XGS suffers from poor usability and manageability (SUM vs SFM or Central anyone?), and many expected features, like an internal NTP server, are simply missing - or only get added after years and customer complaints, hints why we're in this very forum thread.

And to add insult to injury, your sales team still claims the new product is “better in every way”, "easy to move over" (by manually building a new config/ruleset), or my personal favorite from 2018, “full feature parity by the end of the year.”
Why not just be honest? Admit that you don’t want to implement certain features or that (allegedly) you lack the budget or manpower to do so. Stop tiptoeing around the obvious - just be upfront. 

You could simply say, “Yes, that was a great feature in UTM, but we have no plans to bring it to Cyberoam, Sophos Firewall, XG, XGS. Either expose your NTP traffic to the internet with a NAT rule (which, as a SECURITY PROVIDER, we do not recommend), or implement your own NTP solution.”

If your equipment requires millisecond-accurate time, you likely already have the necessary hardware in place. For everyone else, running a GPS NTP appliance or something like Docker-NTP in a container would at least keep the traffic off the WAN.

Finally, consider the compliance implications. Many regulatory standards and industry best practices recommend or even require internal time synchronization services to maintain accurate logs and prevent tampering. By not providing an internal NTP server, Sophos might be inadvertently pushing customers to adopt practices that could lead to non-compliance, potentially opening them up to fines or penalties.

might be a bit off-topic to continue with MTA in this topic...

but moving to a cloud-based mail security solution when your emails are already in the cloud (e.g., EXO) makes (some) sense. However, relying on a cloud service to filter emails when you intentionally keep your mail servers on-premises to avoid data being on 'someone else's computer' (aka the cloud) is not just ironic—it's counterproductive and undermines the very reason for keeping things in-house. I'll keep the discussion about the Central Mail Product off this Thread. 

might be a bit off-topic to continue with MTA in this topic...

but moving to a cloud-based mail security solution when your emails are already in the cloud (e.g., EXO) makes (some) sense. However, relying on a cloud service to filter emails when you intentionally keep your mail servers on-premises to avoid data being on 'someone else's computer' (aka the cloud) is not just ironic—it's counterproductive and undermines the very reason for keeping things in-house. I'll keep the discussion about the Central Mail Product off this Thread.