This FortiManager does not support the discovered device model and firmware version combin

Matthew Mollenhauer wrote:

There be dragons here!!!!

 

I have just finished upgrading our 1500D DR cluster from 5.0.9 to 5.2.1 using the FortiManager, and there are major issues....

 

As 5.2.x uses UUID's on most objects the FGT will assign UUID's during the upgrade, no major issue yet. But as soon as you go to do a config install the FortiManager will delete all policies that have a UUID that does not match what it think it should be.

 

Of ~550 policies in our DR vdom the FMG was wanting to delete over 400...

 

This reeks of poor testing and no QA....

 

Regards,

Matthew

 

I decided to do the upgrade, and I had a similar thing happen. Everything appeared to work just find during the upgrade. However, the next day I had a teammate notice they lost connection to a server sometime after the upgrade. I looked in Fortimanager, everything looked fine. I logged directly into the firewall in read only mode, and noticed the policy was different than what was in FM, maybe only 1/2 the rules were there. Went back to FM, and it said the policy, device, etc. is all synced and happy. I re-installed the policy, FM says it was successful, but back on the firewall itself, only about 1/2 the policy was there.

Thankfully, that one server was the only production system being protected by the Fortinet firewall, and it was easy to move the server to our old firewall to get it running again. But it looks like I will have to wait for yet another update before I think about putting these new Fortigates and Fortimanger into production.

Thanks for the feedback everyone.

scao_FTNT wrote:

Hi, Flyshuffle

 

For previous Matthew's case, that case is for install FMG 5.0 ADOM policy package to 5.2 FGT and because FOS 5.2 re-designed policy (for example, 1 policy with multiple identity rule will become multiple policies after upgrade to 5.2), so FMG re-organized policy with new policy ID, and triggered policy delete and re-install

 

Not sure if this is similar case as your FMG/FGT env? and not sure if you can send me the FMG install log for further investigation?

 

Thanks

Simon

Simon,

That's not actually true in my case, the vdom I reported the issue with has not identity based policies.

The cause that I can see is the new UUID's introduced in 5.2.0. During the upgrade the Fortigate is generating UUID's for it's policies and then when the FortiManager goes to do an install the UUID's that it (FMG) has don't match. This results in the FMG deleting policies that have the mismatch (in the case I raised it happens to delete all policies) and then installs what it thinks are correct policies.

In the brief testing I did on our Backoffice vdom on the same unit, which has only 56 policies, the initial install tried to delete about half the policies and then it was only able to install a couple of the deleted policies, eg; 56->26->32.

Subsequent installs resulted in the Fortigate only having 26 policies. As this vdom is only responsible for a couple of Backoffice DMZ services I decided to delete all policies from the Fortigate and then allow the FortiManager to install it's policies. This returned all 56 policies.

Simon, as I said in the TAC case

If I was to have performed an install on our Fortigate without first checking what was going to happen our entire DR site would have gone offline, consider now a customer that doesn't test these things as rigorously and they will take down their production environment.

Regards,

Matthew