FortiOS 5.2: should we wait or should we go?

[VicAndr]

Questions to those who had been brave enough to upgrade their units to FortiOS v5.2.0: How did it handle complex configurations in the course of upgrade (I mean " in-place upgrade" )? Are there any pitfalls to watch for? Does v5.2 work stable? Is there anything to loose in the jump to v5.2? Are you still there on v5.2 or had to go back to v5.0 for one reason or another? What are your overall experiences so far? We have a pure FortiOS v5.0.7 in our environment. It generally works fine but our main headache is new FortiAPs supporting 802.11ac - they are practically unusable on v5.0.7 (we do not want to go with " interim" FortiOS build as it raises a whole bunch of other questions). Thank you all for any feedback, VA

[rwdorman]

Thank you for poking around... sometimes getting an ad hoc different set of eyes without asking to re-queue and tart the " send me logs" round all over again is appreciated. The SSL VPN thing... hopefully that problem will be resolved to the satisfaction of both sides. To be sure: the majority of the time I' ve gotten to that state with TAC.. remote support isn' t easy.

[rwdorman]

Moved the chat about my VPN download question to: https://forum.fortinet.com/FindPost/114051

[Nihas]

I found few issues with 5.2 ( Up gradation issue) A 1. I had one SSID with Tunnel & DHCP for Guest User access. Now , I can' t see the SSID in " Wifi Network" -" SSID" Module.. But Still the SSID is there in interface. A2. I tried to delete the SSID interface , but throws an error " Entry Not Found" . A3. I have tried to reconfigure the interface with the previous details like SSID+ Authentication etc --- Throws another error that the same name belongs somewhere vdom, interface etc. I tried to delete through Output is given bleow Fortigate (interface) # delete Company_Guest VAP interfaces can only be deleted from the vap interface table. command_cli_delete:5206 delete table entry Company_Guest unset oper error ret= -160 But I can' t see this interface in VAP. Can anyone help me? B 1. I was using custom authentication messages ( Replacement messages) , now seems few of them are gone..

[Sean_Toomey_FTNT]

FortiOS 5.2 has done quite well in my own testing, however I can afford to be bleeding edge. We do a very good job on QA and problems have been very minimal, much better than even the 5.0 release in my experience. That said, my own personal level of comfort for anything you rely on in production is to stay a few months behind the curve and do not deploy any new major version until it at least has a couple of patches under the belt, that' s just best practice. Only move to a new major release right out of the gate if you have no other choice, i.e. you need a new feature to keep the lights on or meet a crucial business need. If you decide to do this, please have full backups of your config in multiple places, and ensure you have serial console access that will not be interrupted. While the majority of upgrades are successful, we live in an imperfect world and there is always the chance that something may go awry. When you install the new major version, it will copy it to the alternate flash location and boot it. If you find that you are in trouble, the best way to get back to good is to reboot the firewall, and hit a key during the part of the boot process to interrupt it where it has the periods . . . . . From here there is an option to boot the secondary firmware, this will put you back on the prior version. Once it' s booted, you will need to restore the config you backed up previously, which can be done via a USB drive plugged into the device, via TFTP/FTP, or via GUI. The idea here is that downgrading is possible but is never a best scenario, and again while the conversion process normally goes quite well, you will give yourself the best chance of returning to a known good configuration by booting alternate flash and restoring config, vs trying to downgrade the existing installation/config in place.

[VicAndr]

FortiOS 5.2 has done quite well in my own testing

