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

[Nihas]

Hi Emnoc, Sorry, I meant the captive portal option has been removed from policy module in 5.2. It' s there on interface, But placing a captive portal in an interface wide, will not effectively help us to achieve the plan. And there might be other devices connected to the port like printers ,NAS which can' t pass the authentication. But 5.0.7 has the option in all policies and we can simply plan and place the captive authentication portal accordingly. in 5.2 ,only wifi interface ( policies with wifi interface) has the option for Captive portal . And they brought few more things on captive like external portal/ portal redirect etc.

[Nihas]

Hi Emnoc, Yes - I was partially wrong, it' s there in CLI, but not that much flexible to do

[TheDudeAbides]

I was pretty excited when i saw all the new features and settings in 5.2. But after our experience I would say no go. We tried to upgrade two units. A remote FortiWifi 40C and our main Fortigate 100D. The FortiWifi 40C was running 5.0.7. My only real problem with the unit is that its 5Ghz signal is weak. Anyway tried a web interface upgrade and was never able to connect to it again. Tried using the Reset button method to bring er back but was unsuccessful. Its on the shelf now awaiting a serial connection reset. After that experience, I was much more cautious with the 100D. We used the serial connection factory reset and uploaded 5.2 via TFTP. I rebuilt our policy from scratch to avoid any issues. We got everything up and running EXCEPT our VoIP phones. I performed the usual steps that fix VoIP through Fortigates: [link=]https://materdeiparish.freshdesk.com/support/articles/1651-how-to-configure-a-fortinet-firewall-for-vocalocity-s-sip-voice[/link] No matter what i did, we were never able to get dial tone. Packet sniffing showed traffic passing as normal. We ended up serial flashing and TFTP back to 5.0.7. Since there arent and gotta have it features, we' ll just watch for the patch. PS, we monitor over 20 fortigate 40' s and 60' s and the are all ALWAYS at 80%.

[emnoc]

FWIW I think with any upgrades, we need to take snapshot & have a back out strategies. A major bump from a release like 5.0 to 5.2 is bound to have problems. We are bound to find new problems and bugs. Anything moving into a new major family release should be thought out and risks associated. The bigger problems are, unless forinet does exhaustive QA, we will not know all of the issues until orgs actually upgrades. Me, I' m waiting for 5.2 and the first patch b4 I re-attempt any more upgrades. The benefits in my environment are slim to none. Right now, I' m battling a SSLVPN portal issues under 5.2.

[rwdorman]

It has been challenging to both times I' ve been on with TAC hear " yeah, we' ve had so many problems with 5.2, I' d stay away from it" when I had to upgrade to fix show stopping bugs. Another known bug (apparently) - The download of the SSL VPN plugin (from the web page) for OS X is broken. The DMG has to be downloaded separately and then manually distributed.

[Christopher_McMullan]

I' ll echo Sean Toomey' s earlier post, and add some perspective of my own... TAC engineers make poor product ambassadors. Unless we think about everything we say " off the cuff" before we speak, we can' t really help it. We only see the product' s faults, since no one calls in when they work! That can jade our perspective. Ask an emergency ward nurse if they think everyone they meet seems sick. Any outreach to Fortinet through discussion forums, web chat, or through a ticket means there is a question or technical issue that needs addressing, so we obviously all have our own reasons for making contact. That being said, QA performs firmware testing up to the full rigor you would expect from any other firewall vendor. The missing ingredient is user experience. Beta testers and early adopters are willing to try a new release for its features and accurately report details of any faults. Follow Sean' s advice on best practices, and upgrade peripheral devices first to test the impact of a new release before applying the build to main production firewalls. One service I would highlight that would be exceptionally useful in this case is web chat. Tickets can be used as a reference for questions before an upgrade, but web chat will provide a response to any question (as opposed to in-depth troubleshooting) within a short amount of time. Anecdotally, when engineers out of our office here in Ottawa are handling web chat, Level II engineers like myself often times will be reading over their shoulders and helping them to answer the questions that come up. If you haven' t used the chat service before, I encourage you to give it a try.

[rwdorman]

Chris I appreciate the insight here. It confuses me to hear you say that QA is done as in any firewall vendor but user experience is not included (or cannot be properly captured). Many of the bugs that I' ve uncovered with TAC are quite understandably edge cases that you just cannot test for. I accept that and tho it is frustrating we live with it. Some of them, however, basic functionality such as logging in as a user and being able to click on everything on the page that is in front of you doesn' t seem to me to be a user experience that cannot be tested ahead of time. Having technical writers compare that the screenshots they put in documentation actually match that of the release they are documenting. Things like that. As for the web chat, that is interesting to hear. When you try to open the web chat, the warning where it says not for use for " complex issues requiring extensive troubleshooting." That is a tough one to quantify, usually if I gotten to the point I want to work with TAC i assume it is a complex issue but I will try that in the future. I honestly do appreciate that you and other Fortinet employees participate on this forum and welcome other advice you would have on how we can make working with your products and colleagues more efficient.

[Christopher_McMullan]

I wasn' t kidding about us looking over each other' s shoulders, Ryan. Without going into specifics about the ticket itself, I was just speaking with one of my colleagues about a case involving an SSL VPN web portal and its download links for various clients. The link from the tunnel-mode widget points to a local file on the FortiGate. AFAIK, this is a stub installer that pulls the remaining cabinets from FortiGuard based on initial system checks when you unpack the executable. The " direct" download links below for different operating systems don' t actually re-direct you to FortiGuard. They cause the FortiGate to initiate its own download of what looks like the latest client installer version. You can see both files under the directory /var/log/package_cache if you run: fnsysctl ls -l /var/log/package_cache It looks like the FortiGate is the proxy in both cases for a direct download. This makes some measure of sense, since you may be allowed to access a VPN web portal but denied access to FortiGuard, depending on where your host is connecting from. That being the case, any unsupported browser (like Chrome, under certain circumstances) could result in server error messages displaying in the widgets.

[Christopher_McMullan]

All that being said, if it still doesn' t work, a packet sniff would be the best next step to see why. It should be run between client and FortiGate, to see what traffic results from an HTTP GET on the download link for the client in the tunnel-mode widget, then again for the direct link. The capture should ideally be run simultaneously on the FortiGate (' diag sniffer packet' ) and on the client (Wireshark). Specific issues can be taken up on a separate, specific thread, if you/we think the eventual resolution merits being seen by a wider audience.

[simonorch]

Anyone that has been working with fortinet kit for a number of years will appreciate the improvements made in the quality of TAC support, documentation and technical interaction with partners and end customers. There are scenarios where i feel it is legitimate to go with a GA release. I' m currently well into a pilot project for a large customer that involves using 60Ds at over 500 locations replacing cisco kit. Phase 1 of the project from a firewall point of view is to simply roll out the kit with the same functionality as today, which pretty much means basic firewalling and a static route with FMG for management. As we' re not upgrading anything either, this is functionality that works fine in 5.2, but looking long term, by going with 5.2 now we' re future proofing something that will be in production for a minimum of 5 years, i' d much rather minor patch 5.2 than even consider having to major upgrade in 3-4 years. I also know that patch 1 is right around the corner and the plan is to go with that (baring show stoppers) when we get to roll out time. if some of you think that' s risky, spare a thought for the other vendor in this project who will remain nameless, they are going with beta software during the pilot and new hardware models that are only now being produced in asia.