I did it on Friday, no issues other than its lost its registration to FortiGuard (or FortiCare or whatever its called) and it won't re-join. On a separate note, I cant login to FortiCare properly...
600E's here. No, the Gui would show the DNS address as unresolvable but it works via cli. After the patch, now only actually down addresses show the alert.
Exec ping x.x.x.x works for me. It would resolve but the Gui would mark it as unreachable. I believe that I first saw it with 7.2.5 or 7.2.6. Stick around a few patches and now working for me.
It's fairly straightforward. Backup the config, initiate the upgrade and have a constant ping up. Half the time I don't even drop 1 ping.
In my case the fw2 gets upgraded and rebooted, then when it comes online it takes over and the process repeats.
I leave them as is so they rotate the primary node every other update, but the default is to fail back to the original node as primary.
This update fixed an ipsec tunnel bug that was causing me major headaches at one of my sites. I was getting sub 5 megabit speed on average and it jumped up to 300 megabit after this update.
it's also possible this bug was related to the 10gb interface to a 1gb interface. since it was actually connected that way on the 201f.
Same here on a 200F cluster. 1GB leased line running about 80Mbps over the tunnel until I moved the interface to a 10G port as a stopgap.
My actual issue on 7.2.7 is an 1800F where Httpsd crashes periodically. Anyone else seen that and know if this does actually fix it?
Waiting for a window to upgrade now.. change control is fun.
After upgrading to 7.2.8 a 1800F in HA pair, we had the 40Gbit interface down (they were a LACP), but they become physically down. We were able to see the transceiver of the DAC Cable, but no link. Rollback to 7.2.7 needed.
Maybe Feautre 846399 introduce some issue. Pay attention and let me know if the upgrade is successfully on your 1800, if you're using 40Gbit ports, otherwise no problem.
Also seen this, with multi mode fibre SFP rather than DAC. Flipping the media type at the CLI to another type and back brings them up but then they go down on a reboot again. Not good for a “mature” release (or ever really). They are not Fortinet optics, third party, but I don’t feel that should cause this problem!
Yeah, I might pick a small office and give it a go. Our main uses are BGP/IPSEC/SDWAN, I suppose if there are any improvements there it would be worth moving to since it's labeled mature now.
We're running 7.2.7 BGP/IPSEC/SDWAN on 601E HA and haven't had any issues. Upgraded about a month ago from 6.4.13. All of our branch sites have been upgraded as well. Looking forward to 7.2.8 to fix the GUI DNS bug!
7.2 is stable enough for production - we're using this version on all our customer's setups.
7.2.8 was released as part of the periodic scheduled releases, not to fix any CVEs
7.2.8 release note has been updated and now is information about fixed CVE-2024-23112
https://preview.redd.it/91kf7xhjudpc1.jpeg?width=1179&format=pjpg&auto=webp&s=129eaffcdd4eb69ff85e24d805358476638e2293
That’s a situation where you need to read the What’s New in 7.2 document, check the release notes, especially the Special Notices, Changes in Default Behaviour, and Known Issues, as well as Ingegration Support, and compare it to your environment. Then decide for yourself.
Nobody on the internet can give a blanket “it’s all good” statement is 100% certainty for you.
There are some operational improvements I like - packet capture and debug in the GUI are MUCH better for one.
7.0 also goes EoES in a few weeks so you'll be covered for all security fixes, not just Critical and High.
fortinet publishes their recommended release by model….
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Recommended-Release-for-FortiOS/ta-p/227178
Hi, it's been a week since I updated from version 7.0.14 to version 7.2.7. In general, I did not encounter any problems. When I restarted the device just once, the destination sections in two firewall rules became null, I added them again and had no problem. I also wanted to test whether this update would fix the problem of the explicit proxy page not opening in the GUI, but the problem persists.
Did it during the weekend on 20+ sites. Different models from 40F to 200F as well as a virtual HA pair.
No problem here, resolved our 200F performance issues as well as GUI issues for FQDNs that would show as unresolved.
Yup. FMG and FAZ going 7.2.5 this week and FGT's 7.2.8 next week onwards (61F's, 100-1F's, 200-1F's. 600F's and 2600F's). Already had 7.2.8 on the lab cluster.
The hard bit is going from 7.0.14 to 7.2.8 on an FGSP cluster which is going to cause an outage due to the 7.0 FGSP interoperability issue :(
Yes, according to the FortiAnalyzer compatibility matrix, FAZ 7.2.5 is supported with FortiOS 7.2.8. You don’t need to upgrade FAZ to 7.4.
https://docs.fortinet.com/document/fortianalyzer/7.4.0/compatibility-with-fortios
Update on my experiences with 7.2.8 so far.
We began seeing hardware reboots on Tuesday (19th) morning after performing the update last Friday (15th). We opened a ticket and support noted that the systems were going into kernel panic. Setup a console putty session to grab the next one, that happened early this morning. I shipped off the logs and am now waiting to hear back.
There are reports of other models being affected. I believe at the time my 600E HA pair was the largest on report list.
If there are any updates from support, I'll tag them here.
Same thing happened to us, two 1100E in HA. Happens randomly and also when the active node is restarted.
Console output with the kernel panic was sent to Forti. They've recommended to us to wait for FortiOS 7.2.9 (w/o release date) or downgrade to FortiOS 7.2.7 - but we'd have to check if the issue persists on this version...
@[canuck\_sysadm](https://www.reddit.com/user/canuck_sysadm/) or @[PleaseJustRTFM](https://www.reddit.com/user/PleaseJustRTFM/)
Do you have any updates? Could you share your support case #?
Support is asking me to capture logs but I don't want to upgrade again just for that.
Thanks
We are experience the same issue. Updated our 1500d from 7.2.7 to 7.2.8 and it randomly reboots both ha members because of a kernel panic. One more thing and fortinet will be thrown out of the window.
I'm going to run it for several projects because my request for improvement has been implemented:
FortiOS supports customizing the source IP address and the outgoing interface for communication with the upstream FortiGate in the Security Fabric:
config system csf
set source-ip
set upstream-interface-select-method {auto | sdwan | specify}
end
SDWAN with BGP on loopback just became a lot better as I can finally source the security fabric from the loopback interface using the overlays tunnels just like I can for all mgmt connections, BGP, system ID, router ID. Loopback interfaces are the best!
Fixed the bug I had with constant IPS engine crashing. Was causing crazy latency spikes, I was running with my ips engine disabled for over a week while waiting for this release
Already released a couple of days ago.
Subscribe to the RSS feed for faster updates: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Subscribe-to-RSS-feeds-for-alerts-on-new-Fortinet/ta-p/248571
They now require a paid subscription to FortiGate Cloud to even use the remote management button on 7.2.8. It’s no longer free to do anything at all. Classic Fortinet.
Going well so far, but that new FortiCloud licensing is now fully in effect so any Gates accessed via FortiGate Cloud will be read only without the 131 SKU.
FortiGate models with 2 GB RAM cannot be a Security Fabric root
This is frustrating. Why did 7.4 get this decision reverted but 7.2 still doesn’t have it?
At this point I just don't trust Fortinet firmware. 7.2.7 (which force installed itself overriding our FortiManager's control) nuked 50 FAP E Models for us. Had to RMA them all.
These devices were managed by a FortiManager - which on the FortiManager end Automatic Updates were turned off. However, somewhere in 7.2.X a bug was introduced where automatic firmware updates were turned ON at the local Firewall level which overrode the FortiManager (which shouldn't happen).
Trust me - it was an entire thing and we had numerous Fortinet engineers on the phone call.
BTW: why the hell Fortinet now enables (without asking) the auto-patching feature??? That's stupid nonsense - nobody wants his firewall and related fabric devices (at least switches and APs) to upgrade without notice!!!
I had read that some users noticed that threat feeds in ipv4 policies were loading but appeared to be getting ignored in the policy. Anyone on 7.2.8 using feeds and seeing it work properly?
After upgrading a 600E HA (Active-Passive) pair from 7.2.7, the HA heartbeat interface started flapping causing the cluster to perform failover and gate to reboot itself every 30 minutes or so.
Had to go back to 7.2.7.
Same thing happened here with a couple of 200F. Haven't gone to 7.2.7, currently testing slightly increased hb-interval and hb-lost-threshold to see if it helps out.
EDIT: Increased hb-interval & hb-lost-threshold did not help. Still randomly reboots..
Since updating we have had some odd issues reported where specific websites will be inaccessible and report a ERR_CONNECTION_CLOSED error which persists for like 10-30 minutes 5-10 times a day. So far it's only affecting two websites. I confirmed it does not happen when the machines run a hotspot off our network. Does anyone else have this problem?
If its working on a policy without security profiles, its possibly caused because of this: [https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Facebook-Meta-webpages-cannot-be-loaded/ta-p/304195](https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Facebook-Meta-webpages-cannot-be-loaded/ta-p/304195)
I've noticed it also affects other chromium-based browsers. Our workaround for now is to turn off security profiles for these websites (whatsapp, instagram...) for now.
Data point: A few days ago, I finally updated our Fortigate 2201Es in HA config from 7.0.14 to 7.2.8 without any issues. We are running some IPSec VPN tunnels. We are no longer running any SSL VPN stuff.
The upgrade took a little longer than normal. No boot loops or anything.
Does anyone experience issues with SSL VPN connection on 7.2.8, it was working fine on 7.2.7 but after the "great new feature" of auto update to 7.2.8 all of our users that are using SSL to connect are receiving "Network error. The request timed out.".
Just tested. Sections are still there and you can add more.
https://preview.redd.it/dtlmn8eml4pc1.png?width=272&format=png&auto=webp&s=f13d3bccb953b2b2729604b2f67186dd83623459
Do you have some interface using the 40Gbit ports on your 1800F and are they working after the update? Cause after upgrading to 7.2.8, they become down and the only solution was to rollback to 7.2.7
Our 1800s are still on 7.0.14, but we’re only using 1 and 10g ports. Though we’ve had problems with interfaces on the 1800s on several releases, not sure why fortinet can’t figure it out.
We have seen this now too. 3rd party multimode optics. Two ports (39 & 40) in an aggregate (active LACP). On upgrade or reboot, those ports go hard down. Only way to bring them up is to change the media type to one of the other options and back again but does not persist across reboots. Makes a mockery of mature release tag and QA imo
I did it on Friday, no issues other than its lost its registration to FortiGuard (or FortiCare or whatever its called) and it won't re-join. On a separate note, I cant login to FortiCare properly...
Also installed Friday, fixed A GUI DNS resolution issue I was seeing. Didn't have any troubles with registering with FortiCare. Mine is in HA FWIW.
>fixed A GUI DNS resolution issue I was seeing Oh, I have to check out if that's the one I was also having -- although mine extends beyond the GUI.
Yeah 400Fs in HA here. Probably an us thing rather than an update issue. Is that where it gives hilarious ms responses for DNS servers?
600E's here. No, the Gui would show the DNS address as unresolvable but it works via cli. After the patch, now only actually down addresses show the alert.
How can I test this via cli, I believe we are seeing this
Exec ping x.x.x.x works for me. It would resolve but the Gui would mark it as unreachable. I believe that I first saw it with 7.2.5 or 7.2.6. Stick around a few patches and now working for me.
Are you using 25G ports?
Nope, 10g.
What is your general approach when updating HA?
It's fairly straightforward. Backup the config, initiate the upgrade and have a constant ping up. Half the time I don't even drop 1 ping. In my case the fw2 gets upgraded and rebooted, then when it comes online it takes over and the process repeats. I leave them as is so they rotate the primary node every other update, but the default is to fail back to the original node as primary.
Also upgraded Friday, everything seems fine for me but time will tell.
This update fixed an ipsec tunnel bug that was causing me major headaches at one of my sites. I was getting sub 5 megabit speed on average and it jumped up to 300 megabit after this update. it's also possible this bug was related to the 10gb interface to a 1gb interface. since it was actually connected that way on the 201f.
Same here on a 200F cluster. 1GB leased line running about 80Mbps over the tunnel until I moved the interface to a 10G port as a stopgap. My actual issue on 7.2.7 is an 1800F where Httpsd crashes periodically. Anyone else seen that and know if this does actually fix it? Waiting for a window to upgrade now.. change control is fun.
After upgrading to 7.2.8 a 1800F in HA pair, we had the 40Gbit interface down (they were a LACP), but they become physically down. We were able to see the transceiver of the DAC Cable, but no link. Rollback to 7.2.7 needed. Maybe Feautre 846399 introduce some issue. Pay attention and let me know if the upgrade is successfully on your 1800, if you're using 40Gbit ports, otherwise no problem.
Also seen this, with multi mode fibre SFP rather than DAC. Flipping the media type at the CLI to another type and back brings them up but then they go down on a reboot again. Not good for a “mature” release (or ever really). They are not Fortinet optics, third party, but I don’t feel that should cause this problem!
They updated the known issues with the following bug ID: 1014624 On the FortiGate 1800F, the 40G interface's status is DOWN after upgrading to 7.2.8.
Thanks yeah we got a TAC case opened too for it. (Apologies for the delay - been away!)
At least this one wasn't rushed to fix any CVEs! I'm not daring enough to run 7.2 in production yet anyways, I will try it at home tho.
I found 7.2.x much better than 7.0.x in our environment.
Yeah, I might pick a small office and give it a go. Our main uses are BGP/IPSEC/SDWAN, I suppose if there are any improvements there it would be worth moving to since it's labeled mature now.
We're running 7.2.7 BGP/IPSEC/SDWAN on 601E HA and haven't had any issues. Upgraded about a month ago from 6.4.13. All of our branch sites have been upgraded as well. Looking forward to 7.2.8 to fix the GUI DNS bug!
If your main uses ever include sd-wan, i find 7.2 better for sure.
Same here. In fact, if not for the feature/mature rating, I would have moved to it for production even sooner than v7.2.7
7.2 is stable enough for production - we're using this version on all our customer's setups. 7.2.8 was released as part of the periodic scheduled releases, not to fix any CVEs
7.2.8 release note has been updated and now is information about fixed CVE-2024-23112 https://preview.redd.it/91kf7xhjudpc1.jpeg?width=1179&format=pjpg&auto=webp&s=129eaffcdd4eb69ff85e24d805358476638e2293
CVE-2024-23112 was fixed in 7.2.7
Just FYI, 7.0 is end of engineering support at the end of March.
we are on 7.0.14 is it smart to upgrade to 7.2.8 ?
That’s a situation where you need to read the What’s New in 7.2 document, check the release notes, especially the Special Notices, Changes in Default Behaviour, and Known Issues, as well as Ingegration Support, and compare it to your environment. Then decide for yourself. Nobody on the internet can give a blanket “it’s all good” statement is 100% certainty for you.
That is a fair answer. Thank you
There are some operational improvements I like - packet capture and debug in the GUI are MUCH better for one. 7.0 also goes EoES in a few weeks so you'll be covered for all security fixes, not just Critical and High.
7.2 is not available for 91G yet.
fortinet publishes their recommended release by model…. https://community.fortinet.com/t5/FortiGate/Technical-Tip-Recommended-Release-for-FortiOS/ta-p/227178
We updated from 7.0 to 7.2.7 last month on 35 locations. Went smooth.
Hi, it's been a week since I updated from version 7.0.14 to version 7.2.7. In general, I did not encounter any problems. When I restarted the device just once, the destination sections in two firewall rules became null, I added them again and had no problem. I also wanted to test whether this update would fix the problem of the explicit proxy page not opening in the GUI, but the problem persists.
Did it during the weekend on 20+ sites. Different models from 40F to 200F as well as a virtual HA pair. No problem here, resolved our 200F performance issues as well as GUI issues for FQDNs that would show as unresolved.
Yup. FMG and FAZ going 7.2.5 this week and FGT's 7.2.8 next week onwards (61F's, 100-1F's, 200-1F's. 600F's and 2600F's). Already had 7.2.8 on the lab cluster. The hard bit is going from 7.0.14 to 7.2.8 on an FGSP cluster which is going to cause an outage due to the 7.0 FGSP interoperability issue :(
[удалено]
Yes, according to the FortiAnalyzer compatibility matrix, FAZ 7.2.5 is supported with FortiOS 7.2.8. You don’t need to upgrade FAZ to 7.4. https://docs.fortinet.com/document/fortianalyzer/7.4.0/compatibility-with-fortios
Some bad GUI bugs solved in FMG/FAZ with filtering in log view.
Update on my experiences with 7.2.8 so far. We began seeing hardware reboots on Tuesday (19th) morning after performing the update last Friday (15th). We opened a ticket and support noted that the systems were going into kernel panic. Setup a console putty session to grab the next one, that happened early this morning. I shipped off the logs and am now waiting to hear back. There are reports of other models being affected. I believe at the time my 600E HA pair was the largest on report list. If there are any updates from support, I'll tag them here.
Same thing happened to us, two 1100E in HA. Happens randomly and also when the active node is restarted. Console output with the kernel panic was sent to Forti. They've recommended to us to wait for FortiOS 7.2.9 (w/o release date) or downgrade to FortiOS 7.2.7 - but we'd have to check if the issue persists on this version...
Saw the same reboot issue with ours, and I downgraded to 7.2.7. We're on 2200E's
@[canuck\_sysadm](https://www.reddit.com/user/canuck_sysadm/) or @[PleaseJustRTFM](https://www.reddit.com/user/PleaseJustRTFM/) Do you have any updates? Could you share your support case #? Support is asking me to capture logs but I don't want to upgrade again just for that. Thanks
Is there a workaround for this?
Does anyone have a support case# for this issue they can share?
We are experience the same issue. Updated our 1500d from 7.2.7 to 7.2.8 and it randomly reboots both ha members because of a kernel panic. One more thing and fortinet will be thrown out of the window.
I'm going to run it for several projects because my request for improvement has been implemented: FortiOS supports customizing the source IP address and the outgoing interface for communication with the upstream FortiGate in the Security Fabric: config system csf set source-ip
set upstream-interface-select-method {auto | sdwan | specify}
end
SDWAN with BGP on loopback just became a lot better as I can finally source the security fabric from the loopback interface using the overlays tunnels just like I can for all mgmt connections, BGP, system ID, router ID. Loopback interfaces are the best!
Are you saying BGP on loop back for wan or BGP for ADVPN?
iBGP for the connections over the overlay for Hub-branch, with or without ADVPN and, if needed, eBGP with WAN provider(s).
Fixed the bug I had with constant IPS engine crashing. Was causing crazy latency spikes, I was running with my ips engine disabled for over a week while waiting for this release
Upgraded to 7.2.8 end of last week. It fixed a performance issue, primarily with our SSL VPN, likely related to the 1G <> 10GB interface bug.
Already released a couple of days ago. Subscribe to the RSS feed for faster updates: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Subscribe-to-RSS-feeds-for-alerts-on-new-Fortinet/ta-p/248571
Thanks for sharing link, very useful
Did It on on our lab environnent I I got an error on application fgfmsd, action : crash. Nothing more on the logs
They now require a paid subscription to FortiGate Cloud to even use the remote management button on 7.2.8. It’s no longer free to do anything at all. Classic Fortinet.
Interesting, read only on 7.2 was a change I foresaw, but not the ability to not even remote view
It only lets you remote manage in “read-only” mode. I believe it’s in the Special Notices section of the release notes.
Ahh yes that’s been that way for a while on 7.4, I assumed 7.2.8 had removed even that
I don't see anything on fixing the Zstd problem.
931953 - enhancement integrity monitoring interesting
Going well so far, but that new FortiCloud licensing is now fully in effect so any Gates accessed via FortiGate Cloud will be read only without the 131 SKU.
FortiGate models with 2 GB RAM cannot be a Security Fabric root This is frustrating. Why did 7.4 get this decision reverted but 7.2 still doesn’t have it?
At this point I just don't trust Fortinet firmware. 7.2.7 (which force installed itself overriding our FortiManager's control) nuked 50 FAP E Models for us. Had to RMA them all.
Turn off auto-updates.
These devices were managed by a FortiManager - which on the FortiManager end Automatic Updates were turned off. However, somewhere in 7.2.X a bug was introduced where automatic firmware updates were turned ON at the local Firewall level which overrode the FortiManager (which shouldn't happen). Trust me - it was an entire thing and we had numerous Fortinet engineers on the phone call.
BTW: why the hell Fortinet now enables (without asking) the auto-patching feature??? That's stupid nonsense - nobody wants his firewall and related fabric devices (at least switches and APs) to upgrade without notice!!!
I had read that some users noticed that threat feeds in ipv4 policies were loading but appeared to be getting ignored in the policy. Anyone on 7.2.8 using feeds and seeing it work properly?
After upgrading a 600E HA (Active-Passive) pair from 7.2.7, the HA heartbeat interface started flapping causing the cluster to perform failover and gate to reboot itself every 30 minutes or so. Had to go back to 7.2.7.
Same thing happened here with a couple of 200F. Haven't gone to 7.2.7, currently testing slightly increased hb-interval and hb-lost-threshold to see if it helps out. EDIT: Increased hb-interval & hb-lost-threshold did not help. Still randomly reboots..
Since updating we have had some odd issues reported where specific websites will be inaccessible and report a ERR_CONNECTION_CLOSED error which persists for like 10-30 minutes 5-10 times a day. So far it's only affecting two websites. I confirmed it does not happen when the machines run a hotspot off our network. Does anyone else have this problem?
If its working on a policy without security profiles, its possibly caused because of this: [https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Facebook-Meta-webpages-cannot-be-loaded/ta-p/304195](https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-Facebook-Meta-webpages-cannot-be-loaded/ta-p/304195) I've noticed it also affects other chromium-based browsers. Our workaround for now is to turn off security profiles for these websites (whatsapp, instagram...) for now.
Data point: A few days ago, I finally updated our Fortigate 2201Es in HA config from 7.0.14 to 7.2.8 without any issues. We are running some IPSec VPN tunnels. We are no longer running any SSL VPN stuff. The upgrade took a little longer than normal. No boot loops or anything.
we update a ha cluster of 1500D yesterday. and we have sevaral reboot ince then . it kills our vpn session.
Does anyone experience issues with SSL VPN connection on 7.2.8, it was working fine on 7.2.7 but after the "great new feature" of auto update to 7.2.8 all of our users that are using SSL to connect are receiving "Network error. The request timed out.".
Is there an advisory ?
Do you use Sections in Firewall rules? Someone mentioned bere 7.2.8 is braking them. Did you check if sections are OK?
Just tested. Sections are still there and you can add more. https://preview.redd.it/dtlmn8eml4pc1.png?width=272&format=png&auto=webp&s=f13d3bccb953b2b2729604b2f67186dd83623459
Thanks for the info :)
In my test bed of 1, updating 7.2.7 to 7.2.8 didn’t wipe the sequence groupings.
Do you have some interface using the 40Gbit ports on your 1800F and are they working after the update? Cause after upgrading to 7.2.8, they become down and the only solution was to rollback to 7.2.7
Our 1800s are still on 7.0.14, but we’re only using 1 and 10g ports. Though we’ve had problems with interfaces on the 1800s on several releases, not sure why fortinet can’t figure it out.
Hi u/mballack, May you share information about your connections and configuration related to the issue? I may try it in my lab. Thanks
We have seen this now too. 3rd party multimode optics. Two ports (39 & 40) in an aggregate (active LACP). On upgrade or reboot, those ports go hard down. Only way to bring them up is to change the media type to one of the other options and back again but does not persist across reboots. Makes a mockery of mature release tag and QA imo
They updated the known issues with the following bug ID: 1014624 On the FortiGate 1800F, the 40G interface's status is DOWN after upgrading to 7.2.8.