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]>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]>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 [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 [1/0] via 0.0.0.0, Virtual-Access2* >> >> >> >> From: Jason Madsen <[email protected]> >> Date: Friday, September 7, 2012 1:59 PM >> To: Karthik sagar <[email protected]> >> Cc: "[email protected]" < >> [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]> 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
