Skip to main content
IlyaK97
IlyaK97
New Member
July 17, 2025
Question

IPsec VPN user and group based restrictions

  • July 17, 2025
  • 1 reply
  • 1607 views

Good evening,

 

We have a issue regarding a IPsec remote access VPN configuration. We now have to covert entirely to IPsec VPN (no ssl-vpn anymore) and we are having issues with configuring user and group based restrictions. We want to create 3 tunnels which will use 3 user groups which have users that have a external Radius server for authentication (everything works fine in that part). We want to create a policy for each group, which will have access to 3 servers, and then add access to other servers for specific users. We are using Fortimanager, and a sample configuration is

 

Incoming interface :  ipsec-VPN-Tunnel

outgoing interface : local-area network

source:  172.17.0.0/28 + user1

destination: server 1, 2 and 3

 

Problem is, the Fortigate allows all the users in the  172.17.0.0/28 to access these resources, not only user 1. We also tried enabling the "security mode: captive portal" option on the tunnel interface and allowed only the logistics department as the group, and then modified the policy and added the logistics group as the user. When we enabled that, no users has access anywhere, so the traffic was all dropped. We also tried creating a separate policy for all users in the group but that also blocked all traffic.

 

Is there any tips or even better a whole tutorial or thread on this platform that discusses this issue, and any best-practices for this config.

 

 

Thank you!

 

1 reply

esalija
Staff
esalija
Staff
July 18, 2025

Dear @IlyaK97 

To address the issue of configuring user and group-based restrictions for IPsec VPN on FortiGate, follow these steps:

1. - Ensure that each user group is correctly configured in FortiGate. You should have three distinct user groups corresponding to the three tunnels.

2. - Verify that each IPsec VPN tunnel is correctly associated with the respective user group. This can be done by setting up the correct phase 1 and phase 2 configurations for each tunnel.

3. - Create separate firewall policies for each user group. Ensure that the source address includes both the IP range and the specific user (e.g., `172.17.0.0/28 + user1`).
- Set the destination to the specific servers (e.g., server 1, 2, and 3).
- Ensure that the policies are ordered correctly, as FortiGate processes them from top to bottom.

4. - If using the captive portal, ensure that it is correctly configured to authenticate users against the external RADIUS server.
- Double-check the settings to ensure that the correct user group is allowed access.

5. - If traffic is being blocked, check the logs to identify where the traffic is being dropped.
- Ensure that the policies are not being overridden by other policies that might allow broader access.

6. - Use explicit firewall policies for each user group and specific users.
- Regularly review and audit the policies to ensure they align with your security requirements.

Please check the KB for details - https://community.fortinet.com/t5/FortiGate/Technical-Tip-Allow-IPsec-VPN-ports-and-protocol-access-to/ta-p/251878

Best regards,
Erlin

    IlyaK97
    IlyaK97Author
    New Member
    July 18, 2025

    Hello Esalija, thank you for your reply.

     

    We identified this issue this morning although we encountered another issue which we suspect is a bug. We have added 20 RADIUS users, where authentication works fine, and users can log in and access their platforms. The issue is, in 12 of the 20 users a captive portal appears randomly, in the time they log in (for example the captive portal does not appear on the first log in although it appears in the second and third), even though "security mode" is disabled in the tunnel interface and we chose the "Exempt from captive portal" option on our policy (both via GUI and CLI). This policy is a test policy, and we made sure that there were no other policies or configurations that can cause this issue.We suspect this is a bug since it happens randomly and without a clear cause, and affects random users that use the same authentication method.

     

    For informational purposes, the first issue was caused by the captive portal, where no traffic was allowed without logging in, although we did not choose it as an option. That was quite a rabbit hole :)

     

    Is this a known bug and is there a workaround?

     

    Thank you!

    Terms & ConditionsAccessibility statement