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

Reply via email to