Extend VLANs out to Remote Access Clients

[matthewceroni]

Hi:

I am not sure if what I am trying to accomplish is possible. On my internal network I have the following VLANs setup (102, 104, 106) and they map one to one to a subnet (ie: 102 = 192.168.102.0/23, 104 = 192.168.104.0/24, etc).

All interVLAN routing is done on a 3560 via vlan SVI. Connected to the 3560 via a routed port is a ASA 5510. The routed port has IP 192.168.100.1 and the ASA interface on the other side of that routed port has IP 192.168.100.2.

I use 802.1x on the wired network to assign users (based on their department) into a specific VLAN. I want to extend this concept to Remote VPN access. Therefore I setup multiple Group Policies (policy is applied based on an LDAP attribute) where each policy defines a different DHCP scope. This has successfully allowed me to login wtih different users who get assigned to different Group policies and they obtain the correct DHCP IP address from the internal DHCP server (ie: an engineering person logins remotely and gets an IP in 192.168.102.0 range). However the issue (and as I was planning this out I knew this would come up) is that traffic can be routed out from the VPN client to its destination but there is no return path.

Obviously the reason is that the ASA is not part of that VLAN. So when an internal machine (lets say 192.168.102.12) receives traffic from a Remote VPN client (lets say 192.168.102.13) it assumes it is directly connected and sends the packet out its interface. But the ASA isn't directly connected on that subnet as it is on a routed port on 192.168.100.0/23.

The only real option I can think of is to disable interVLAN routing on the 3560 so that everything ends up going through the ASA and it will have host specific routes for the VPN clients and no where to send the traffic. But that solution only solves the issue for when a Remote VPN session is on a different VLAN (VPN session is on 192.168.104.0/23 and it is trying to communicate with something on 192.168.102.0/23), the same issue would still happen if they are on the same VLAN.

Thanks

[Neeraj Arora]

Hi Matt,

I can think of 2 solutions:

1. A better solution: Instead of 102,104,106......create three new subnets on your DHCP server for 202,204,206. Use these new subnets for your VPN clients but apply the same policies as their predecessors. On your 3560, you can have routes for these 3 new subnets pointing towards 192.168.100.2, so this will take care of the return path as well

2. Dirty solution: On your DHCP server, using some attributes sent by VPN client restrict their Ip address allocation to a range For eg. VPN clients in 102 vlan should only be allocated ip address from 192.168.102.192 to 192.168.102.254 (192.168.102.192/26)

Then a route for this subnet 192.168.102.192/26 could be configured in 3560 pointing towards the ASA

Hope it helps. Do let me know if you could make it work with the above options

Neeraj

[matthewceroni]

Neeraj:

Thanks for the reply. I decided to go with option 1 (it was something I had decided on after posting my thread yesterday). It seems to be the easier more logical approach.

Also I think I could have done what I wanted initially if I switched from routed mode to transparent firewall mode on the ASA, but that brings up a whole bunch of other issues to contend with.

Thanks for the help

[Abzal]

Hi,

I think it could work if will be ASA on the same subnet .102/23 instead of .100. We had the same topology but with PIX.

Hope it will help.

Sent from Cisco Technical Support iPhone App