Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 181 replies
  • Answers 1 answer
  • Subscribers 76 subscribers
  • Views 37250 views
  • Users 0 members are here
Options
Suggested
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

Sophos Firewall: v18.5 MR2: Feedback and experiences

LuCar Toni

https://community.sophos.com/sophos-xg-firewall/b/blog/posts/sophos-firewall-v18-5-mr2-is-now-available

Release Notes: https://docs.sophos.com/releasenotes/output/en-us/nsg/sf_185_rn.html

"Old" V18.5 MR1 Thread: https://community.sophos.com/sophos-xg-firewall/f/discussions/128960/sophos-firewall-v18-5-mr1-feedback-and-experiences/

"Old" V18.0 MR5 Thread: https://community.sophos.com/sophos-xg-firewall/f/discussions/127053/xg-firewall-v18-mr-5-feedback-and-experiences

Please review: https://support.sophos.com/support/s/article/KB-000043489?language=en_US



Prio
[gesperrt von: LuCar Toni um 8:07 AM (GMT -7) am 26 Mar 2022]

Top Replies

  • in reply to StevenSultana +6

    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.]

    Jump to answer
Parents
  • 0

    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!

Reply
  • 0

    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!

Children
  • 0 in reply to jamonlee

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

  • 0 in reply to siuswat

    Thanks siuswat, I ended up sending the Qotom machine back (2nd time) and just got a Vnopn machine, which works without a hitch.  I did notice that the BIOS was more up to date on this one compared to the Qotom and for the Qotom, it was impossible to grab the latest BIOS to apply (any search would lead to dead links to the latest BIOS).  Finally ready to start getting this going.