Cisco VPN Clients Routing Over IPSec VPN – ACL Configuration

access-controlciscocisco-iosvpn

I have remote access to a Cisco 2821 Router with a security firmware license in California with an IPSec tunnel going to a site in New York. On the New York side, there is a RFC 1918 IP scheme of 10.0.0.0/8. The LA side is 172.17.0.0/16. On the router, there is a VPN which hands out IP's by this command:

ip local pool Pool-1 192.168.50.1 192.168.50.30*

The issue is that, when I (or any other client) connects to the VPN on a remote computer, they are given an IP address (as seen below) but are still not able to contact the 10.0.0.0/8 network. They can still access the local network and the internet, but I'm not sure that access to the internet is going through the VPN. It may be going through their normal home connection.

IP Addresses

Attempted Solutions:

  • The first thing I did was look at the routing table. It had no routes for the 192.168.50.0/24 subnet, so I added some. I added the same route as the 172.17.0.0/16 network since they had access, however this did not work.
  • After that, I imagined I should have put an ACL in place to allow 192.168.50.0/24 traffic. I edited the existing ACLs to no avail.

My question:
When all said and done, the IP address of the VPN clients is originating within the router and is all virtual. My question is to what interface would I apply an ACL as to allow 192.168.50.0/24 traffic?

Other Notes:

  • I had a coworker VPN into it as well and he was not able to ping my 192.168.50.29 address.
  • The actual IP schemes are far more complex, but for sanity's sake, I've made them nice and easy without VLSM.
  • When I (or another client) connect to the VPN, there is a dynamic CRYPTO MAP policy added with an ACL that allows all incoming traffic to the IP, but nothing showing what it's allowed to go to…

Best Answer

Obviously you aren't using a Cisco VPN client, as it monitors the route table and will remove your tampering immediately. Even if the routes stick, the ASA will ignore traffic that doesn't belong in the tunnel.

There are two possibilities at play here:

  • the ASA isn't configured to hairpin traffic
  • the ASA isn't configured to allow those networks through the tunnel

The first can be enabled via same-security-traffic permit inter-interface and same-security-traffic permit intra-interface.

The second requires changes to the VPN split-tunnel configuration, any ACLs restricting access, routes on other gateways to know where the vpn-pool lives, and finally ensure the site-to-site VPNs know about and allow that pool across their tunnel.

(The latter is why my ASA proxy's DHCP from the local LAN for clients. It essentially makes VPN clients look like nodes on the local LAN.)

[UPDATE]

With IOS, the crypto map defines what traffic goes in the tunnel(s). (match address clause) That info is provided to the IPSec client. (it creates a security-association (SA) for each rule of the ACL.)

(for the record, I don't use the old IPSec client engine anymore. I prefer the SSLVPN (webvpn) setup on both ASA and IOS -- the setup is nearly identical. ASA-IOS tunnels are still the old, complicated crypto map IPSec setup. IOS-IOS tunnels, I prefer Tunnel interfaces.)

Related Topic