No. I moved onto different setups. I'll have to revisit that one with real equipment.
Sent from my iPhone On Sep 8, 2012, at 12:30 AM, Eugene Pefti <[email protected]> wrote: > So, now you believe your issue is fixed ? ;) > > Sent from iPhone > > On Sep 7, 2012, at 11:10 PM, "Jason Madsen" <[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]> 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
