Sophos Firewall: v20.0 MR1: Feedback and experiences

Question

Release Post: Sophos Firewall OS v20 MR1 is Now Available 
 The old V20.0 GA Post: Sophos Firewall: v20.0 GA: Feedback and experiences 
 To make the tracking of issues / feedback easier: Please post a potential Sophos Support Case ID within your initial post, so we can track your feedback/issue. 
 Release Notes: https://docs.sophos.com/releasenotes/output/en-us/nsg/sf_200_rn.html 
 
 Important Note on EOL Sophos RED Support: 
 The legacy EOL RED 15, RED 15w, and RED 50 are not supported in v20 MR1. Customers using these devices should upgrade to SD-RED or a smaller XGS appliance before upgrading to MR1 to maintain connectivity. See the following article for details: Sophos RED: End-of-life of RED 15/15(w) and RED 50

LuNie · Accepted Answer

The updates are usually staged and therefore it takes time until they are offered via the automatic update function. So shortly after release, an update is usually only possible manually via file.

LHerzog · Answer

Thanks for LuCar Toni for mentioning NC- 117690 fixed on the other posting here. 
 
 Enhancement: Boot options : DHCP now supports boot server and boot file options in the DHCP header. You can also continue to send the parameters through specific DHCP options to provision network devices.

JanosRapcsak · Answer

The hotfix is released, the IMAP proxy should work again on 20.0 MR1. 
 Please let us know when you can confirm this.

bobbylam · Answer

Hi Ian, 
 Glad to hear your issue is resolved. Thank you so much for flagging this issue to us, and helping us fix it. 
 If you look in /log/u2d.log, you should see entries like this: 
 2024-05-17 15:17:28Z dr_dload_checker: Starting download for file sfsysupdate_NC-135882_2.tar.gz.sig 2024-05-17 15:18:28Z dr_dload_checker: Download completed for file sfsysupdate_NC-135882_2.tar.gz.sig 2024-05-17 15:18:28Z dr_dload_checker: Download for file sfsysupdate_NC-135882_2.tar.gz.sig passed integrity and sig checks Fri May 17 08:18:28 2024 [Hotfix]: Affected version '20.0.1.342' found Fri May 17 08:18:28 2024 [Hotfix]: Stopping services Fri May 17 08:18:28 2024 [Hotfix]: Backing up original files Fri May 17 08:18:28 2024 [Hotfix]: Copying files Fri May 17 08:18:28 2024 [Hotfix]: Restarting services Fri May 17 08:18:28 2024 [Hotfix]: Start service: warren 
 This shows the hotfix ' sfsysupdate_NC-135882_2.tar.gz.sig' being downloaded & installed. 
 Note: You can now download the debug logs from Admin UI under Diagnostics -> Tools -> Troubleshooting logs, without having to go into the advanced console. This is a new feature in MR1.

Jubin · Answer

Thank you OlafPelzer for reporting this. 
 We have identified the root cause, workaround, and resolution. 
 Root cause summary: 
 DHCP Boot Options Next-server configuration cannot take URL value (as per RFC 2131). The validation for the URL is missing in v20 MR1. When URL is present in DHCP Boot Options Next-server config, the DHCP service fails to start. 
 Workaround : Please remove URL config from the DHCP Boot Option Next server configuration (DHCP server > Boot Options > Next-server).

Resolution : We will soon release a hotfix to resolve this/prevent it from happening. And also fix this in the immediate next maintenance release. 
 Root cause details: 
 Till 20.0 GA and earlier versions, Boot Option configures DHCP options 66 and 67 internally and did NOT consider Next-server and boot file configurations. 
 In 20.0 MR1 and later versions, these settings configure the DHCP Boot Options Next-server and Boot file option available in the DHPC header. 
 During Migration, if DHCP Boot options Next-server and Bootfile are configured, then when migrating to 20 MR1, SFOS retained the configuration for both DHCP Boot options (Next-server and Boot file) and DHCP options 66 and 67. Additionally, DHCP options 66 and 67 was populated by the firewall (internally) will be made visible on UI under the DHCP option section. 
 The next-server option only support IP address and domain. URL values are not supported (as per RFC 2131), however, the URL value validation has been missing which caused the DHCP service to fail. 
 Thank you for your understanding and patience as we work to resolve this issue. 
 
 Sophos Team

ShrikantSophos · Answer

Thanks for reporting this @ Gerd Rehders 1. This is tracked for fix next MR 20.0MR2 in NC-136693 .

sanket.shah · Answer

Hello Ian, 
 These DHCP improvements are still in the backlog and will be considered in future versions. 
 To complete overall DHCP improvement list in v20-MR1, "next server" and "boot file" DHCP options are also corrected. I hope it will help users who were facing difficulties in using it.

LuCar Toni · Answer

Essentially SFOSv20.0.1 will refuse the connection but still maintain the config. 
 Sophos is doing this, to not "destroy" the config. Because if you are not noticing this change and going to V20.0.1, If we would delete the config, it would mean, SFOS would also remove the config on the RED provisioning server. By not removing it, you still could go back in the firmware and then decide the next steps.

