Skip to main content
pj255
New Member
November 17, 2014
Solved

Application Control - Change Application Sensor Issue

  • November 17, 2014
  • 2 replies
  • 5857 views

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

Best answer by Dave_Hall

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. :)

2 replies

Dave_Hall
Dave_HallAnswer
New Member
November 17, 2014

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
pj255Author
New Member
November 17, 2014

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
SuperUser
SuperUser
November 17, 2014

@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
New Member
November 17, 2014

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.