Re: Can not enable Split Tunneling

Jim Broom · ‎12-08-2009

Gentlemen,

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.

Thanks!

jb

busterswt · ‎12-11-2009

Hi Jim,

I don't have much experience with VPNs on a router, but I have configured many VPNs on ASA's and PIX's and have a few ideas that might send you in the right direction.

In your isakmp client config on the head router, you have dictated the split-tunnel ACL as '100':

crypto isakmp client configuration group xxxVPN

key xxxx

pool SDM_POOL_1

acl 100

netmask 255.255.255.0

The networks defined within that ACL are the routes it injects into the client as traffic that needs to pass over the tunnel (source network in ACL):

access-list 100 permit ip 166.xx.xx.16 0.0.0.7 192.168.100.0 0.0.0.255

access-list 100 permit ip 166.xx.xx.16 0.0.0.7 192.168.101.0 0.0.0.255

access-list 100 permit ip 166.xx.xx.16 0.0.0.7 192.168.103.0 0.0.0.255

access-list 100 permit ip any 192.168.100.0 0.0.0.255

access-list 100 permit ip any 192.168.101.0 0.0.0.255

access-list 100 permit ip any 192.168.103.0 0.0.0.255

As you can see, from a client perspective the policy has said that traffic destined for 166.xx.xx.16/29 AND 'any' needs to flow over the tunnel. In actuality, you need traffic destined to the inside network - ONLY - from the client to pass over the tunnel. Looks like the inside network is 166.xx.xx.16/29. If you removed the bottom three ACLs then all other traffic should flow through the client's "public" interface, not the tunnel.

I hope this helps. Like I said, my only exposure to the routers configs is from this forum, so I could be wrong.

Good luck!

James

Jim Broom · ‎12-15-2009

James,

I can't thank you enough for your answer as you are confirming my suspicions on just how the VPN operates. That helps a lot.

We actually tried removing the three statements you suggested but it did not work. However, I think it did not work because we either did not remove the statements correctly or we were missing the NAT statements for the inside and outside interfaces of the client. I think we need both the correct ACL statements and the NAT statements to get split tunneling to work correctly.

I will go back to the drawing board and remove those ACL statements and make sure my NAT statements are correct as well.

Again, thanks for the help.

Jim Broom

Parminder Sian · ‎12-16-2009

Hey Jim,

Please go through the following doc, this might help you resolve your issue.

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_configuration_example09186a008032b637.shtml

Regards,

Parminder Sian