Application Control - Change Application Sensor Issue

[pj255]

Hi,

When I need to change the application sensor, IPS sensor or web filter associated with a policy I need to drag the policy line right to the bottom of the ruleset above the implicit deny, change the UTM sensor or policy, then move back to the correct position.

If I dont follow this procedure then the policy loses all it's L7 inspection sensors.

Is this a bug ? We're running 5.0.7

PJ

[Dave_Hall · Accepted solution]

I have never personally experience this issue directly, but it's not uncommon for such issues to be the result of browser compatibility issues (try switching browsers and/or clearing browser cache, resetting browser to defaults). 

Just deployed some new 200Ds and migrated several 200B to 5.0.8 (wireless controller ver) and 5.0.9 -- Encountered 2 GUI-related issues so far (on the same 200D running 5.0.8 wireless controller build); I'm running the latest Firefox browser.

First "bug" is trying to add a new entry to a DHCP-reserved IP list that already has about 30 entries, clicking apply gives an error message then it wipes out the entire reserved IP list -- not a happy camper (had to copy/paste the IP list from an old backup into the CLI to restore the entire list).  Fortigate was no where near the max 200 reserved IPs as pointed out by the Maximum values table.

Second "bug" is related to the Block Intra-SSID traffic option on the SSID setting -- I just set up a new SSID, on a separate subnet, and enabled this option.  But later was told by the site admin that they can't print to their wireless printer, so I unchecked this option (from the GUI).  Site admin reports printer is still unreachable, nor even pingable.  I was able to ping all devices on that subnet from the Fortigate, but not from a test machine (via remote connection).  So I finally checked the setting via the CLI and discovered the option was still enabled even though the GUI shows it unchecked. >:(

I like stories. :)

[pj255]

Hi Dave,

Cheers for the response, I usually run Chrome but just tried with FF and IE, no joy, exactly the same issue...worth a shot though!!

Sounds like a bug to me. I also forgot to mention it happens if I amend the policy in anyway - like remove or add a new address object or service. 

I have tested on two separate platforms running slightly different code.

1000C's running 5.0 patch 7

90D's running 5.0 patch 9

Whats the best play from here you guys recon - open a case?

...and yes you do like stories...hahahahah

Dave Hall wrote:

I have never personally experience this issue directly, but it's not uncommon for such issues to be the result of browser compatibility issues (try switching browsers and/or clearing browser cache, resetting browser to defaults). 

Just deployed some new 200Ds and migrated several 200B to 5.0.8 (wireless controller ver) and 5.0.9 -- Encountered 2 GUI-related issues so far (on the same 200D running 5.0.8 wireless controller build); I'm running the latest Firefox browser.

First "bug" is trying to add a new entry to a DHCP-reserved IP list that already has about 30 entries, clicking apply gives an error message then it wipes out the entire reserved IP list -- not a happy camper (had to copy/paste the IP list from an old backup into the CLI to restore the entire list).  Fortigate was no where near the max 200 reserved IPs as pointed out by the Maximum values table.

Second "bug" is related to the Block Intra-SSID traffic option on the SSID setting -- I just set up a new SSID, on a separate subnet, and enabled this option.  But later was told by the site admin that they can't print to their wireless printer, so I unchecked this option (from the GUI).  Site admin reports printer is still unreachable, nor even pingable.  I was able to ping all devices on that subnet from the Fortigate, but not from a test machine (via remote connection).  So I finally checked the setting via the CLI and discovered the option was still enabled even though the GUI shows it unchecked. >:(

I like stories. :)

[ede_pfau]

@Dave:

Fortinet should be notified about these bugs. Any energy left to open a case?

- there should be a dropbox style mailbox where you could report bugs, real bugs I mean; a support case is some effort... -

[Dave_Hall]

I have considered that, but currently don't have the time/resources to properly document/research/replay the steps to replicate the "bugs", not to mention getting permission from the client to submit their Fortigate's config to Fortinet.  So far we have migrated/deployed about 12 fgts to 5.0.x and these two bugs are the only hiccups so far.