Restricting VPN remote network access

[Landis]

I am looking to setup some VPN tunnels that allow our SSL VPN network access to the remote networks. I would like to be able to restrict access to only allowed users (we have the LDAP external connector setup already). I run into the issue when creating the firewall policy that simply selecting the User OU as the source, the following error is displayed: One address, address group, external resource or Internet service is required. 

I can add that the source is the SSL VPN group, but that would include access for everyone to that remote network. And of course, the tunnel has to be setup with all the networks negotiated in the Phase 2 options of the tunnel. I just need to be able to then restrict it down from a specific network for specific users, assuming that is even a possibility. We are using 201F firewalls. 

Thanks

[AEK]

When you add a user or group as source you must also add an address object as source.

Typically you add the address range or subnet from which the users connect, or just "ALL".

[Landis]

Appreciate the reply, wouldn't adding the whole IP range source with the user group actually just allow that whole range to have access according to the policy?

[AEK]

No it will not.

Allowing user with IP range source in policy will only match if that user connects from that range.

[mauromarme]

Hello @Landis 
You are talking about a SSL VPN Setup but also mention Phase 2 tunnel networks. Which makes me feel a little confused.
We can create some Portal Mapping Rules for SSL VPN.
Under SSL VPN settings, you can map group of users to specific "Portals"
Each portal can have different Split Tunneling configurations, which would allow you to control who can access specific internal resources.

Regards,

[Landis]

Fair point... I should clarify. 

We have a single SSL VPN connection to our main site that the firewall acts as a DHCP server. Our main site also has several tunnels to our remote sites that only allow certain internal networks access to the remote networks, negotiated through the Phase 2 settings of the VPN tunnels. Currently the SSL VPN DHCP scope is not included in those Phase 2 negotiations because we don't want everyone that uses the SSL VPN connection to have access to all the remote sites, just a select few.

I thought that we might be able to set up a firewall policy that specifies the users that need access and then a rule right after that to deny everyone else from the SSL VPN network. But this is where I receive the error that states: One address, address group, external resource or Internet service is required.  I thought the user would include the IP address since its integrated with the FSSO agent that runs on our AD Server, but apparently it doesn't work that way. 

[mauromarme]

Landis,

Thank you for providing clarification.

When creating SSL VPN Policies, it's essential to specify the group of users applicable to that policy. As a user is logged in, all traffic generated from that SSL VPN Client would include the username, directing it to the relevant policy.

Regarding your concern, I believe utilizing Portal Mapping might resolve this. Configuring Portals enables control over the access each group of users should have.

For instance:
- Group of Users - Admin -> Mapped to ADMIN PORTAL
- They can access 172.16.0.0/24
- Group of Users - Contractors -> Mapped to CONTRACTOR PORTAL
- They are restricted to accessing only 172.16.0.16/24

By implementing this setup, you can configure the phase 2 selector for the SSL VPN subnet. Even if the phase 2 selector includes the whole subnet, the SSL VPN rule only permits certain user groups to access specific segments of the remote network. This means that policy enforcement occurs at the SSL VPN Authentication Level, rendering the phase 2 selector's inclusion of the entire subnet inconsequential.

Regards,

[Debbie_FTNT]

To elaborate a bit on Mauricio's response:

- IF you use SSLVPN portals for different groups, AND use split-tunneling, you can set different split-tunneling addresses in different SSLVPN portals. This essentially means that a connecting SSLVPN client only receives certain routes, and a user connecting to portal1 would get different routes (and thus different access) compared to a user connecting to portal2.

This will not work if you do not utilize split-tunneling and ALL user traffic is routed via SSLVPN.

In principle, a single policy should be sufficient:

-> source ssl.root, and sslvpn tunnel IP ranges

-> destination IPSec tunnel interface and applicable source/destination

-> set whatever user groups you want to restrict the access to

-> when users authenticate via LDAP for SSLVPN, FortiGate queries LDAP for ALL usergroups of the user (by default at least) and matches that to existing group objects on FortiGate to determine what groups a user is member of

--> if you set up a simple user group with filter on a particular LDAP group, and then set this user group in the proposed policy, the following should happen:

- User1 connects to SSLVPN, authenticates to LDAP, FortiGate gets membership information over regular group and restricted group

- User2 connects to SSLVPN, authenticates to LDAP, FortiGate gets membership over only regular group

- the policy from SSLVPN to IPSec is set with restricted group

-> only user1 matches this policy, user2 will NOT match the policy

-> as long as there is no other policy user2 can match into, user2 will not have access to IPSec VPN or any resources behind it

-> you do NOT need to configure an explicit deny policy to achieve this