ASA VLAN Mapping feature limited to local network only?

[sbaetz07860]

Hello Cisco,

I have a design question in building a VPN Cluster using Anyconnect.

I have a customer that wants to map 4 groups to a corresponding VLAN.

For example:

employee - Vlan 94

Admin - Vlan 95

IT - Vlan 96

etc....

Each Vlan has a specific pool configured, and on the switch side, there is a Vlan interface that is configured as the DG for that subnet.

Now this appears to work just fine from a mapping perspective, however, the question becomes routing.  I've noted that there have been others that have run into this issue where the "route <interface> 0 0 tunneled" provides a tunnel default gateway for newly unencrypted traffic "globally"... meaning that you can set a DG for the VPN clients as a whole, however this option doesn't work when these clients groups are mapped to specific VLANs.

So the bottom line question is:  Does VLAN Mapping as a limitation only allow access to the local subnet where the user is assigned based on his group configuration, and there is no way to allow them to route off that particular subnet using the the DG for that subnet?

Thanks.

Steve

[jan.nielsen]

The VLAN feature is just for restricting access to a vlan, not for routing virtualization. you can only have one tunnel default gateway, the ASA does not have VRF like functionality.

[Kent Heide]

Jan is correct here. You have misunderstood the feature you are using slightly :-)

What I recommend you do is just use the same pool (or use different ones if you like) and then apply VPN filters (ACL's) to the Group Policies that the different users are belonging to.

[charlesdf22]

This is a pretty crap solution.  We are trying to do the same thing.  As with most networks, we have grown (and still growing) and continuous IP space is a luxury.

We figured out how to make one group work and map directly into their vrf, however, the rest are busted due to this limitation.

I know this can be done with other vendors... I wonder what the hold up is.

[dyonisiusnmvisser]

Hi charlesdf22  I have also acquired an ASA an found out that this does not work. I am interested which other vendors support this?

[charlesdf22]

We managed to do this DAP.  The documentation is awful and contradicts itself a couple times.  Basically we are using to DAP to match on an AD group and grant a permit/ deny.  Each group/ VRF has a vlan assigned to it with it's own adress pool.  The Juniper SA's are a lot more straight forward and give you a ton of flexibility.

If you do go the DAP route, keep in mind that Cisco does not support nested groups or recursive lookups.  If you need this to work, then all of your users must be in the root of the group.

[Gustavo Medina]

Hello All,

I can see this post is a little bit old but I had a very similar case and my customer found this when he was researching prior opening the TAC case. I was able to provide him with a solution and I thought it would be nice to share it with you guys.

In the example Steve pointed the solution would go like this:

group-policy employee attributes
  vlan 94
group-policy Admin attributes
  vlan 95
group-policy IT attributes
  vlan 96



interface GigabitEthernet0/2.2   
 vlan 94   
 nameif Employee   
 security-level 100   
 ip address 192.168.10.1 255.255.255.0

interface GigabitEthernet0/2.3
  vlan 95
  nameif Admin
  security-level 100
  ip address 192.168.20.1 255.255.255.0
interface GigabitEthernet0/2.4   
 vlan 96  
 nameif IT   
 security-level 100   
 ip address 192.168.30.1 255.255.255.0 

interface GigabitEthernet0/3   
 nameif outside  
 security-level 0   
 ip address 12.12.12.12 255.255.255.0 

route Employee 0.0.0.0 0.0.0.0 192.168.10.254 2 

route Admin 0.0.0.0 0.0.0.0 192.168.20.254 3 

route IT 0.0.0.0 0.0.0.0 192.168.30.254 4 

route outside 0.0.0.0 0.0.0.0 12.12.12.1 1

Notice the metrics on the default routes.

Regards,
 

[smunzani]

Gustavo,

Does this configuration work for you? If the ASA doesn't support VRFs, this configuration would not work because it would create multiple default routes pointing in different directions.

Charles,

Since you finally figured out DAP and I am still struggling, would it be possible for you to post some of your sanitized configuration with information on what you had to setup on the AD side?

Thanks in advance,

Sam

[Gustavo Medina]

Hello Sam,

Yes it works, take a look at the metric at the end of each route statement. Is it not working for u?

Regards,

[smunzani]

Gustavo,

I have not implemented it but I am 100% confident that it would not work. Is it working for you?

Matric on a route is nothing but way of telling the device which one has better preference. So when you put 10 default routes with various matrics and if everything is operating, only 1st one with better matrics would be used.

May be your config is designed for different need than mine. My need is different. What I want it various user groups with different access on the VPN. On active directory, I want to create different groups and on the ASA I want to provide different level of access to each group. This is very easy if the users were locally defined on the ASA. Simply create different ACLs and use vpn-filter command on each user's attribute. However I have to achieve the same from the active directory.

Thanks,

Sam

[Gustavo Medina]

Hello Sam,

Well I have made it work before so Im 100% sure it works

Each route will have a different interface, we use different metrics because the ASA won't allow us to have a DGW with the same metric even if we're using different interfaces so that's why we use different metrics, now the vlan mapping is the one that tells which interface the packets should go to, after that the ASA does the route lookup and will take the DGW that interface has.

Reading your las post you don't need this, what you can do is an ldap-attribute-mapping and bind any attribute from AD e.g. memberOf to and ASA value e.g. Grpup-Policy so that on the GPs you will have the vpn-filters yo want and the user will be mapped to a GP depending on the AD attribute.

Regards,

[Javier Portuguez]

Hi,

I totally agree with Gustavo (5 stars).

I have seen it working and I would also recommend his second option.

Thanks.

Please rate any post that you find helpful.

[smunzani]

I will go with his 2nd option suggestion since my need is different. If I had each group going to one VLAN only then it might be easier with 1st. However for some groups, they would have access to multiple VLANs not just one. So 2nd option is better choice.

Any pointers on configuration? Any URLs that show example of 2nd option?

Thanks,

sam

[Javier Portuguez]

Please check this out:

PIX/ASA 8.0: Use LDAP Authentication to Assign a Group Policy at Login

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a00808d1a7c.shtml

ASA/PIX: Mapping VPN Clients to VPN Group Policies Through LDAP Configuration Example

http://www.cisco.com/en/US/products/ps6120/products_configuration_example09186a008089149d.shtml

Let us know if you have any questions.

Please rate any post that you find helpful.

[Axel Maertens]

Hi

I did try to assign Group Polices via LDAP/AD group membership as Javier sugested following his document links.

For some reason the Attribute gets maped correctly, but is beeing overwritten immediately by the local tunnel group config!?

I am using ASA 8.4.4.1. Has anybody tried this with a 8.4 ASA? Might this be a bug? I have done similiar things with Radius on older ASA - Versions without problems

Regards

Axel