Try to troubleshoot it with the following: 1. Validation on server side
sh ip int brief - Does this show up a virtual-access? interface that is up and has the same ip address as the physical interface that the client is going to reach. sh ip route static Does this show a route to an ip address from the pool that is defined. 2. Validation on the client side. Ensure that you have done the "inside" and "outside" mapping properly (just concept wise relate it to NATting but with a crypto twist to it) sh ip int brief Do you see a virtual-access? pointing to the ip allocated from the pool Do you see a loopback10000 (10k series) that again points to the ip allocated from the pool sh crypto ipsec ezvpn client Do you see your split acl pushed down showing up in this output sh ip route static Do you see a route to the network defined in the split acl where the exit interface is defined to be the virtual-access? The key point is that if properly configured then a. On server side it sets up a static routing pointing to the clients pool ip for proper reachability b. On client side for all traffic that needs to be encrypted it sets up static routes that point to the virtual-access interface as exit interface. Also saw in your config client configuration list VPN command is missing. >From a minimal configuration perspective all the routing that needs to be taken care of is a. The only reachability you need to take care is b/w the server and client. This could be dynamic or static. b. On the server side there should be reachability to any network referenced in the split acl that is pushed down c. On the client side since encrypted traffic has to go via the server there is nothing extra needed to configure. Its auto-magically setup as static routes when ezvpn context is created. You can cross check this by just adding a dummy ACE to the split acl. For every dummy ACE you add you will see an additional static route popping up on the client side. (Just force a renegotiation once you change the split acl by doing a clear crypto session on client performing xauth again), In your specific config pointed to by http://onlinestudylist.com/archives/ccie_security/2011-January/025328.html - since f0/0 on both R1 and R2 are on the same subnet the EZVPN negotiation should get thru fine - there is no need for the eigrp routing setup for the crypto destinations since they are loopback interfaces on R1 (server), #a from above satisfied. #c from above is automatically taken care when EZVPN comes up. My guess is the missing client authentication list VPN is the culprit. - R Shenai
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