Have similar experience here. It is not perfect but generally FortiOS 5.2.0 works pretty stable and does what it is supposed to do. It has 2 major flaws though: one is hardware-related and another one - software-related. HARDWARE-related As we all noticed, FortiOS is steadily becoming more and more resource-consuming with every new FortiOS release; and memory is hit especially hard. We do understand why it is happening: FortiOS is getting more and more features; it is processing more and more data in real time; and it is becoming a lot more capable, flexible and intelligent. So nothing they could do about increased demand on resources (especially memory). The problem is though that there is still a lot of FortiGate/FortiWiFi units on the field with a mere 512MB RAM (FG/FW-20C, FG/FW-40C, earlier hardware versions of FG/FW-60C and FG/FW-80C). Many of those units are not even listed on Fortinet Product Life Cycle page ; and if they are - they still have a long time to go before reaching End-Of-Support milestone. So they all claimed to be " supported" on FortiOS 5.2. What happens after upgrading such a unit to v5.2 is - having a memory shortage on the system, unacceptably often FortiOS locks itself into the " conserve mode" as a self protection measure. While working in the " conserve more" a FG/FW unit has a " handicapped" performance; you can' t even adjust a unit' s configuration - as no adjustments are allowed in this mode. I am pretty sure that Fortinet' s Engineering was well aware about the " memory issue" . That is why they quietly introduced memory-upgraded hardware versions of FG/FW 60C and 80C (thanks to rwpatterson post). So we have a very interesting situation now. On one hand - it is unrealistic to expect that future builds/releases of FortiOS would require less amount of memory to operate efficiently. On the other hand - what to do with poor folks who own those memory-deficient FG/FW units? The Car Industry would make a recall, fixed the problem and returned products to their happy owners. IMHO although it is a costly undertaking, strategically Fortinet would benefit from similar approach in a long run. I wasn' t sure if Fortinet even contemplating such a recall. So I opened a ticket (it is good to have all your Fortinet equipment under support contracts ), argued the case, and managed to replace all our memory-deficient units (three FG/FW-80C(M) boxes) with RAM-upgrade hardware revisions. So if you don' t ask - you don' t get . SOFTWARE-related While v5.2 itself works pretty stable (according to my experience - it is not any worse than v5.0.7), " the devil is" in the upgrade scripts built into this particular build of FortiOS (the ones which transform firewall' s configuration from previous FortiOS version in the process of " in-place" upgrade). Not sure - if they assigned a junior programmer to compile those scripts, but they are written quite poorly and do not accommodate all possible configuration scenarios. As a result of an upgrade - it either misses some parts of pre-existing configuration or totally corrupts it, making the whole unit unusable. We have 25% success rate upgrading boxes from v5.0.7 to v5.2.0. So far we have upgraded 4 FG/FW units to v5.2 and only one of them was upgraded without noticeable issues. One unit fell into endless reboot cycle and other two - lost pre-existing WiFi networks without easy straight-forward way to re-instate those SSIDs. All lost SSIDs happened to be Captive Portal ones with customized messages. I was lucky enough as the configuration of the unit which fell into reboot loop was comparatively simple - it was rather easy to rebuild it from scratch. Unfortunately it is not always the case. Our main FG appliance installed in the head office, for example, has a pretty complex configuration: multiple policies, virtual IPs, dual-internet connections, miltiple VPN channels, complex routing, several SSIDs and so forth - it would be a nightmare to re-build its configuration from bottom-up. In the circumstances we can NOT rely on upgrade scripts which are built into this build of FortiOS. Much more reliable way to get a FG/FW box on v.5.2.0 is: formatting flash, uploading FortiOS through TFTP and then build the whole configuration from bottom up. Fortunately Fortinet do not need to do recall in this case - just make sure to do the job right.

[Michael_Ledet]

Vic you mention the memory upgrades in some units. There was a similar situation with Cisco ASA' s when moving to 8.3 code. However, you could manually upgrade the memory in the unit to the new higher requirements. Curious if this is also possible w/ the Fortigate' s.

[VicAndr]

Vic you mention the memory upgrades in some units. There was a similar situation with Cisco ASA' s when moving to 8.3 code. However, you could manually upgrade the memory in the unit to the new higher requirements. Curious if this is also possible w/ the Fortigate' s.

That' s actually a very interesting question which opens the whole new discussion. Extended hardware warranty is a valuable part of FortiCare/FortiGuard subscription bundle. Although generally FortiGate/FortiWiFi boxes proved to be pretty reliable, they do fail: I had to exercise our hardware exchange right few times during 10 years of my working experience with Fortinet products. FG/FW units could easily be opened BUT while doing so you would break a seal that states " Warranty void if seal is broken" . So if you want to maintain hardware warranty you would not open a FG/FW unit. Our FG/FW units currently in service are all covered by support subscriptions, so I couldn' t have opened them for obvious reasons. I opened few old ones though which are no longer in service. I found that most of them (although not all! I.e on FG-60 memory is soldered - it is not removable) use standard removable memory modules - the same one which are used in regular PCs (not sure about high-end FG/FW models but on lower ones - they are Non-ECC, Unbuffered). So technically - memory is easily upgradeable, ...if you don' t have (or don' t care about) hardware warranty. Nor sure though if any memory restrictions are in force on FortiOS BIOS level. It would be interesting to know if anyone successfully upgraded memory on a FG/FW unit. Perhaps we should open a new thread re. the subject.

[MikePruett]

I wish it was a little more polished. Disappointing really because I am a big fan of what they are trying to do with it. It butchered wireless on my 60D though.

[Jan_Scholten]

I wish it was a little more polished. Disappointing really because I am a big fan of what they are trying to do with it. It butchered wireless on my 60D though.

Could you tell me a bit more? I have to upgrade to 5.2.X on a remote 60D-Cluster, and i have a couple of FortiAPs running there.

[VicAndr]

I have to upgrade to 5.2.X on a remote 60D-Cluster, and i have a couple of FortiAPs running there.

I have upgraded a number of FG/FW units (including one FW-60D) with various types of SSIDs from 5.0.X to 5.2.0. In my experience (maybe experiences of others are different) - WPA/WPA2-Personal and WPA/WPA-2 Enterprise SSIDs are upgraded to v5.2.0 just fine but Captive portal ones ALWAYS get corrupted during the upgrade. I am not exactly sure why it was happening - whether it is due to our portal customizations or something else - Fortinet would be in a better position to answer this question. But after you remove a corrupted SSID and re-create it with the very same configuration on v5.2.0 - it works just fine. The problem though is that removing a corrupted SSID is not always a straight-forward process. You can' t do it from GUI since a corrupted SSID simply disappears from the list of configured Wireless Networks in WiFi Controller section of the GUI. So you need to do it from CLI removing all the dependencies first and then removing the SSID itself. And even with the CLI you can' t always do that. So your last resort to remove remains of corrupted SSID is - saving firewall' s configuration to a file - manually editing this configuration to clean it up off the failed SSID - and uploading it back to the firewall. So if you want to preserve a Wireless Network during the upgrade from v5.0.X to v5.2.0, the safest way to do so would be - removing it from the configuration right before the upgrade - performing the upgrade itself - and then re-create it back on v5.2.0. If you have a limited time-frame to perform a firewall upgrade - you may pre-compile " SSID_remove" and " SSID_create" scripts and apply them before and after upgrade accordingly. There is bigger issue to watch for while upgrading to v5.2.0 though. Whether you have a Wireless Network on your unit or not - sometimes a hardware-healthy FG falls into endless reboot loop when you apply v5.2.0 firmware. Again - I do not know why it happens, but it have happened to me once, as well as other people in the forums reported the same experience. The only solution available to you in this case: formatting flash -> uploading a firmware and either -> uploading an available configuration backup for that particular FortiOS version -> or rebuilding it from scratch.