Could someone confirm or comment on the following behavior for SSLVPN tunnels.
On older Fortigate firmwares I had users enables with Web mode and tunnel mode VPNs.
For Tunnel mode I create a separate user group for each firewall policy i.e. RDP_users, EchangeUsers, FileServer1_Users, FileServer2_Users.... This way I was able to easily assign the correct granular permissions to each user by assigning group membership. This has worked for years, but after upgrading to 6.4 all of that broke. The SSL-VPN tunnel mode firewall policies are ignored and only the WebPortal Firewall policy matches user traffic. If I add each individual users to each of the firewall policies it works. I called support and they told me that every individual User group needs to be separately added to the SSL-VPN Authentication/Portal Mapping. While that does work that does not seem right to me. Whay would individual users still work but not group, also it makes it impossible to make sure that when users create VPN bookmarks in the web protal that it is in the correct portal because the portal selection will match different VPN Authentication/Portal Mapping depending on what groups the user is a member of.
I cannot find anything in the release notes inticating this change, and I am wondering if it has been broken so long on the 6.4 firmware that support does not know how it is suposed to work and keeps using this workaround?
Any thoughts or suggestions would be greatly appriciated.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hello,
Did you try to have a look in our Knowledge Base? You may find an article which could provide a solution.
Just select Knowledge Base, the concerned product and you can easily make a search in our search bar.
Do not hestiate to come back to us if you do not find the solution.
Regards,
Hey J13224,
I'm not sure what you were told, but the users being member of a group, and that group being referenced in SSLVPN policies, should be sufficient to allow a user to authenticate. There was a bug in some early 6.4 versions where SSLVPN users would sometimes only match into one group even though they were member of several. The authentication/portal mapping is only important to determine what portal a user matches into; they do not impact if a user is allowed to authenticate in the first place or not.
If you are not on the newest 6.4 version, perhaps an upgrade would help.
How SSLVPN authentication works in general: https://community.fortinet.com/t5/FortiGate/Technical-Tip-A-quick-guide-to-FortiGate-SSL-VPN-authent...
If you still have the issue post-upgrade, I would suggest gathering this debug in CLI:
#dia de reset
#dia de app sslvpn -1
#dia de app fnbamd -1
#dia de en
Then try to log in, wait 30s, end debug:
#dia de dis
#dia de reset
That debug should show:
- the SSLVPN connection attempt
- authentication against remote authentication servers (if there are any)
- observed group memberships
- successful authentication via specific group and portal
That should give you some idea if the issue is with group memberships not being observed properly, an unintended portal is being matched, or what might be going on.
I am running the latest 6.4, but I will investigate the debugs.
Thank you!
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1709 | |
1093 | |
752 | |
446 | |
231 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.