Cisco ASA 5505 - VPN into VLAN

Hi all,

I would like to set up our ASA to allow clients to IPSEC VPN into our network, and be assigned to a VLAN based on their group policy.  For instance, office workers should be able to, based on their group assignment, VPN into our office vlan.  Network Admins should be able to VPN into the Network Admin VLAN, and so on.  These VLANs are currently in production (IE they are already used internally).

Here is the scenerio:

vlan's are configured on a 3750 stack.  The ASA is plugged in to a trunk port on the switch.  

Vlan 15: 192.168.15.x, default gateway for this vlan is 192.168.15.1
vlan 16: 192.168.16.x, default gateway for this vlan is 192.168.16.1

Vlan 15: server vlan.  Subinterface e0/0.15 on ASA, nameif server.  ASA has an IP on this interface, 192.168.15.2
Vlan 16: client vlan.  Subinterface e0/0.16 on ASA, nameif client.

default gateway for ASA is pointing outside.  
route 192.168.16.0 255.255.255.0 192.168.16.1 is configured on the ASA

ACL's are wide open, permit ip any any, for testing purposes.




A client connects from the outside into the ASA using anyconnect.  They are assigned an IP address of 192.168.16.100.  They then attempt to ping a web server at 192.168.15.44.  The ping is successful.  They attempt to browse to the web server, but nothing happens.  ASA logs shows the following:

Deny TCP (no connection) from 192.168.15.44/80 to 192.168.16.100/2173 flags SYN ACK on interface client

Doing a packet capture, I can see that the initial client request goes out the server interface (vlan15), but the return packet tries to come in the client interface.  This makes sense from a routing perspective, and asa drops it because the return packet doesn't have a tcp connection created.

Next, I tried editing the group policy for this client to force them to vlan 16, so all traffic should generate out that interface.  Client reconnects to VPN and tries pinging the web server again, but fails.  Log show the following:

Routing failed to locate next hop for UDP from outside:192.168.16.100/138 to server:192.168.15.44/138

Again, this makes sense, since the client interface doesn't know how to route to the server network.  

Any ideas on how to get this to work?
LVL 1
wilsonb162Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

bignewfCommented:
You could try a test setup using one of the layer 3 switch vlans as your "inside router"

you could then try this command in the asa

route inside  0.0.0.0 0.0.0.0 x.x.x.x tunneled, where x.x.x.x  represents the inside router, in your case, a vlan that is considered the gateway network - ie.   192.168.15.1
This tunnel default gateway will sometimes overcome the vlan routing issues you are having with your asa. I have used this with some success in similiar scenarios as yours
0
wilsonb162Author Commented:
I added the tunneled route as you suggested, but that unfortunately did not help:

route inside 0.0.0.0 0.0.0.0 192.168.15.1 tunneled

when I establish the VPN session I can still ping the device, but I get the same problem as before:

Deny TCP (no connection) from 192.168.15.44/80 to 192.168.16.100/4612 flags SYN ACK on interface client
0
bignewfCommented:
I will have to research this more, but you might want to try assigning a vlan subnet that is different than your production network ip scheme, say  192.192.192.0
used nowhere else, for the VPN address pool. Then:
access-list nonat permit ip any 192.192.192.0 255.255.255.0
(if nonat is in your config)

make sure you have a route to this network
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
wilsonb162Author Commented:
Unfortunately I was hoping to utilize our existing production networks to place clients on, since we already have internal firewalling setup.  That way we can apply additional security policies for remote access, and keep our internal firewall rules separate.  From what I can see though, the separate VLAN seems to be the recommendation for VPN.  
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
VPN

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.