Skip to main content
Pacolo
Pacolo
New Member
September 30, 2016
Question

FortiOS 5.4.1 Issues

  • September 30, 2016
  • 1 reply
  • 24676 views

Hello everyone,

 

I have a cluster of 1500D in A-P mode working and I have noticed some rare issues since we upgraded to 5.4.1.

 

For example, after disable and enable again a policy route rule, on the GUI it was placed as SEQ #1, but when running a "diagnose firewall proute list" it was placed at the end of the policy rules.

 

Another one, a policy fw rule created on FortiOS 5.2.x (rule 41) doest not match traffic that is supposed to, another rule with the same config created on FortiOS 5.4.1 (rule 121) indeed match the same traffic.

 

Taking a view at the rule's full-config, the change of the new rule created in FortiOS 5.4.1 is "set utm-status enable" instead of "set utm-status disable". Although we have no utm feature enabled, it adds the following sentences:

set profile-type single set av-profile '' set webfilter-profile '' set dnsfilter-profile '' set spamfilter-profile '' set dlp-sensor '' set ips-sensor '' set application-list '' set casi-profile '' set voip-profile '' set icap-profile '' set waf-profile '' set profile-protocol-options '' set ssl-ssh-profile ''

 

Anyway, I changed to "set utm-status enable", and it did not match the traffic neither, so now I do not trust which rules created on FortiOS 5.2 are working on 5.4.

 

Other isssue would be that on another cluster of 1000D, the Virtual Wire config was lost after a reboot.

 

I am going to open a case about the rules's issues as they have given us a some headache, but I think we should downgrade to the 5.2 branch until the 5.4 is more stable.

 

Has anybody found similar issues?

 

Regards,

Paco.

 

 

 

 

    1 reply

    emnoc
    emnoc
    New Member
    September 30, 2016

     

     

     

    For example, after disable and enable again a policy route rule, on the GUI it was placed as SEQ #1, but when running a "diagnose firewall proute list" it was placed at the end of the policy rules.  

     

    That's normal behavior for all FortiOS. The route ID# is not a "SEQ" number as you indicated. It's a route ID and in the RIB it's still the exact match that wins regardless if it  a PBR or static-Route. Every route you populate in the   PBR will be placed at the end of the list regardless of the ID number you give it.

     

     

     

    You can check the  table via "get router  info routing-table  database" or the rt-cache  "

    diag ip rtcache  list" and monitor the use field for the  route that was selected 

     

     

     

    tanr
    tanr
    New Member
    September 30, 2016

    Paco, after your changes to the rule that had been converted from 5.2 to 5.4.1, what are the differences between the two rules full-configs?  

     

    Also, what is the rule supposed to be matching, exactly?  Have you confirmed which other rule (like the default deny) is actually matching the traffic?

     

    So far, with 5.4.1 I've run into two issues matching security policies:

    [ul]
  • The (documented) issue of a proxy-based Web Filter not catching what it should when using a flow-mode only Application Control profile.  Changing the Web Filter to a flow-mode version worked around this.
  • A non-reproducible issue where a security policy set to match Device Types (iPhone) failed to match devices of type iPhone that had been given an alias.  I saw this happen very obviously, then modified the rule and re-ran tests of this and was never able to reproduce it again.  This had happened after I edited the policy in the GUI directly from the list (clicking on the source subnet, then using the right pane to add device types) so its possible the issue is related to that sort of editing.  But as I said, couldn't repro it later.[/ul]

     

    If you got a reproducible difference in the way the rule gets handled this seems like a good issue to open a support ticket about.  

    • tanr
    tanr
    New Member
    October 3, 2016

    Spoke to soon.  I re-checked recent logs and found a repro of my second case where a security policy set to match a Device Type (iPhone) fails to match devices of type iPhone that have been given an alias, thus making them a custom device (though they still have type iPhone).

     

    When this occurs none of my security policies match (even my last any:any/all:all deny) and it drops to the implicit deny (rule id 0).  What is very weird is that this only seems to happen for a specific service that is a UDP range (Apple RTP RTCP) that the default IOS outbound security policy would have allowed.  The same custom device, with other services, is matching the rule and iPhone device type as it should for everything except that service.

     

    Looks like I'll be opening a ticket.

    Terms & ConditionsAccessibility statement