wilsonb162
asked on
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
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?
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
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?
ASKER
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
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
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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