Disabling Split Tunneling - SAs not matching when i change crypto ACL

[ovieira]

Hi!

When i change my Crypto ACL i get an error message in IKE phase I: "NOTIFY PROPOSAL_NOT_CHOSEN". I'm doing this to disable ST and make all traffic go trough the tunnel. Please see the config below:

crypto isakmp policy 10

hash md5

authentication pre-share

lifetime 3600

crypto isakmp key cisco address x.x.x.x

!

!

crypto ipsec transform-set CRYPTO esp-des esp-md5-hmac

!

crypto map CUSTOMER 1 ipsec-isakmp

set peer x.x.x.x

set transform-set CRYPTO

match address 115

!

access-list 115 permit ip 10.10.10.0 0.0.0.255 10.10.11.0 0.0.0.255

access-list 115 deny ip any any

I changed the ACL 115 to so i can disable Split Tunneling and it looks like this:

access-list 115 permit ip 10.10.10.0 0.0.0.255 any

access-list 115 deny ip any any

What's failing? I donthink the crypto ACLs need to be the same?!

[gfullage]

You said "I donthink the crypto ACLs need to be the same?!".

The most important thing in a crypto configuration is that your crypto ACL's are the EXACT OPPOSITE of each other. On whatever the peer router is you need ot change it's crypto ACL to:

> access-list nnn permit ip any 10.10.10.0 0.0.0.255

for this to work. If you're ACL's differ then you'l get this exact error.

[ovieira]

Hi!

Thanks for your answer! In my case i have a hub-and-spoke network with a central router receiving several IPSEC VPN tunnels. The actual situation, regarding crypto ACLs, is as below:

Central Site:

access-list 116 permit ip 172.20.0.0 0.0.63.255 172.20.128.0 0.0.63.255

access-list 116 deny ip 172.20.47.0 0.0.0.255 any

access-list 116 deny ip 172.20.44.0 0.0.0.255 any

Remote Site Example:

access-list 115 permit ip 172.20.129.0 0.0.0.255 172.20.44.0 0.0.3.255

access-list 115 deny ip 172.20.129.0 0.0.0.255 any

The headquarters crypto ACL 116 includes a major net that works with all remote sites subnets. What i mean is that these ACLs don't match but it works fine as it is.

When i tryed to disable split tunneling it stops working (see changed remote ACL below).

Remote Site:

access-list 115 permit ip 172.20.129.0 0.0.0.255 any

Regards

[gfullage]

I'll say it again, make sure your crypto ACL's are the exact opposite of each other. If what you show above is working then you're lucky, but I guarantee you'll run into problems depending on which side tried to initiate the tunnel.

If the central site ACL includes major nets that include all remote sites, how are you differentiating that specific traffic goes to a specific site? Also, you can remove the "deny" lines in your crypto ACL's, they're not necessary.

[ovieira]

Hi!

Beeing so, how can i have a hub-and-spoke with a central site and 50 remote sites using LAN-to-LAN IPSEC? Configuring at the headquarters 50 CRYPTO MAPS!?

Thanks for your help.

[gfullage]

In general, yes, that's exactly how you do it, otherwise how does the head-end know which peer to send which traffic types to? Actually you only have the one crypto map, but you have 50 instances of it that define each peer and the traffic type that will be sent to them.

Or to simplify the config on the head-end, just configure a dynamic-crypto map and then it'll just accept connections from each of the remote sites, which will also fix up your current ACL problem cause it'll only be defined on the remote site. This will mean that the remote site has to be the one that initiates the tunnel, but if that's OK, then a dynamic crypto map is the way to go.

I'm a little confused how things are working for you now with 50 remote sites and are you saying you only have one crypto map instance?

[ovieira]

Hi!

Here goes the EXACT CONFIGURATION from both the head-end and a remote site. Please take a look:

############################################

### Configuration at "head-end" (CS2611) ###

############################################

!

crypto isakmp policy 1

hash md5

