[Fortigate 50B Firmware Download Free Download
Abdul Soumphonphakdy
My suggestion would be to keep calm and have a look first which parts of the config are damaged - if any. Going from v5.4.x directly to v5.4.8 isn't nice as an upgrade may include transformations of parts of the config where e.g. the syntax has changed. These transform routines are included in the firmware image and run automatically.
This would really be detrimental if you skipped from one FortiOS main version to another. Currently, there is v5.2, v5.4, v5.6 and (soon, bleeding edge) v6.0 as the main OS versions. But in my experience skipping a patch release will only affect small parts of the config. It would be wise to first assess the damage before downgrading as this will 100% revert the FGT to factory defaults. If you don't have physical access to the FGT this will be really a showstopper.
Just download the current config (without password a.k.a. as cleartext) and compare that with a diff tool to your backup. Chances are high that only the version comment in the first line and all encrypted strings are different. The latter will still be valid.
Everything with the router so far seems fine except that Wifi is almost unuable. I tried loading the previous *.conf file by putting it onto a USB and doing a auto load on restart. (I tried both CLI and GUI methods, always comes back with the latest config)
I will have physical access tonight, the router is at my home. I have remote access here now but will obviously lose connection if I do a firmware downgrade that will have no config. I''m going to try what you folks have said. Thanks!
Actually, just so I'm clear on this - I'm restoring from the secondary partition and not downloading a fresh copy of v5.4.3 (= build 1111) then restoring my config to that...forgive my beginner comments.
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
The reason why you see a difference between the build number installed in your device from the one in the support portal is simply that depending on the Hardware model a specific firmware version will have a specific build version too, this means that in the end they are still the same exact versions only optimized slightly differently for each of the hardware models.
Some of the configuration settings "locations" change depending on the version you upgrade to, meaning that you could be bypassing these changes by jumping directly ahead, which could result in the upgrade to have unforeseeable outcomes.
Upon reviewing our internal build database, I've found that build 6083 is actually a special build not available to the general public. It's likely that our TAC (Technical Assistance Center) team provided this specific build to the original poster as a tailored solution to a bug or issue they were experiencing, especially when a public GA (General Availability) release containing the same fix was not yet available.
A department on the company that I work are having issues with some FortiGates. This department is charge to the maintenance of the client's fortigates. Today they had two issues with "missing policies", one with a FG200D and another with a FortiWiFi 90D. The FG200D is installed on our office and it had "missing policies" after a Firmware upgrade following the upgrade path from FortiOS 5.6.3 to 5.6.6 and finally 6.0.3. The other device is a FortiWiFi 90D owned by one of our clients and this one also had "missing policies", but in this case it happened after a power disruption.
We had this type of issue on the past on other devices, but were few. The department of maintenance tells me that they are following the recommendations of FortiNet for upgrades by reading the release notes and following the upgrade paths. My concern is that this is happening more often and we are scheduling to do a firmware upgrade to a core 1000D that manage the security on our DataCenter. Missed policies on this FortiGate will cause me a huge stress.
I had been looking on the forum if someone else had this problem, but I didn't find nothig. Some one faced or is facing with this "missing policies" issue? Do they are missing something? Can they do something to mitigate this? I had also hear them say that "policies are getting corrupted" after an upgrade.
This hasn't happen with recent firmwares, but back in the 4.2.x days, the "conversion scripts" that ran during the firmware upgrade process didn't properly handle white space characters in object names/labels, would truncate them at the first space character, so it pretty much missed up the config rather badly.
Same here, never seen that issues b4. I would suspect that maybe manual save might be a issue. If you login into the Fortigate and look and diff the rev b4 and after the changes, what that system revision shows ? FWIW
Way back when dirt was invented, Fortigates would sometime run into memory issues if run for too long. If the device has been up for a while, try rebooting it prior to starting the upgrade. That adds a few minutes to the procedure, but may alleviate some issues.
I did the rev-diff comparing two backup files. The first two were the last backup on version 5.6.3 and the first (and only) on 5.6.6. This presented that a lot of policies were deleted. This doesn't happened when I did the second comparison between the last backup of 5.6.3 and the first of 6.0.3. This last comparison showed policies that the first comparison showed them as deleted. The last comparison (5.6.3 and 6.0.3) showed clearly that the policies that affected the services attached to their interfaces were no longer on 6.0.3.
They have a habit of putting spaces in the names of objects. In the FortiGate of our office I just executed the command "diagnose debug config-error-log read", but showed nothing. I do not know if it's because the upgrade was a few hours ago.
We have 2 fortigate 100EF in an HA cluster that needed to be upgraded (were on 7.0.2) and my boss asked if I wanted to give it a shot. He said it was straightforward and that it does the failover itself and all that. Upgrade path was to be .2 -> .5 -> .7 Well I think I got ahead of myself and somehow set the secondary (f2) to upgrade to .7 while the primary (f1) was rebooting to move to .5. This also briefly took down our sites since both FW were down at the same time (we're an e-commerce company).
So now f1 is on 7.0.5 and is the active primary and f2 is on 7.0.7 but f2 is out of sync and f1 still needs to come up to .7... I'm not a real sysadmin or network guy we don't have one. I tried a couple cli commands I saw online. Recalculate, and there was some force sync command too. Neither helped. I also tried the one to force HA failover to make f2 the primary but that didn't either (my boss thought this might help but I guess I wasn't surprised because the HA cluster is basically just 1 box right now I think).
Part of me thinks if I just do the upgrade to .7 on f1 that maybe they'll sync back up and all will be well. Would just have to eat a site outage again for a few minutes while it reboots? Not ideal I know. Another idea the team had was drop f2 out of the cluster but I think without sending someone to the sever farm to be ready to unplug stuff that we would run into network collisions? Any help or thoughts you guys have is appreciated.
First it would be a good idea to contact a Fortinet Partner with knowhow with that products for the next time, especially if it's for your main business . There are a reason, why network specialist are existing. ;)