ASA VLAN Mapping feature limited to local network only?

Unanswered Question
Apr 28th, 2010

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

I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
jan.nielsen Thu, 05/06/2010 - 14:59

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 Thu, 05/06/2010 - 15:10

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 Tue, 06/15/2010 - 05:58

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 Mon, 09/06/2010 - 02:26

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 Mon, 09/06/2010 - 11:39

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.

Jose Gustavo Medina Tue, 04/17/2012 - 16:30

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,

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

Jose Gustavo Medina Mon, 07/30/2012 - 07:18

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,

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

Jose Gustavo Medina Mon, 07/30/2012 - 08:15

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 Mon, 07/30/2012 - 08:29

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.

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 Mon, 07/30/2012 - 08:40

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.

amaertens Wed, 08/01/2012 - 04:12

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

Javier Portuguez Wed, 08/01/2012 - 05:36

Hi Axel,

Please collect the "debug ldap 255" and the "debug aaa common 255" during a connection attempt.

Also attach the "show run tunnel-group", "show run group-policy", "show run aaa-server" and "show run ldap-attribute-map".

Let us know:

username:

tunnel-group:

Thanks.

lukaskuzmiak Sun, 04/20/2014 - 05:20

Hi!

I think I'm in a pretty similar problem right now.

The only difference being the ASA itself serves as a default gateway for all the VLANs/subnets that I need to route to..

I have an outside interface and then a couple of inside ones (subinterfaces for each vlan)

However I still get this when I'm trying to connect to VLAN101 host from VLAN102 - that is a VPN client and therefore is coming from the outside interface:

Routing failed to locate next hop for TCP from outside:<internal vlan ip from VLAN102>/60093 to vlan101:<internal vlan ip from VLAN101>/443

And while trying to set a default gateway as you said (with higher metric than the default gateway that I normally have) I get this error:

Invalid next hop address, it belongs to one of our interfaces

Am I being stupid with my configuration or am I screwed?

Thanks!

lukaskuzmiak Tue, 04/22/2014 - 08:11

Hello Gustavo,

thanks for taking time to reply :-)

I'm attaching both the current config and routes - I've deleted some stuff of running config (but only the irrelevant stuff like other non-affected interfaces and CA and certificates and stuff that only takes place and bothers).

Config:

ASA Version 9.1(5) 
!
hostname asa
domain-name ii
xlate per-session deny tcp any4 any4
xlate per-session deny tcp any4 any6
xlate per-session deny tcp any6 any4
xlate per-session deny tcp any6 any6
xlate per-session deny udp any4 any4 eq domain
xlate per-session deny udp any4 any6 eq domain
xlate per-session deny udp any6 any4 eq domain
xlate per-session deny udp any6 any6 eq domain
names
!
interface GigabitEthernet0/0
 nameif trunk
 security-level 0
 no ip address
!
interface GigabitEthernet0/0.101
 vlan 101
 nameif ii_services
 security-level 0
 ip address 172.30.151.234 255.255.255.0 
!
interface GigabitEthernet0/0.102
 vlan 102
 nameif ii_users
 security-level 0
 ip address 172.30.152.234 255.255.255.0 
!
interface GigabitEthernet0/0.201
 vlan 201
 nameif upc
 security-level 0
 ip address 192.168.234.3 255.255.255.0 
!
boot system disk0:/asa915-smp-k8.bin
boot system disk0:/asa914-smp-k8.bin
ftp mode passive
clock timezone CEST 1
clock summer-time CEDT recurring last Sun Mar 2:00 last Sun Oct 3:00
dns domain-lookup trunk
dns domain-lookup upc
dns domain-lookup ii_services
dns domain-lookup ii_users
dns server-group DefaultDNS
 domain-name ii
same-security-traffic permit inter-interface
object network upc_pat
 subnet 0.0.0.0 0.0.0.0
 description NAT for upc connection
object network ii_users
 subnet 172.30.152.0 255.255.255.0
object network ii_services
 subnet 172.30.151.0 255.255.255.0
access-list ii_users standard permit 172.30.151.0 255.255.255.0 
access-list ii_users standard permit 172.30.152.0 255.255.255.0 
pager lines 24
logging enable
logging asdm informational
mtu trunk 1500
mtu upc 1500
mtu ii_services 1500
mtu ii_users 1500
icmp unreachable rate-limit 1 burst-size 1
asdm image disk0:/asdm-716.bin
no asdm history enable
arp timeout 14400
no arp permit-nonconnected
nat (upc,any) source static ii_users ii_users no-proxy-arp
!
object network upc_pat
 nat (any,upc) dynamic interface
route upc 0.0.0.0 0.0.0.0 192.168.234.1 1 track 1
webvpn
 enable upc
 anyconnect-essentials
 anyconnect image disk0:/anyconnect-macosx-i386-3.1.05160-k9.pkg 1
 anyconnect image disk0:/anyconnect-win-3.1.05160-k9.pkg 2
 anyconnect image disk0:/anyconnect-linux-64-3.1.05160-k9.pkg 3
 anyconnect enable
group-policy DfltGrpPolicy attributes
 vpn-tunnel-protocol ikev1 l2tp-ipsec ssl-client ssl-clientless
 default-domain value ii
group-policy grp_ii_users internal
group-policy grp_ii_users attributes
 banner value grp_ii_users
 dhcp-network-scope 172.30.152.0
 split-tunnel-policy tunnelspecified
 split-tunnel-network-list value ii_users
 vlan 102
tunnel-group DefaultWEBVPNGroup general-attributes
 authentication-server-group ii_radius
 dhcp-server link-selection 172.30.160.2
 username-from-certificate UPN
tunnel-group DefaultWEBVPNGroup webvpn-attributes
 authentication aaa certificate
 pre-fill-username ssl-client hide
!
class-map inspection_default
 match default-inspection-traffic
!
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map 
  inspect ftp 
  inspect h323 h225 
  inspect h323 ras 
  inspect rsh 
  inspect rtsp 
  inspect esmtp 
  inspect sqlnet 
  inspect skinny  
  inspect sunrpc 
  inspect xdmcp 
  inspect sip  
  inspect netbios 
  inspect tftp 
  inspect ip-options 
  inspect icmp 
!
service-policy global_policy global
prompt hostname context 
no call-home reporting anonymous
Cryptochecksum:f14379244cafbd85b6ed4c735a7c7b21
: end

and the routes:

Gateway of last resort is 192.168.234.1 to network 0.0.0.0

C    172.30.151.0 255.255.255.0 is directly connected, ii_services
C    172.30.152.0 255.255.255.0 is directly connected, ii_users
C    192.168.234.0 255.255.255.0 is directly connected, upc
S*   0.0.0.0 0.0.0.0 [1/0] via 192.168.234.1, upc

If you feel a need for any additional information I'll be happy to provide it.

Thanks a lot again,

Lukas

Actions

This Discussion

Related Content