Guest User!

You are not Sophos Staff.

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 35309 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]
  • 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

  • 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