Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
New Contributor III

Unusual Firewall Policy behavior For SSL VPN

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.

Community Manager
Community Manager



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.



Anthony-Fortinet Community Team.

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:


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.

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
New Contributor III

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.

Top Kudoed Authors