So, now you believe your issue is fixed ? ;) Sent from iPhone
On Sep 7, 2012, at 11:10 PM, "Jason Madsen" <[email protected]<mailto:[email protected]>> wrote: It's possible there was no issue. I was in VMs inside of VMs using Loopback adapters etc. I love testing / studying in a virtualized environment because I can change the topology etc so easily, but every once in a while I end up troubleshooting configuration issues that don't exist. Jason On Sat, Sep 8, 2012 at 12:01 AM, Jason Madsen <[email protected]<mailto:[email protected]>> wrote: Hi Eugene, The client is actually a PC running the IPSec client. I was running in Client mode and had an IP Local Pool specified. The PC did in fact receive an IP from the pool, and I could see the Split Tunnel route in my VPN client when looking at its statistics. However, the encryption/decryption counters were not incrementing as the route provided / recieved / generated by Windows was to 10.0.0.1, which didn't exist anywhere in my topology. My IP Local Pool was 10.10.10.1-50. PC NIC was 192.168.0.100 btw. I thought usually a route would be auto-magically entered on a PC pointing to a Tunnel interface of some sort that gets created. This was weird. Thanks, Jason On Fri, Sep 7, 2012 at 11:53 PM, Eugene Pefti <[email protected]<mailto:[email protected]>> wrote: Jason, I assume your VPN client is a hardware client. What is its mode, client or network-extention ? Is your IPSec tunnel up and you see counters incrementing for packets entering and exiting the tunnel? I would say everything is correct and what you see should be like this May be this is not relevant to your situation but these are my notes (see routes details in different modes). Briefly, it depends on the mode and the route that you are asking is added via Split ACL value (number or name) and you added it correctly. I didn’t understand why you ask about another AV value ;) 1) EzVPN remote standard configuration (as opposed to DVTI below) A) mode client - You need IP pool to be pushed to the client. IP address from the pool is assigned to Loopback10000 interface. - On EzVPN server route to the client (to the IP address from the pool) is seen as static via Virtual-Access interface (10.10.10.x is IP pool) S 10.10.10.x [1/0] via 0.0.0.0, Virtual-Access2 B) mode network-extension - You don't need IP pool on the EzVPN server. - On EzVPN server route to the network behind EzVPN client is seen as static via Virtual-Access interface (192.168.8.0 is the network behind EzVPN client) S 192.168.8.0/24<http://192.168.8.0/24> [1/0] via 0.0.0.0, Virtual-Access2 2) EzVPN remote with Dynamic VTI A) mode client - You need IP pool to be pushed to the client. IP address from the pool is assigned to Virtual-Access interface - Client builds a new static route to the network advertised by the server (1.1.1.1 in my case) via the virtual-access interface S 1.1.1.1 [1/0] via 0.0.0.0, Virtual-Access2 - On EzVPN server route to the client (to the IP address from the pool) is seen as static via Virtual-Access interface (10.10.10.x is IP pool) S 10.10.10.x [1/0] via 0.0.0.0, Virtual-Access2 B) mode network-extension - You don't need IP pool on the EzVPN server. - Client builds a new static route to the network advertised by the server (1.1.1.1 in my case) via the virtual-access interface S 1.1.1.1 [1/0] via 0.0.0.0, Virtual-Access2 - On EzVPN server route to the network behind EzVPN client is seen as static via Virtual-Access interface (192.168.8.0 is the network behind EzVPN client) S 192.168.8.0/24<http://192.168.8.0/24> [1/0] via 0.0.0.0, Virtual-Access2 From: Jason Madsen <[email protected]<mailto:[email protected]>> Date: Friday, September 7, 2012 1:59 PM To: Karthik sagar <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [OSL | CCIE_Security] Remote Access EZVPN using ACS Auth Hi All, Last night I setup a scenario where I added Split Tunneling to the remote access policy by adding "ipsec:inacl=ST" as a cisco-av-pair in the group (thanks Karthik for your pointer!). I was able to see the Split Tunnel routes in my VPN client, but I found that my remote access host was not getting the necessary route to reach this network. I assigned my VPN Pool to be in the 10.10.10.x /24 range, and the host successfully got an address in this range, but the only route provided through the VPN was a route toward my Split Tunnel subnet toward a GW of 10.0.0.1, which doesn't exist anywhere. It looks as though something did classful summarization and made up a gateway host address. Couple questions: * Anyone know what that occurred? * How do we specify a route to be added to the remote access VPN policy from within ACS? ....another RADIUS AV pair i'm guessing. Thanks, Jason On Fri, Sep 7, 2012 at 1:14 AM, Karthik sagar <[email protected]<mailto:[email protected]>> wrote: Yes, this is how it is designed. The Router sends the "vpn-group/cisco" as username/password to the ACS server. The actual vpn-group-password is then validated against "tunnel-pre-shared-key " attribute in the profile. This method is to be used only with IOS/RADIUS. With the ASA, the ACS profile will have the actual "vpn-group/vpn-group-password" as username/password. Why was it designed this way ? No idea :-) If anybody knows why, please share.. Regards, Karthik
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
