Upgrading 17 to 18 experiences would and criticism

There is a good post about upgrades in general: https://community.sophos.com/sophos-xg-firewall/f/recommended-reads/129246/best-practice-for-sophos-firewall-firmware-upgrade

But from 17.5 to V18.0/5, there are some specialties. 

First of all, the HA will reboot at the same time. Therefore you will have a downtime of ~2-5 minutes until both appliances reboot. 

The configuration should not change and it should not have impact on your configuration but the config will look messy. Therefore some cleanup should be follow up. 

Linked NAT will be created for each and every firewall rule. This is generally speaking not needed, because you have a SNAT MASQ Rule at the bottom. 

I recommend to disable the virtual fastpath, if something behavior oddly after upgrade. The new architecture is loaded after upgrade and the new DPI engine is loaded: You can disable this via console> system firewall-acceleration disable    and in the webadmin under TLS/SSL Inspection Rule. 

Thanks for the quick answer.

I use a lot of policies "grouping" , Do you think that this could lead to even more messy results?

I have a couple of IPsec VPN connected offices that are on 17.5 version too, I will upgrade the main one first and after that the remote appliances, or maybe it's better the opposite way? 

And the last question, will it be possibile to switch back in case of a disaster scenario ?

Best Regards,

Simone

Grouping should not be an issue. NAT will be placed into NAT. 

I would always recommend to get some hands on experience with a smaller office first. 

You can go back in the firmware, if you want by using the SFloader (Simply press "boot old firmware"). 

I've tested on an xg115 the upgrade from 17 to 18, migrated policies are "decomposed" in the NAT rules ( and that is ok ) but are spread even in Migrated IPv4 SD-WAN policy route resulting in Firewall Policies option "Do not apply this migrated rule to system-destined traffic" checked and grayed out. Do I have to manually create again all firewall policies to clean all this mess? 

See: https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/tasks/RoutingSDWANPolicyRoutesMigrated.html

Firewall Rules are only having a Checkbox, indicating there was a rule created. This checkbox does not matter. 

Check the Sd-WAN Rules and read the Online help carefully. 

I was excited to upgrade to 18 because of the added fixes for the DUO DualAuth push timout issue and the upgraded Modecurity modules. Unfortunately a few things we didn't expect went sideways in our deployment with this move. Because the WAF logging is weak at best in the gui we opted to tail the reverseproxy.log out to our Elasticsearch cluster so we could keep a better eye on it. this is possible by scripting an ssh session and invoking netcat to pipe the output to one of our logstash servers. Worked great.. but with the upgrade we needed to add a watch dog to the SSH session because with the new firmware SSH sessions are limited to 15 mins unless poked at. No problem, got around that.. Problem number 2 was that in 18 the country blocking module was no longer working for my WAF pipelines because of something to do with fast path processing routing around the filter for the WAF. That was annoying as well and I ended up having to implement a blackhole DNAT for any offending countries. I was also told that MR5 fixes this issue.. I upgraded and found that this was not true. and not only was that not fixed, in MR5 they removed NC from the OS and my WAF log ingestion would no longer function as I had it. So while I was able to fix my DUO MFA timeout issues, it's been a real treat working around the other "enhancements'. I suspect the SSH timeout and removal of NC were security enhancements,  but I cant help feeling that it was actually because I had shared my methods and this may have thrown up some ???'s So basically we are now stuck at MR4 unless I come up with a way to stream that logfile. We have somewhat outgrown our XG's but the pain of moving on is a valid consideration, especially with all of our optimizations and methods we use to get around the limitations.

SSH timeouts are to prevent IDLE Sessions. Modern Tools support keep alives. 

About the country blocking: https://docs.sophos.com/nsg/sophos-firewall/18.0/Help/en-us/webhelp/onlinehelp/nsg/sfos/tasks/FirewallRulesCountryBasedRuleCreate.html?hl=country%2Cblocking and https://support.sophos.com/support/s/article/KB-000042367?language=en_US

Yep. SSH is using a keepalive now, it was an unexpected surprise.

As to the DNAT, That's what I had to do...

17.5-mr10 to 18.0-mr5 3 months ago. So far everything's been working fine. There was an issue we identified with VPN via Sophos Connect and support finally just confirmed the issue a couple of weeks back.  FW/NAT rules were a bit overwhelming at first but I did load it to my home XG lab and played around a bit. It wasn't too difficult after a couple of days. So far so good and the performance of the FW seemed to be quicker.

Sophos Connect Problem - Split and Full Tunnel at the same time on different users - Discussions - Sophos (XG) Firewall - Sophos Community