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 37325 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
  • 0 in reply to LHerzog

    has it just become GA? a XG106 is showing it as available since 2022.01.18 11:28 CET

    just wondering because 2 hours earlier I've been told on the phone that it is not GA right now also because of the Heartbeat issue in combination with Sophos Central.

  • 0 in reply to LHerzog

    The Heartbeat issue is documented in Release notes and on the release page. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

    our specific(?) issue isn't listed there. DNS and Central Communication was working but Central supposedly did not trigger the Certificate renewal to the client. But we don't need to discuss that once again. GES is still analyzing this in our case.

  • 0

    After upgrade due to replacement unit a recreate the HA between two XG310 (active passive), network is dead and lot of devices lost communication.

  • 0 in reply to rfcat_vk

    Hi,

    On Sunday, January 16, the CPU load was reduced to "standard" values from 18.5 MR1. Any patch was applied?

  • 0 in reply to martinis_01

    The same issue here with SFOS 18.5.2 MR2-Build380 on XG115w Rev. 3. I have to roll back to MR1 :(

  • 0

    After upgrade from 18.5.1 MR-1-Build318 to 18.5.2 MR2-Build380 on XG115w Rev. 3 all interfaces are down (lights off). I have to roll back MR1 version :(

  • 0 in reply to RainMan730

    Absolutely the same for my xg86w, had to rollback to 18.5 MR1 by using putty and serial connection.

  • 0

    This update ran fine on all of my clients except 1.  I had one with a XG115w update from 18.5.1 to 18.5.2.  It looked fine aside from one of their wireless SSID's stopped allowing connections.  The guest Wi-Fi seemed fine, but the corporate Wi-Fi wouldn't do anything with a connected client.  The client connects, doesn't get an IP and can't do anything with the connection.  Rolling back to MR1 resolved the issue for now.  They don't use any AP's and WiFi is handled using the built in radios.  Super odd.

  • 0 in reply to Laxmikant Agarwal

    Thanks! One suggestion when communicating with customers: could you please say "provide access via Diagnostics > Support Access"? This makes it clear that it's a safe, limited, one-button-click ON/OFF option. I had a run-around with an engineer on a call who kept saying they'd need access to the system but I would not have to provide a password.

    Those of us who have not dealt with Sophos support asking for access probably don't remember the switch, and we're thinking providing logins, passwords, making login available from the WAN, and all kinds of painful thoughts. So specifying the method up front would avoid the shock (and defensiveness) of thinking we're being asked to provide WAN-accessible accounts/logins/passwords.

    Appreciate your help, and not trying to criticize. Actually, just wanting to make your life a bit easier.