topic Re: IPSec - "All IPSec SA proposals found unacceptable!" in Network Security

IPSec - "All IPSec SA proposals found unacceptable!"

techsupport — Mon, 11 Mar 2019 15:46:16 GMT

Trying to setup a l2l vpn between 2 ASAs and came across this in the log

Thanks

Jun 21 17:07:46 [IKEv1]: Group = 71.172.68.18, IP = 71.172.68.18, IKE Remote Peer configured for crypto map: vpn_map

Jun 21 17:07:46 [IKEv1 DEBUG]: Group = 71.172.68.18, IP = 71.172.68.18, processing IPSec SA payload

Jun 21 17:07:46 [IKEv1]: Group = 71.172.68.18, IP = 71.172.68.18, All IPSec SA proposals found unacceptable!

Jun 21 17:07:46 [IKEv1 DEBUG]: Group = 71.172.68.18, IP = 71.172.68.18, sending notify message

Re: IPSec - "All IPSec SA proposals found unacceptable!"

jeromecandiff — Sun, 21 Jun 2009 23:10:51 GMT

Compare your crypto maps between the 2 firewalls. The IPSEC proposal is the phase 2 proposal (transform set, group, pfs, etc)

Re: IPSec - "All IPSec SA proposals found unacceptable!"

Patrick0711 — Mon, 22 Jun 2009 00:05:28 GMT

Sounds like a mis-matched transform set between the peers.

sh run crypto

Check the transform sets referenced by your crypto map.

Re: IPSec - "All IPSec SA proposals found unacceptable!"

techsupport — Mon, 22 Jun 2009 00:18:11 GMT

These are the two configs, I'm not clear on

how crypto maps are linked to isakmp policy.

Whats the best way to set both sides to the

same. I can see that both sides are using

3des sha group 2. I get confused about policy 1 vs. 10 , 20 etc

name 71.X.68.X ABC

access-list VPN_TO_ABC extended permit ip host 10.20.12.127 host 192.168.13.3

access-list OUTSIDE_ACCESS_IN extended permit ip host 192.168.13.3 host 10.20.12.127

access-list nonat_inside extended permit ip host 10.20.12.127 host 192.168.13.3

nat (inside) 0 access-list nonat_inside

crypto ipsec transform-set 3DES-SHA esp-3des esp-sha-hmac

crypto map vpn_map 26 match address VPN_TO_ABC

crypto map vpn_map 26 set peer ABC

crypto map vpn_map 26 set transform-set 3DES-SHA

tunnel-group 71.X.68.X type ipsec-l2l

tunnel-group 71.X.68.X ipsec-attributes

pre-shared-key *

crypto map vpn_map interface outside

crypto isakmp enable outside

crypto isakmp policy 1

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

crypto isakmp policy 10

authentication pre-share

encryption aes-256

hash sha

group 2

lifetime 86400

crypto isakmp policy 20

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 28800

crypto isakmp policy 30

authentication pre-share

encryption 3des

hash md5

group 2

lifetime 86400

no crypto isakmp nat-traversal

---------------------------------------------------------------------------

name 198.63.227.53 XYZ

access-list VPN_TO_XYZ extended permit ip 192.168.13.0 255.255.255.0 host 10.20.12.127

access-list OUTSIDE_ACCESS_IN extended permit ip host 10.20.12.127 192.168.13.0 255.255.255.0

access-list no_nat0 extended permit ip 192.168.13.0 255.255.255.0 host 10.20.12.127

nat (inside) 0 access-list no_nat0

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto map outside_map 1 match address VPN_TO_XYZ

crypto map outside_map 1 set peer XYZ

crypto map outside_map 1 set transform-set ESP-3DES-SHA

crypto map outside_map interface outside

crypto isakmp enable outside

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

tunnel-group 198.X.227.X type ipsec-l2l

tunnel-group 198.X.227.X ipsec-attributes

pre-shared-key *

Re: IPSec - "All IPSec SA proposals found unacceptable!"

Patrick0711 — Mon, 22 Jun 2009 03:15:57 GMT

The debug messages indicate a problem with the IKE phase 2 quick mode negotiation.

Is there a dynamic crypto map configured with a lower priority number in the first configuration?

I also noticed that the encryption domains do not match. One end specifies 192.168.13.0/24 while the other end specifies the 192.168.13.3 host. This will need to be corrected.

Re: IPSec - "All IPSec SA proposals found unacceptable!"

techsupport — Mon, 22 Jun 2009 04:55:03 GMT

Thanks for your help, we (the other side of the tunnel) seemed to have matched enough of the ISAKMP to create a whole new problem.

I'll start a new post