I apologize for asking dumb questions but I have been wrestling with this problem for over a week and I am out of ideas and need guidance.
I am attaching two configs, one for the head end (an 871 running 12.4 code) and the other for the remote end (an 1841 running 12.4) of a VPN connection. These are configs we have inherited and do not have sufficient documentation regarding the finer details on how they work. In short, the VPN tunnel does work but we want to implement Split Tunneling and we don't seem to be able to figure out how to do it. My partner and I have reviewed all the Cisco Tech Notes we can find on Split Tunneling but none quite seem to match our existing configuration. I am open to suggestions with regard to starting over from scratch if need be if we have a suitable template that matches our requirements.
Let me explain a few of our assumptions gleened from many hours of observation regarding these configs that may, in fact, be wrong.
1. In our configs, it appears that the headend is dictating what the Crypto Map looks like on the remote. If we do a 'show crypto map' on the remote, we see ACL permit statements that appear to be products of the isakmp profile. I can't find any mention of an isakmp profile on the remote config and I sure do not see the ACL statements in that config either. I suspect we have a profile in the headend that is populating my crypto map in the remote. What confuses me is that the ACL referenced in the head end's 'crypto isakmp client configuration group' statement appear to be reversed in terms of source and destination addresses that appear on the remote's crypto map. Is that the way it is supposed to work?
2. My suspicion is that as long as my crypto map in the remote is permiting traffic to flow up the ipsec tunnel, I am stuck. I have to figure out what is causing my remote router's crypto map to be populated with statements that are sending my Inet traffic up the tunnel instead of directly to the Net. I had considered adding a 'crypto map' statement to the remote with a 'match' parameter to specify what traffic to send up the pipe but that seemed useless since the crypto map appears to be set by the head end router. I also thought about adding an ACL parm to the existing 'crypto ipsec client ezvpn' statement in the remote config but that seemed just as useless for the same reason stated above. Please correct me if my judgement has faltered on this point.
3. My real fear is that I am getting killed by the dynamic crypto map in the head end router. I can't make head or tails out of what it is doing to me.
I greatly appreciate any help you can offer. I have the feeling we would be better off to start over from scratch as opposed to trying to salvage these configs and make them work. Please let me know what you think.