cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2308
Views
10
Helpful
18
Replies

Restrict AnyConnect FlexVPN Connectivity with CSR1kv in multi VRF scenario if IKEid (key) is leaked

manoghos
Cisco Employee
Cisco Employee

Hi Experts,

I need help in configuring an ikev2 profile for VRF to restrict other VRF users.
AnyConnect Client 4.5 is using FlexVPN using AnyConnect-EAP authentication with an IKE ID for matching remote key identity.
Also, we are using a local AAA database.( No Radius/TACACS).

In case I got the IKE ID of any other tenant and using that in my AnyConnect profile I can connect to another tenant network.
I hope this can be restricted using name-mangler option in aaa authorization group/user in ikev2 profile but found limited examples for implementing it with local-AAA.

Please find the configuration snapshot.

 

1 Accepted Solution

Accepted Solutions

When you are using the name-mangler it would extract "test1@manoj2.com" (as per your debug) and then expect that value to be the name of the authorization policy. Obviously to scale you would want to use a more generic value (.e.g manjo2.com) and then have multiple authorization policies for the different attributes extracted.

View solution in original post

18 Replies 18

Hi,
What is the configuration of your ikev2 authorization policy? it's not in your configuration output

 

Check out this example, in particular the hub configuration section of the answer towards the bottom of the post. It's not using the EAP attribute in the name-mangler but I think it relates.

 

HTH

Thanks, RJI.

Please find the authorization policy:

aaa attribute list AAA-attr
 attribute type interface-config "ip mtu 1300"
!

crypto ikev2 authorization policy auth-policy-Tenant1
pool ACPOOL-Tenant1
aaa attribute list AAA-attr
!

 

Can we use two authorization group configuration in ikev2 profile. one for authorization policy and another for name-mangler

When you are using the name-mangler it would extract "test1@manoj2.com" (as per your debug) and then expect that value to be the name of the authorization policy. Obviously to scale you would want to use a more generic value (.e.g manjo2.com) and then have multiple authorization policies for the different attributes extracted.

thanks RJI. Let me quickly test that.

Thanks a lot, RJI.

I did this:

crypto ikev2 name-mangler Tenant1-mangler
 eap suffix delimiter @
!

and authorization policy as:

crypto ikev2 authorization policy manoj2.com
 pool ACPOOL-FIE40AO8HT3AT2V2F1EUCIR6QG
 def-domain manoj2.com
 aaa attribute list AAA-attr
!

 It is working. will do some more test. do you want to suggest some more attributes or configuration in authorization policy?

Awesome, glad it's working

You could create additional Attribute Lists, reference them in the different IKEv2 AuthZ policies and apply different settings such as VRF, Qos Policy, Access List/ZBFW Zone Member, uRPF etc.

Rob

yeah. got it.thanks again

Hi RJI,

Applying the name-mangler and getting the desired authorization policy is working, but I am unable to restrict the local aaa user (for particular VRF). 

There are many options in aaa attribute list. also, "attribute type vrf-id" ...

 

aaa attribute list AAA-attr-manoj
 attribute type interface-config "ip mtu 1300"
 attribute type vrf-id vrf-1 protocol ip
!

crypto ikev2 authorization policy manoj.com
 pool ACPOOL-vrf-1-pool
 def-domain manoj.com
 aaa attribute list AAA-attr-manoj
!

 

The original problem is still there i.e test2@manoj.com user is still using the vrf-2 network. (using the IKEid of VRF 2 in anyconnect profile) so the authorization rules don't restrict.

I am not sure on applying the attribute's type to apply a certain VRF or creating usergroups on VRF basis.

Please suggest.

 

Hi,

The following command under the aaa attribute list works for assigning the VRF.

 

aaa attribute list Customer-1
 attribute type interface-config "vrf forwarding Customer-1"
 attribute type interface-config "ip unnumbered lo10"

crypto ikev2 authorization policy Customer-1
 pool CUSTOMER-1_POOL
 aaa attribute list Customer-1

interface Virtual-Template1 type tunnel
 no ip address

Obviously if you have additional VRFs you would create additional IKEv2 AuthZ policy and attribute list accordingly.

 

HTH

Thanks a lot, RJI.

So it means we will not going to restrict the connection (as IKEid domain and user domain are different), instead, we will start the connection to the VRF to which the user belongs based on authorization policy.

 

I tried with below and it is starting the connection using the below mentioned VRF:

aaa attribute list AAA-attr-manoj
 attribute type interface-config "ip mtu 1300"
 attribute type interface-config "ip unnumbered Loopback1"
 attribute type interface-config "ip vrf forwarding VRF1"
!

 

As I already have a VT Interface for the VRF, I want to use that, thus I tried interface in attribute type, but it has not worked.

It is using any of the VTs can we restrict that ?:

aaa attribute list AAA-attr-manoj
 attribute type interface-config "ip mtu 1300"
 attribute type interface "Virtual-Template2"
 attribute type interface-config "ip vrf forwarding VRF1"
 attribute type interface-config "ip unnumbered Loopback1"
!
interface Virtual-Template2 type tunnel
 ip vrf forwarding VRF1
 ip unnumbered Loopback1
 ip nat inside
 zone-member security inside-VRF1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile AC-VRF1
!
Thanks again for your valuable guidance :)
 

Hi,
Are you actually going to using multiple VRFs or just the one? If just the one, I'm not sure there is a need to use attribute list

If you intending to use multiple VRF, you should be referencing "VT2" in your IKEv2 Profile, therefore any established tunnel will dynamically create a Virtual-Access interface, using VT2 as the template. Therefore you don't need VRF or IP unnumbered configured under the VT, you just need to specify them under the attribute list and you wouldn't need to define the VT under the attribute list.

HTH

yeah, I will be using multiple VRF. Can we anyhow restrict the dynamic VT allocation from attribute list?
the existing VTs are currently our day0 config. which we push along with VRF creation.

Ok, are you saying you cannot modify the existing VT to remove the ip unnumbered and VRF configuration? I am not sure you can override the VRF configuration from the attributes list, I haven't tried.

 

I know this configuration below works and will assign VRF depending on name-mangler result.

 

aaa attribute list manoj.com
attribute type interface-config "vrf forwarding VRF-1"
attribute type interface-config "ip unnumbered lo10"
!
aaa attribute list abcde.com
attribute type interface-config "vrf forwarding VRF-2"
attribute type interface-config "ip unnumbered lo20"
!
crypto ikev2 authorization policy manoj.com
pool ACPOOL-vrf-1-pool
def-domain manoj.com
aaa attribute list manoj.com
!
crypto ikev2 authorization policy abcde.com
pool ACPOOL-vrf-2-pool
def-domain abcde.com
aaa attribute list abcde.com
!
crypto ikev2 name-mangler Tenant1-mangler
eap suffix delimiter @
!
interface Virtual-Template2 type tunnel
no ip address
ip nat inside
tunnel mode ipsec ipv4
tunnel protection ipsec profile AC-VRF1
!
crypto ikev2 profile AnyConnect-Tenant1
 aaa authorization group anyconnect-eap list a-eap-author-grp name-mangler Tenant1-mangler
virtual-template 2

HTH

 

 

 

Yeah, the above configurations are working. Only thinking about managing the VT, how to use the existing VT.
Thanks again.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: