I prefer the SSLVPN ( webvpn) setup on both ASA and IOS - the setup is nearly identical. (for the record, I don't use the old IPSec client engine anymore. (it creates a security-association (SA) for each rule of the ACL.)
( match address clause) That info is provided to the IPSec client. With IOS, the crypto map defines what traffic goes in the tunnel(s). It essentially makes VPN clients look like nodes on the local LAN.) (The latter is why my ASA proxy's DHCP from the local LAN for clients. 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 first can be enabled via same-security-traffic permit inter-interface and same-security-traffic permit intra-interface. the ASA isn't configured to allow those networks through the tunnel.the ASA isn't configured to hairpin traffic.There are two possibilities at play here: Even if the routes stick, the ASA will ignore traffic that doesn't belong in the tunnel. Obviously you aren't using a Cisco VPN client, as it monitors the route table and will remove your tampering immediately. 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.The actual IP schemes are far more complex, but for sanity's sake, I've made them nice and easy without VLSM.I had a coworker VPN into it as well and he was not able to ping my 192.168.50.29 address.My question is to what interface would I apply an ACL as to allow 192.168.50.0/24 traffic? When all said and done, the IP address of the VPN clients is originating within the router and is all virtual. After that, I imagined I should have put an ACL in place to allow 192.168.50.0/24 traffic.I added the same route as the 172.17.0.0/16 network since they had access, however this did not work. It had no routes for the 192.168.50.0/24 subnet, so I added some. The first thing I did was look at the routing table.It may be going through their normal home connection. 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. 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. 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* On the New York side, there is a RFC 1918 IP scheme of 10.0.0.0/8.
This is the only method that tunnels both IKE and IPSec within the same stream.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. The default port for this traffic is 10000/tcp.