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.
employee - Vlan 94
Admin - Vlan 95
IT - Vlan 96
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?
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.
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.
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.
Hi charlesdf22 I have also acquired an ASA an found out that this does not work. I am interested which other vendors support this?
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.
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 94group-policy Admin attributes vlan 95interface GigabitEthernet0/2.2group-policy IT attributes vlan 96
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.0interface GigabitEthernet0/2.4
ip address 192.168.30.1 255.255.255.0
ip address 22.214.171.124 255.255.255.0
route Employee 0.0.0.0 0.0.0.0 192.168.10.254 2route Admin 0.0.0.0 0.0.0.0 192.168.20.254 3route IT 0.0.0.0 0.0.0.0 192.168.30.254 4
route outside 0.0.0.0 0.0.0.0 126.96.36.199 1
Notice the metrics on the default routes.
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.
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,
Yes it works, take a look at the metric at the end of each route statement. Is it not working for u?
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.
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.
I totally agree with Gustavo (5 stars).
I have seen it working and I would also recommend his second option.
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?
Please check this out:
PIX/ASA 8.0: Use LDAP Authentication to Assign a Group Policy at Login
ASA/PIX: Mapping VPN Clients to VPN Group Policies Through LDAP Configuration Example
Let us know if you have any questions.
Please rate any post that you find helpful.
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 188.8.131.52. 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
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:
Attached is Config and Log.
I do have a TAC Case concerning this problem by now as well (622633357), createde from Discussion https://supportforums.cisco.com/thread/2163198?tstart=0 - thought it fits better in a seperate discussion.
just so you won't do work twice.
Thanks so far,
Or you can use DAP as well...
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 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).
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,