SSL VPN identity-based policy issues in 5.6.10

[commutator]

gbagita wrote:

rojekj wrote:

Beware, as this release has a major bug in SSL VPN. When uer is in multiple groups that grants different access in SSL VPN, only the first group is working. For example:

User x is in group vpn_a, and vpn_b, group vpn_a grants access to 1.1.1.1 and group vpn_b grants access to 2.2.2.2. After upgrading to 5.6.9, user can no longer access 2.2.2.2. After removing him from vpn_a group he can access 2.2.2.2 again.

Once again - our VPN gateway is broken after upgrade.

When it will be fixed? In 6 months? or 7? So I must live with vulnerable VPN till then?

Seriously, I don't have words for fortinets' QA. Because it does not exist!

I can confirm this. We have the same problem. Don't use this version of FortiOS, when you have have rules based on LDAP groups, and where one user is a member of two or more different groups!

This is a follow-up to posts (as above) in thread 5.6.9 is out: https://forum.fortinet.com/tm.aspx?m=174433 

We're having similar issues, have opened a ticket, and think it might be beneficial to cross-reference with other tickets on the same topic. I'd hoped upgrading to 5.6.10 would help but it did not. The release notes list the following as a resolved issue:

542706 With groups and its users in different SSL VPN policies and accessing resources via web, only user based policies are processed.

It appears to us that upon accessing an SSL VPN portal, an object is matched in the authentication/mapping rules of Settings as expected, but then only that object by name will be matched in policies to determine access. So if a group name is matched in the auth/map rules then only identity-based policies with that group name will be matched. Policies with other groups containing the authenticated user will not be matched. Nor will policies with the user listed individually. Similarly if a user is listed individually in the auth/map rules then only identity-based policies with the user listed individually will be matched.

In our case we are using local users and local groups. The local users authenticate using a RADIUS server rather than local passwords.

If you're having similar issues with users/groups on SSL VPN policies, and believe there is value in cross-referencing tickets, then please send me a PM. My thought is that multiple tickets reflecting different scenarios will result in a more complete description of the problem.

...Fred