authentication pre-share

crypto isakmp key MySharedKey address 0.0.0.0 0.0.0.0

!

! the head-end router only is a receiver of VPN remote connections from

! unknown Internet IP address. we are talking about 50 CS803 with dial-up

! non-fixed IP Internet connections

!

crypto ipsec transform-set ipsec-trans esp-des esp-md5-hmac

!

crypto dynamic-map PERSONAL 10

set transform-set ipsec-trans

match address 115

!

crypto map VPN-CUSTOMER 10 ipsec-isakmp dynamic PERSONAL

!

interface Ethernet0/0

description *** HEAD-END Internal LAN ***

ip address 172.20.44.70 255.255.252.0

ip nat inside

ip policy route-map RemoteSites

!

! the route map is for distinguish between regular internet access ou IPSEC

! traffic

!

interface Serial0/0

description *** Internet link for regular Internet access ***

ip nat outside

!

interface Serial0/1

description *** Internet Link for VPN connections ***

ip address 10.10.10.1 255.255.255.252 --> an example IP!!!

crypto map VPN-CUSTOMER

!

ip nat inside source route-map NoNAT interface Serial0/0 overload

!

access-list 115 permit ip 172.20.0.0 0.0.63.255 172.20.128.0 0.0.63.255

access-list 115 deny ip 172.20.47.0 0.0.0.255 any

access-list 115 deny ip 172.20.44.0 0.0.0.255 any

!

! bothe ACL 115 and 116 have traffic defined beteween the head-end LAN and

! a major-net that contains all the 50

! remote sites subnets

!

access-list 116 deny ip 172.20.0.0 0.0.63.255 172.20.128.0 0.0.63.255

access-list 116 permit ip 172.20.47.0 0.0.0.255 any

access-list 116 permit ip 172.20.44.0 0.0.0.255 any

!

route-map NoNAT permit 10

match ip address 116

!

route-map RemoteSites permit 10

match ip address 115

set interface Serial0/1

!

############################################

### Configuration at remote site (CS803) ###

############################################

!

crypto isakmp policy 1

hash md5

authentication pre-share

crypto isakmp key MySharedKey address 10.10.10.1

!

crypto ipsec transform-set ipsec-trans esp-des esp-md5-hmac

!

crypto map VPN-CUSTOMER 1 ipsec-isakmp

set peer 10.10.10.1

set transform-set ipsec-trans

match address 115

!

!interface Ethernet0

description *** Remote site internal LAN ***

ip address 172.20.133.1 255.255.255.0

ip nat inside

!

interface Dialer1

description *** Internet dial-up connection ***

ip nat outside

crypto map VPN-CUSTOMER

!

ip nat inside source route-map NoNAT interface Dialer1 overload

!

access-list 115 permit ip 172.20.133.0 0.0.0.255 172.20.0.0 0.0.63.255

access-list 115 deny ip 172.20.133.0 0.0.0.255 any

!

access-list 116 deny ip 172.20.133.0 0.0.0.255 172.20.0.0 0.0.63.255

access-list 116 permit ip 172.20.133.0 0.0.0.255 any

!

route-map NoNAT permit 10

match ip address 116

!

Again you are beeing of great help.

Regards

[gfullage · Accepted solution]

OK, you're using a dynamic crypto map on the head-end just as I suggested so that's fine. What you have done, which is causing your problem (and generally causes more problems than it's worth), is assign an access-list to the dynamic crypto map. This is not necessary because with a dynamic crypto map the head-end router will simply accept whatever traffic pattern the remote router sends it.

In your case since you've changed the remote router to be "any", this no longer maps into the ACL 115 on the head-end and it's now failing.

Easiest way around it is simply to remove the "match address 115" from the dynamic crypto map on the head-end. This won't affect any of your other tunnels, and will allow the remote router to establish a tunnel.

The exact commands you'd use are as follows:

> crypto dynamic-map PERSONAL 10

> no match address 115