What is best way to control vpn users acces via cisco ise

[User_80617]

Hello,

So, we have below requirement. We have firepower firewall and ciso ise version 3.1 on aws

Setup a VPN profile for around 75 vendors. Each vendor will have its own access. I see currently following options

1. Create single vpn connection profile on firepower. Create 75 authorization policies for each vendors on ise. So if user1 belongs to ad group vendor1, apply DACL to him pushed on firepower firewall. This seems good method as access policies will be applied for each user dynamically.

The problem with this approach is, suppose there are 300 users. There will be surge in DACLs on firepower. What is limit for an 6 core firepower container in terms of DACLs. Also, DACLs are checked first or the normal access policies will checked first? How scalable this option would be.

2. This approach i personally dont like but it works as well. So in cisco ise authorisation profile make user to put in a group-policy on firepower as per the ad group they belong to. There will be 75 group-policies on firepower (with single connection profile) and each group polciy will have a vpn-filter list configured that will control access to users.

3. I dont know if this works. So, here cisco ise informs firepower to assign the ip pool to each user as per respective ip pool defined for a vendor on firepower. And then the access control will be done on basis on access policy for ip pool. So, vendor1 and 2 will be assigned a pool 10.20.20.0/28 and allow them to get rdp of jump server 1. 

Can someone guide which is best way to implement this and some cisco documentation etc to deploy, faq, limitations etc. 

[Rob Ingram]

@User_80617 I would create a single tunnel-group (connection profile), group-policy and IP pool for all vendors.

Authenticate and authorise the vendors from ISE, during authorisation assign the vendor a TrustSec SGT (one SGT per vendor), then on the FTD access control policy control access based on the vendor SGT. As access is based on the SGT you don't need to create multiple IP pools or group-policies etc, this keeps the design simple.

[User_80617]

Thanks Rob for valuable input.

So, does SGT need any additional licenses? I am trying to find myself some documents on this , can you share any such document if you have with you. 

[Rob Ingram]

@User_80617 you will need ISE Advantage licenses to use SGTs. Example ISE/FMCintegration:- https://integratingit.wordpress.com/2018/08/25/cisco-ise-pxgrid-integration-with-firepower/

[tvotna]

@User_80617 You can go with SGT as @Rob Ingram suggested or use DACLs and single pool / single connection profile (a more traditional approach). On our Firepower 4150 I currently see 10 DACLs 1000 lines each, but I used to see many more. Each DACL is downloaded once and then is reused by new connecting users. If it is modified on ISE, new version is downloaded, but old one remains if it is still in use by other users. So, yes, DACLs can consume some memory, but its unlikely you'll have 100,000s of lines per DACL, right?

DACLs do not work well with HA (replication issues), but HA is rarely deployed with RA VPN.

I'm not sure about DACL vs ACP order on FTD. On ASA "sysopt connection permit-vpn" is ON by default, so only DACLs work.

[User_80617]

@rob @tvotna Thanks for your revert. The SGT things looks bit complex to me. I am referring below document. Any other document with ISE and firepower.

https://integratingit.wordpress.com/2019/01/26/cisco-trustsec-on-asa-firewall/

[Rob Ingram]

@User_80617 that post you provided is for ASA, so not applicable to FTD.

This link demonstrates ISE/FMC integration with DACLs, just ignore the posture section. For each vendor create an ISE authorisation rule, authenticate the users via a different AD group and assign a different authorisation profile which references the unique per vendor DACL.

[User_80617]

Thanks @Rob Ingram @tvotna 

The risk i see using dACL is, What is the limit for dynamic ACLs on firepower with a 6 cpu container? In the case of many users the number of DACLs on FTD will be more and there can be issues as the total number of ACEs will be multiplied with the total number of concurrent users As dACL will be downloaded for each user? I see some forum says, dACL won't be downloaded each time a new user from a vendor connects but only once for the first user and then the same dACL applied for the rest of users.But not sure on this.

[tvotna]

DACLs are shared between users. New version of DACL is downloaded only when you change the DACL on the RADIUS server and a new user connects. Old DACL remains on ASA so long as it is in use. The DACL is removed when all user sessions which refer to this DACL disconnect. This behavior was implemented in 2009: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCsx69265

So memory is not an issue.

[User_80617]

Thanks @tvotna for the revert @Rob Ingram 

One more option i am evaluating since dACL wont enable us to add L7 features to control.

I am trying following : Created realm with AD, created identity policy and added that to ACP. So I have ACP control based on user ad group membership. 

If i use realm/AD for both authentication and authorisation this works absolutely fine. But when I use SAML as authentication and realm/AD as authorisation this doesne work. When AD is set for authorization it asks for ldap attribute-map and thats creating problem. 

Please, how to resolve this.

[tvotna]

Very good question, @User_80617 . I didn't try this myself, but believe that SAML authentication + native user/group-based filtering is not currently supported on FTD. When you use RADIUS for authentication, you can configure Realm under Objects > Object Management > AAA Server > RADIUS Server Group. The Realm connects your authentication config with the Identity Policy used in the Access Control Policy and hence user-based filtering works in ACP just fine. So far as I can see, it is not possible to set Realm for SAML server.

Perhaps @Milos_Jovanovic or somebody from Cisco can help us understand the reason of this limitation and if there are plans to resolve it the code.

The LDAP authorization you're trying to use indeed implies that LDAP attribute-map is going to be used to assign group-policy from AD group a user belongs to. This is not very convenient as was discussed here, but works: https://www.reddit.com/r/Cisco/comments/ns4nsc/restrict_access_to_internal_resources_for/?rdt=62129 (just as an example).

[User_80617]

Thanks @tvotna for revert.

Yes, you are correct user based access rules dont work for vpn if authentication is set as saml as described in https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwa57876

So, i was trying another option. Authentication SAML and authorization Cisco ISE, ISE will pass attribute address pool /217 to ftd that will keep separate ip pool for each vendor and then i can control in acp. Now, this also doesnt work! for this ISE must be set for authentication. Dont know what to do now.

I have around 60 vendors and want to keep single connection profile and group-policy for them. Other options like SGT and Cisco ISE-PIC seems also wont work with SAML.

[Rob Ingram]

@User_80617 SAML authentication and authorisation via ISE should work. You can deploy a different IP pool or SGT etc during authorisation and then use them in the ACP to distinguish between the different vendors.

You'd need to provide information relevant to your environment as why it is not working, how is ISE configured? What do you ISE Live Logs say when you attempt authorisation?

[User_80617]

Hi @Rob Ingram Even I think it must work as FTD debug shows that it has received pool information from ISE but somehow it is not using it and vpn getting disconnected giving reason like - no ip to assign.  IP pool object is there on firewall.

Now logged case with Cisco awaiting their revert.

[tvotna]

As @Rob Ingram mentioned ISE authorization should work. In this example group-policy is assigned and not just pool: https://www.lookingpoint.com/blog/ra-vpn-on-ftd-with-aad-duo-authc-and-ise-authz