Need Assistance with IPSec Tunnel Group-Based Access Control via Entra ID

[GaetanLabrecque]

1. Hello,

   I am currently setting up an IPSec VPN tunnel on our FortiGate firewall, authenticated via Entra ID (formerly Azure AD), and I am encountering issues restricting access to specific VLANs based on Entra ID user groups.

   Objective:

   We have successfully configured an IPSec VPN tunnel that allows users to connect and access our internal network (192.168.0.0/16) and VLAN 10 (10.10.0.0/16). However, we want to achieve the following:

   1. Existing Setup (Working):
      • All authenticated users can access the internal network and VLAN 10 without issues.
   2. New Requirement (Issue):
      • Users from a specific Entra ID group should only have access to VLAN 20 (10.20.0.0/16), and should not be able to access other subnets.

   ---

   Steps Taken:

   1. IPSec Tunnel Configuration:

      • Configured an IPSec VPN tunnel with Entra ID authentication (SAML).
      • Successfully tested the tunnel connection and access to the internal network.
      • Added Entra ID groups under User Groups (VPN - Access Vlan 20).
      • Assigned the correct SAML entity and certificates.

   2. Address Object Creation:

      • Created an address object for VLAN20_Pool (10.20.0.0/16) with the correct associated interface.
      • Created a user group in FortiGate linked to the SAML authentication server using the GUID of the Entra ID group.

   3. Firewall Policies Configured:

      • Rule 1: VPN_to_VLAN20

        • Incoming: FCT_SAML
        • Outgoing: VLAN 20
        • Source: User Group (VPN - Access Vlan 20), Address Object (VPN_Vlan20_Pool)
        • Destination: Vlan20 address (10.20.0.0/16)
        • Action: Accept
        • NAT: Disabled

      • Rule 2: VLAN20_to_VPN (Return traffic)

        • Incoming: VLAN 20
        • Outgoing: FCT_SAML
        • Source: Vlan20 address
        • Destination: VPN_Vlan20_Pool
        • Action: Accept

   4. Routing Configuration:

      • Verified that a static route exists for VLAN 20 (10.20.0.0/16) to the correct interface.
      • Removed and re-added any conflicting static routes.

   ---

   Current Issue:

   • Users belonging to the specific Entra ID group can connect to the VPN but cannot access VLAN 20 resources.
   • Pings to 10.20.1.10 fail and are logged as "Implicit Deny" in FortiGate logs.
   • However, users are able to ping and access other subnets (e.g., 10.10.0.0/16 and 192.168.0.0/16), which should not be allowed.
   • We suspect the Entra ID group association is not correctly applied or the firewall policy is not correctly matching the traffic.

   ---

   Questions:

   1. How can we ensure that only users from the specified Entra ID group are allowed access to VLAN 20?
   2. Are there additional configurations required to enforce group-based access control via IPSec with SAML?
   3. Are there any troubleshooting steps to verify if the group assignment is properly working?

   Any assistance or guidance would be greatly appreciated.

   Thank you in advance for your support.

   .

[Anthony_E]

Hello Gaetan,

Thank you for using the Community Forum. I will seek to get you an answer or help. We will reply to this thread with an update as soon as possible.

Thanks,

[Anthony_E]

Hello,

We are still looking for someone to help you.

We will come back to you ASAP.

Regards,

[funkylicious]

hi,

as per my understanding, you would like to separate access for different users/groups to different resources.

you could basically achieve that by create multiple groups on the FortiGate which will match a Entra ID security group where each user would be part of.

https://docs.fortinet.com/document/forticlient/7.2.0/new-features/712604/ipsec-vpn-saml-based-authen... , 

FortiGate can optionally map users to specific groups based on the returned SAML user.groups attribute. The example shows group matching based on Entra ID Group ObjectId, using the set group-name command

Then in the firewall rules you just specify which group to have access to which resources and it should work in theory, havent gotten a chance to test it yet.