Cisco ASA 5505 - VPN into VLAN
Posted on 2008-11-19
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?