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 37327 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

    We have report a bug with the release-link in the Quarantine Digest Mails.

    The port in the release-link is the port of the admin-interface and this is wrong. the link is for the endpoint-user and he can not open.

    this issue is not fixed in this new release SFOS 18.5.2 MR-2-Build380! still the same.

    In the Sophos XG management under "admin and user settings" the port for admin-portal is 4444 the port for user-portal is 443 and the link in the Quarantined Emails is like that:

    https://gateway.company.com:4444/webconsole/Controller?mode=458&release=aGR...

    this is wrong!

    we have all the time to delete all after the fqdn :4444/webconsole/Controller?mode=458&......

    only then the user can login in the userportal... whats wrong here?

  • 0 in reply to AussieTom

    I experienced the same problem after upgrading my XGS116W, and also had to use putty and a serial connection to revert back to 18.5 MR1.

  • 0 in reply to Frederick Clausen

    Hi folks,

    how long did you wait before rolling back? My XG115W took about 20 minute or sos before it came back online.

    Ian

    XG115W - v19.5.1 mr-1 - Home

    If a post solves your question please use the 'Verify Answer' button.

  • 0 in reply to rfcat_vk

    I waited over 8 hours before I started the roll back process.

  • 0

    Hi,

    In XG-450 (HA), in the authentication/users section in the user list, the status column has disappeared. I don't know if this is when they are in HA or in the XG-450 model.

  • 0 in reply to LuCar Toni

    who may face this issue after upgrade and find this information in this terribly long thread here, refer to the case# mentioned earlier and this NC-83739 when contacting Sophos Support. From what I know, by today (Feb. 3rd) the issue is not 100% identified but has something to do more with Central than the XG. Central should inform/push new certificates to the endpoints but this process may take hours or days which is - of course - a little bit unacceptable.

  • 0 in reply to rfcat_vk

    I have waited 24 Hours and had to go onsite in order to roll back previous version via console.

  • 0

    Hi all, 

    we need to plan an update from18.0 MR 4 to 18.5 MR2 or later to 19.0  depending if some of the known issues are fixed before. Any how we run a XG in Active/Passive mode. We are not allowed to have bigger impact then a session reconnect for those apps which are not willing to move properly. As i treat this whole update as an "OS change" i expect stuff break  but i try to get a better view what i should expect or e.g. HA will be broken during update as both node will reboot simulatnous - such things. anyone have some input here ? The release notes gave not away much to work with. 

    So the most pressing question is behave that update like a normal one - patching passive first, failover, patch new passive , failback ? Or is it more adviseable to beak HA patch the "passive" , take conf from the active , point any client to the patched node and make it the active one. patch the other node, at best kill the config - and bring it as emtpy box back to cluster ? 

    Tbh it is hard to estimate how to work this update - as in past i encounter lot strange things with the OS release on different boxes.

    regards 

  • 0

    Updated from 18.5 MR1 to MR2 and IPSec VPN stopped working for NCP IPSec VPN clients with previously working config.

    I'm using IPSec connections (not Remote Access) with ConnType = Remote Access (legacy) and PSK.

    Phase 1 connects just fine, phase 2 is cancelling due to "INVALID_ID_INFORMATION : 18" (NCP log).

    This is the excerpt from /log/charon.log. (VPN name and IPs redacted for privacy)

    2022-02-03 22:18:03Z 22[NET] <CLIENT_VPN-1|64> received packet: from 93.104.xx.xx[10954] to 80.154.xx.xx[4500] (604 bytes)
2022-02-03 22:18:03Z 22[ENC] <CLIENT_VPN-1|64> parsed QUICK_MODE request 3455262986 [ HASH SA No KE ID ID ]
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> ### process_request invoking quick_mode_create
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> ### quick_mode_create: 0x7efc98003780 config (nil)
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> ### process_r: 0x7efc98003780 QM_INIT
2022-02-03 22:18:03Z 22[CFG] <CLIENT_VPN-1|64> looking for a child config for 192.168.1.0/24 === 192.168.254.2/32
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> trying other candidates from phase 1
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> no matching CHILD_SA config found
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> queueing INFORMATIONAL task, already 0 tasks queued
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> flush_queue(IKE_NATD)
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> ### destroy: 0x7efc98003780
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> activating new tasks
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64>   activating INFORMATIONAL task
2022-02-03 22:18:03Z 22[ENC] <CLIENT_VPN-1|64> generating INFORMATIONAL_V1 request 866459256 [ HASH N(INVAL_ID) ]
2022-02-03 22:18:03Z 22[NET] <CLIENT_VPN-1|64> sending packet: from 80.154.xx.xx[4500] to 93.104.xx.xx[10954] (92 bytes)
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> activating new tasks
2022-02-03 22:18:03Z 04[NET] sending packet: from 80.154.xx.xx[4500] to 93.104.xx.xx[10954]
2022-02-03 22:18:03Z 22[IKE] <CLIENT_VPN-1|64> nothing to initiate

    Any advise would be helpful. Thanks!

  • 0 in reply to Steffen Seitz

    Hi

    Last week I updated XG310 in HA (Active/Passive) from 18.0 MR5 to 18.5 MR2. Did not break HA, just did an update. First it updates passive device ( it took around 10 minutes), when passive device reboots with new OS it becomes Active device. When it switched from Act/Pass 2 pings are lost and all VPN reconect, and all SSL VPN sessions drop. Then the other device gets upgraded (also 10 minutes). Basically that is it. I had no problems. It probably also depends on how complex your configuration is. For failback I read a KB that you need to break HA and revert and set up HA again with old OS.

    BR