- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Firewall group mismatch from VPN SSL group
Hello,
We configured the VPN SSL authentication using SAML (Azure AD) successfully for some groups.
To distinguish profiles, we mapped different groups with specific realm+portal.
Firewall group A = default realm + portal A
Firewall group B = realm B + portal B
Firewall group C = realm C + portal C
Both groups A & B mapping work perfectly, allowing users to connect to multiple realms depending on the device they are using (portal A for workstation, portal B for mobile device, portal C for limited users)
The firewall policies work for firewall group A and group B however, users which are in group C are blocked whenever they are correctly connected to the SSL-VPN with their group.
The ACL for group C is nearly the same as the groups A & B :
- Source IP : Group C pool IP
- Source group : Group C
The result is packets are dropped because the implicit firewall rule.
We found out that there is a difference when we check the group membership on VPN SSL and Firewall user part.
On the VPN SSL monitor :
get vpn ssl monitor
SSL-VPN Login Users:
Index User Group Auth Type Timeout Auth-Timeout From HTTP in/out HTTPS in/out Two-factor Auth
0 user_fromgroup_C Group_C 256(1) 3596 27949 X.X.X.X 0/0 0/0 0
SSL-VPN sessions:
Index User Group Source IP Duration I/O Bytes Tunnel/Dest IP
0 user_fromgroup_C Group_C X.X.X.X 850 126/86 Y.Y.Y.Y
From the FW user list
diagnose firewall auth list
Y.Y.Y.Y, user_fromgroup_C
type: fw, id: 0, duration: 952, idled: 952
expire: 27847, allow-idle: 28799
flag(80): sslvpn
server: AzureAD
packets: in 0 out 0, bytes: in 0 out 0
When we compare with the other user from group A or group B, it seems to be missing the "group_id" and "group_name" parts.
We tested with a new group D, new realm D, new portal D, same authentication/Portal mapping we did for Group A & Group B and we are facing the same issue.
Is there any kind of limitation or a missing parameter on our portal / realm / ACL / VPN SSL settings configuration ?
Solved! Go to Solution.
- Labels:
-
FortiGate
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Upgrading to the last 7.2.X firmware version yesterday fix the issue. The user is now is the correct group regarding FW policies and everything works fine !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
Usually while connecting to VPN, should match to the group, portal and policy as well.
However, to check why user is not able to connect VPN it will be helpful with SSLVPN debug logs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
User can connect to the VPN SSL without issue and has access to systems which are reachable allowed to a specific subnet (10.253.255.0/24 as source address into the ACL)
The issue is more likely when this user tries to reach a system which is only allowed to a specific FW group + subnet (10.253.255.0/24 + Group_C as source address into the ACL).
We can see from the VPN SSL users list this user is part of the group "Group_C", even when connecting.
However, in the Firewall Users list, he has no group assigned :
We can't find the correct logs filter to check when the authentication happens as it is using the AzureAD SSO so we are a bit lost to go further for troubleshooting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
Upgrading to the last 7.2.X firmware version yesterday fix the issue. The user is now is the correct group regarding FW policies and everything works fine !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
what was Your previous Fortigate firmware version that you had SAML group issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It was 7.2.3, we were "pushed" to go to 7.2.5 after the last news from Fortinet.