LuCar Toni · Answer

Compression was dropped from SSLVPN configs going forward. More information you find here: https://community.openvpn.net/openvpn/wiki/Compression

Bhavik24 · Answer

Hi Thomas_XG , Please try to check the radius server group name attribute. It looks like the group name is configured instead of the group name attribute. This can be create an issue during user-group membership update and user login is rejected because of missing required policy attachment. 
 Thanks

jekin.virparia · Answer

Hi K-M I have relook the device and below is the reason why the HF is not worked for your case. - The device migrated at around Jun 06 09:47(UTC), and the hotfix is applied at Jun 06 10:06:25(UTC) so the DHCP service is expected to be dead between this time. - As per the logs it seems that DHCP server configuration is updated/deleted, probably to diagnose the DHCP service dead, and the service is started running around Jun 06 10:04(UTC), before the hotfix. 
 - As the probablematic configuration removed before the hotfix applied, the hotfix don't do anything. Hence at first sight, it didn't look like device was affected with the issue. 
 It's should be noted that the hotfix will not apply immediately on the firmware upgrade and it may take approx 15 to 20 min to apply all the hotfixes. 
 I hope this info will clear the understanding about why the hotfix didn't worked for your case.

LHerzog · Answer

I removed the Sophos Central device registrations on the cluster and re-registered both machines again. 
 The This firewall belongs to a Sophos Central firewall group message has now disappeared.

rfcat_vk · Answer

Under Michael's guidance I have disabled pharrming and block ssl on ssl ports. I also disabled my specific firewall rule and the messenger chats now update regardless of secure chat upgrade or not. 
 Waiting on further advice as to the next step. 
 Ian

Nikhil Bhandari · Answer

Thanks for sharing access id over DM. From the logs, I could see that some of the users (6 in number) had some problems connecting initially. Can you share how did you resolve the problem for them ? Did they download a new ovpn file or used a different sslvpn client, for example ? Those initial problems caused some stale entries in table due to which you are seeing the problem now. 
 To take one example, the connection problems I am referring to occurred on May 23rd for the user "j***s**v.s*m*k" (hiding the complete name, that you would know). 
 The immediate remedy for your problem is to delete those stale entries from the table while we investigate why it happened in the first place.

LuCar Toni · Answer

Could be related to the issue above: Could you ping the support: NC-136062

Jubin · Answer

Hotfix is released on 3rd June.

Bpatel · Answer

Andreas Marx , we have fixed the issue related to the firmware upgrade on XGS87 in v20 MR1 but it is still open for v20 GA. The issue is because of the more memory required by firmware upgrade utilities. you may try a firmware upgrade immediately after reboot as a workaround or share the support access ID to me, I can patch the system to fix the issue permanently. 
 This is the issue ID NC-132224 that you can share with support if you want to open a support ticket. 
 Thanks, 
 Bhupendra

OlafPelzer · Answer

The hotfix did only part of the job in our tests, but the workaround/solution is quite simple: Clear the content of the field "next server" in the dhcp gui and the dhcp-service can be started. The Hotfix as it is now just copies the content of the next-server-field into dhcp-option 66, which is available in the gui since SFOS v20.0 MR1.

JanosRapcsak · Answer

So far this seemed to be a configuration issue, the mail proxy handles detected spam messages as defined in the SMTP policies.

jekin.virparia · Answer

Hi Ben, 
 Thank you for providing the support access. We identify this behaviour is a side effect of improvement in the DHCP client in v20.MR1 release and tracking with NC-136619 . With improvement in v20.MR1, the actual lease time will be used whereas in v20.GA the minimum lease time used was 120 seconds. As per the DHCP client, the renew happens when dhclient script(executed on IP lease) execution takes less time compared to renew time(lease time/2). For your case, the dhclient script took more time than the renew time(20 seconds) hence the renew was not sent by the client the lease was lost and a fresh IP discovery was sent. Due to this, the gateway and internet is flapping. This issue can be observed on earlier releases if dhclient script takes more time(depending on the processing power and no of DHCP interfaces and CPU usage) than the renew time but is aggravated with the changes with lower lease time. This is can be mitigated by increasing the lease time in the DHCP server by ISP.

emmosophos · Answer

Hello Community, 
 This issue is being investigated under NC-136062 
 Regards,

JanosRapcsak · Answer

Hi Evan R , 
 it seems you experience a knows issue that we track about wildcard domains not working in SMTP exceptions. 
 Please upgrade to 20.0 MR2 when it's released, where we'll support adding IP ranges to SMTP exceptions. 
 Until then, you can remove "Premium RBL Services" from the "Reject based on RBL" list.

Ben@Network · Answer

Very strange. Sophos Support creates new IPSec Profile, firewall rules and NAT Rules. After that, the tunnel came up one time. I was not able to reestablish the tunnel. Now I switched back to my old tunnel configuration that works in SFOS 20 and the tunnel is working with MR-1. I removed the settings that was configured by Sophos Support and the tunnel is still working.

Sophos Firewall: v20.0 MR1: Feedback and experiences

Important Note on EOL Sophos RED Support:

Top Replies