Sophos Firewall: v18.5 MR2: Feedback and experiences

Thank you for the detailed explanation. I would expect that Sophos has some way of measuring the error messages on their servers, because most of the error I see are from Sophos update servers a number of times a day.

Ian

Agreed. It's not super-common, but I see such errors regularly for Intercept X updates from Sophos servers. It may happen with other servers, but I don't remember seeing it. I guess it stands out in my mind because I'm worried that some piece of Intercept X might not be updated when it was supposed to be.

The specific change you mention was a result of a security review we carried out on the OTP functionality. It is not good practice to provide methods to recover existing secrets because this makes it much easier to create cloned tokens that could be used without the knowledge of the original user to gain access to their account. Recovering OTP on an account by deleting the existing secret and creating a new one is more secure because even if it is done by the wrong person, the original user will realize the error the next time they try and log in using their old token.

You see the same behaviour in most websites that offer OTP options like this - the only way to recover if you lose your OTP is to re-initialize with a new secret.

Your point about including more specifics about this in the release notes is valid. We try to keep the release notes brief so that customers can read them all quickly and identify areas that may concern them where they can dig in to documentation to find out more. Sometimes we make them too brief. We'll take your feedback into account.

[I updated my original post because I mistakenly thought I was reading the v19 EAP1 forum. Apologies for any confusion.]

That's a high quality answer. Thanks for taking your time!

Anyone running into issues with the hardware bricking when first rebooting after install or booting after shutdown/startup? This is the same for me for MR1 and MR2 for Intel Hardware (Qotom Q190G4, 8GB RAM, 256 GB SSD).  Made sure that it boots up using Legacy BIOS.  When attempting to reboot after install, it just hangs (for the latest install, letting it sit for a while to see if anything happens). For the second instance after tailing syslog.log I notice that the USB devices are disconnected by the kernel (something similar to this).  After some searching, I tried setting 'usbcore.autosuspend=-1' to mitigate the issue in Grub (i.e., `set cmdline_linux_default="quiet splash usbcore.autosuspend=-1"`, after which I ran `save_envcmdline_linux_default`, then booted again).  This time, the USB issues were gone, but still hung.  Not able to access the GUi with this happening.

For both instances, I notice there is no hard drive activity.  I've had no issues with v18.0 before (installed on two of the same mini computer model above, 4 GB RAM for those). Need this to replace the box I want to use for HA setup.  Any help will be much appreciated!

I didn’t face the exact same issue. But disabling serial port and audio in BIOS resolved some other issues for me.

How does one actually know if the GCM suite is being used for the IPSEC connections? I don't see any options to enable it in the IPSEC policies.

Run this on Advanced shell

ipsec statusall | grep GCM

Meaning the firewall will automatically determine if the GCM suite is needed or not? what  is the default behaviour?

You have to specify GCM chiper in a custom ipsec profile