FMG: Bug in interface mappings upon rollout?

[sw2090]

I try to eplain this to you:

if you create a mapping in the objects section of FMG Policy & Objects and you use an interface that already has a mapping you get notified about this and FMG reports that if you save this you are going to replace the old (=existing) mapping. 

So far this is fine. You get to know that there already is a mapping and you could choose wether you want to replace it or not. Everthing ok here.

If you use an interface e.g. in a policy but forget to do a mapping for all FGT this policy is to be rolled out to, the FMG will notice that upon its integrity checks it does before it rolls out anything. It will then prompt you for the missing mappings so you can complete them. So far this is fine too.

When you then choose an interface of the FGT to complete the mapping you get all interfaces of the corresponding FGT in the drop down and you do not see which already have a mapping. Also you get interfaces that cannot be used as destination or source interface in a policy on a FGT. If you now chose an interface that already has a mapping the FMG will override the existing mapping without any notice or comment. So you neither notice there already was a mapping on this nor that it was replaced unlike the usuall way I wrote in the first stanza. The next check will then end up with yet more missing mappings due to that and the same problem again.

Then there are interfaces you cannot use in policies, like the modem interface or the ssl.vpn interface or also all members of the WLLB (virtual-wan-link) Interface. If you chose one of these FMG accepts that as a mapping but then fails to roll that out to the corresponding FGT because the FGT doesn't accept it. You then see the corresponding error in the log.

If you have a load of FGT in your FMG (we have 20) this could rather mess you up and is very annoying. 

I consider this a bug or not been noticed by the developers even. Due to this I also openend up a ticket with TAC.

Maybe someone else ran into this issue and this might be helpful then.

[sw2090]

TAC replied on my ticket: they try to reconstruct this in a Lab setup to evaluate it...

[sw2090]

TAC say they cannot reproduce this in FMG 6.x so maybe it is fixed there. They're still trying with 5.4

[sw2090]

TAC say this is reproducable in FMG 5.4.x and they are making a note on this. As said this does not happen in 5.6.x or 6.0.x . 

I meanwhile have upgraded our FMG to 6.0.2...

[brazz_FTNT]

Hello, 

So if it is a bug , did they provide you with any info like bug ID or Fix schedule?

Cheers 

[sw2090]

hi,

TAC gave me no bug ID. They said they will inform the developers and that is does not exist in 5.6 and upwards.

So I upgraded our FMG to 6.0 and it should be gone now...

[sw2090 · Accepted solution]

BTW there is yet annother nasty bug in FMG 5.4.x:

Fortimanager destroys the order of your url filter entries upon rollout. This results in wildcard entries going to the top.

So if you have something like "allow this and this and this and this (all exempt) and then block anything else" you will get screwed by this ;)

This is a confirmed bug in 5.4.x (confirmed by TAC and I should have the bug id somewhere in that ticket) and it is still not fixed in 5.4 thus it is fixed in [strike]5.6[/strike] 5.4.4 and above.

"This issue is listed as 0423757 - URL Filter wrong order of block action entry.  It will be fixec in upcoming version 5.4.4 and 5.6.0" - said TAC.

[sw2090]

"I have reached out to some senior engineers regarding this issue in 5.4, to have it documented in some manner and determine what other steps we should take.  Many thanks again for reporting this behaviour. "

is exactly what TAC answered me.