Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

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: v20.0 MR2: Feedback and experiences

Release Post:  Sophos Firewall OS v20 MR2 is Now Available    

The old V20.0 MR1 Post:  Sophos Firewall: v20.0 MR1: 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



This thread was automatically locked due to age.

Top Replies

  • It was not possible for us to get this working 100% with different customer environments and I´m not sure now if we should retry this and maybe wasting more time for things that have a stupid implementation...sophos support was useless in every case here - so we moved to STAS... But I´m not really happy to install 3rd party software on DCs and get a lot of ID 10028 errors on the DCs now... But so far the user auth with STAS is working.

  • The bottom line is: the Kerberos implementation is similar to the UTM one. It is just for some setups different, as SFOS in most setups is not the direct proxy / like in UTM in most cases was. 

    Those fixes here are not helping for initial setups. 
    Customers using SFOS as a direct proxy should not have much problems for Kerberos in the first place. For transparent proxy, you need to be careful with the internet proxy settings on the client. 
    One fix is about customer using HSTS for the proxy and this breaks the authentication in SFOS. 

    __________________________________________________________________________________________________________________

  • Your compatibility checker doesn't appear to work correctly for 'Virtual - Cloud, Virtual, Software'

    I can't find a single instance where using this as the source or the destination with any other appliance is allowed (including to itself!)

    From the release notes, "This makes it easy to upgrade Sophos Firewall XG Series to XGS Series, upgrade any XGS Series model to any other XGS Series model, or even migrate to or from software or virtual appliances". So what is supported? And can you get the online checker fixed?

  • Seems to be a display issue. software is supported as a source device.

    __________________________________________________________________________________________________________________

  • The issue has been resolved. Thank you,  , for reporting it.

  • 'Virtual - Cloud, Virtual, Software' is supported as a destination device too.

    Been playing around with it today and on our limited testing seems to work fine.

    Will be very useful as a Sophos Partner when we need to do a temporary replacement of an XGS because of a hardware issue. It's always been a worry having something available that is compatible for the backup. This gives us a lot more flexibility.

  •   how do you handle licensing with temporary replacement devices on customer failure? Always fully licensed appliance on hold for such cases?

  • Hi,

    when will Sophos fix two small but impactful bugs?

    1. if you use auto created firewall rules (I know better not to use) the logging is always off!

    2. the same with the dop all rule - NO logging

    Both would be easy to fix and would make troubleshooting much easier!

    BR Gerd

  • We can deploy with an MSP license and only pay for a month.

  • Essentially they are not considered as bugs. Auto created firewall are not using logging per default. 

    The default firewall rule is not existent. It is a visual placement, to indicate what happened if there is no matching firewall rule. If you want to have logging for default drop, you can create your own firewall rule at the bottom.

    As far as I remember, auto created firewall rules did not use logging on UTM either. It’s a design choice. As well as default drop. You could enable it, if you want, like you can create your own default drop firewall rule on SFOS. 

    Why do you consider those system designs as bugs ? 

    __________________________________________________________________________________________________________________