Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2128
  • Last Modified:

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?
0
wilsonb162
Asked:
wilsonb162
  • 2
  • 2
1 Solution
 
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
 
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

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now