Multiple ID based policies failing in 5.0.x - 5.0.1

[Geom]

So I took the jump this weekend and upgraded from 4mr3 train to 5.0.1. Bad idea. At my site we use user authentication to protect some sensitive networks (about 40). Policies are configured to match against specific groups in AD based on the destination of the traffic. Unfortunately Fortigate decided that they would simply remove the ability to do authentication based on destination from policies in 5.x. There is a one line sentence in the release notes for 5.0 that states this. Unfortunately, it does not mention user authentication or anything like that. They refer to it as ID-Based policies. While accurate it does not do a very good job of calling out the change. I realize this is a feature many may not be using, but it is a critical function for us. Way to go Fortinet on removing working features. This isn' t the first time this has happened either. There is simply no way to know if an upgrade is going to work with the features you are using anymore and you have to play detective to hopefully find all the crumbs they put in their release notes. Other vendors have upgrade utilities and ways to check configurations. Fortigate.. nothing to my knowledge. I certainly appreciate new features, but I would more appreciate not losing my entire weekend because the new features they put in, were put there at the expense of features I was already using. -GM

[Jordan_Thompson_FTNT]

Can you elaborate on your topology? Can you give an example of a policy that worked for you in 4.3 that will not work in 5.0?

[Geom]

From a high level, we have a set of untrusted networks that may need to go into a set of protected networks. The protected networks have amonst other things, user authentication placed on them so that when a user tries to access them, they must first enter user/pass creds. We have about 40 of these protected networks. In my firewall policies, I have each policy set to authenticate a user based on their destination. So for instance, untrusted network going to protected network1. Protected network 1 will have a specific ldap group assigned to it. protected network2 would have a different group, and so on for about 40 fw policies. In 5.0 they removed the ability to have a firewall policy that was using identity based user authentication be configured using a destination network. There was also no log information upon boot, and no warning anywhere. The upgrade just changed all these rules and removed the destination parameter. So the only policy that applied to anything was the first one that was configured in the policy order. Below is an example of before and after policies: Before

     edit 271
         set srcintf " any" 
         set dstintf " zn-RED-PROJECTS" 
             set srcaddr " grp-RFC1918"              
             set dstaddr " net-10.166.40.0/24"              
         set action accept
         set comments " project maui" 
         set identity-based enable
             config identity-based-policy
                 edit 1
                     set schedule " always" 
                     set utm-status enable
                         set groups " ldap-prj-maui"                          
                         set service " ANY"                          
                     set av-profile " av-standard" 
                     set ips-sensor " ips-standard-srv" 
                     set profile-protocol-options " po-standard" 
                 next
             end
     next
 

After:

     edit 271
         set srcintf " any" 
         set dstintf " zn-RED-PROJECTS" 
         set srcaddr " grp-RFC1918" 
         set action accept
         set comments " project maui" 
         set identity-based enable
             config identity-based-policy
                 edit 1
                     set schedule " always" 
                     set utm-status enable
                     set groups " ldap-prj-maui" 
                     set dstaddr " net-10.166.40.0/24" 
                     set service " ALL" 
                     set av-profile " av-standard" 
                     set ips-sensor " ips-standard-srv" 
                     set profile-protocol-options " po-standard" 
                     set deep-inspection-options " po-standard" 
                 next
             end
     next
 

[Jordan_Thompson_FTNT]

It' s not removed, destination address is part of the split policy criteria now. You can see " set dstaddr net-10.166.40.0/24" within your identity-based policy rule.

edit 271 set srcintf " any" set dstintf " zn-RED-PROJECTS" set srcaddr " grp-RFC1918" set action accept set comments " project maui" set identity-based enable config identity-based-policy edit 1 set schedule " always" set utm-status enable set groups " ldap-prj-maui" set dstaddr " net-10.166.40.0/24" set service " ALL" set av-profile " av-standard" set ips-sensor " ips-standard-srv" set profile-protocol-options " po-standard" set deep-inspection-options " po-standard" next end next

[Geom]

It is removed from the firewall policy so traffic does not match based on the destination anylonger. I agree it is in the id based portion, but it does not have any effect. This is from the release notes for 5.0 on page 17:

ID-based firewall policy will not use destination addresses as the behavior in FortiOS v4.0 MR3.

Work around Need to re-arrange the sequence of the firewall policies that are below the identity based policy. If any of the firewall policies that are below the identity based policy has the same source as the identity based policy, those polices will not be hit. You would need to move those firewall policies above the identity based policy

This sort of presumes you have only one id based policy. That is not the case in my environment, and so the work around does not actually function.

[Jordan_Thompson_FTNT]

I see. In 5.0.2, there is a new option that might help with this type of topology. For each identity-based policy, you can enable an option to fall-through to the next identity-based policy in order. In short, the option skips the implicit deny at the end of each identity-based rule set. Perhaps you can try it out and provide some early feedback on the new option after 5.0.2 is available?

[Geom]

I had opened a ticket regarding this. What you said previously was correct. It hadn' t occured to me that instead of having 30-40 individual policies with the destination network in them, I should have one with individual id-policies within the firewall policy. I haven' t tested it to be sure it works, but I am fairly certain this will resolve my problem. Unfortunately I can' t really configure it until I am on 5.x, which means I have to munge a bunch of rules together right after upgrade. Not exactly a seemless upgrade process. Below is what I plan to do:

 edit 271
 set srcintf " any" 
 set dstintf " zn-RED-PROJECTS" 
 set srcaddr " grp-RFC1918" 
 set action accept
 set identity-based enable
 config identity-based-policy
 edit 1
 set schedule " always" 
 set utm-status enable
 set groups " ldap-prj-maui" 
 set dstaddr " net-10.166.40.0/24" 
 set service " ALL" 
 set av-profile " av-standard" 
 set ips-sensor " ips-standard-srv" 
 set profile-protocol-options " po-standard" 
 set deep-inspection-options " po-standard" 
 next
 edit 2
 set schedule " always" 
 set utm-status enable
 set groups " ldap-prj-x" 
 set dstaddr " net-10.166.41.0/24" 
 set service " ALL" 
 set av-profile " av-standard" 
 set ips-sensor " ips-standard-srv" 
 set profile-protocol-options " po-standard" 
 set deep-inspection-options " po-standard" 
 next
 end
 next