点到点 Ipsec VPN 从一端能正常发起，另一端发起不成功的解决过程

    集团总部用的cisco 5540防火墙，上面配置了2个动态vpn，若干L2Lvpn。集团总部到各分公司直接用lan to lan ipsce vpn连接，部分分公司到集团总部的vpn能够双向发起，部分分公司，只能从集团端发起vpn后，才能成功建立隧道实现双向通信。下面具体描述下 解决问题的过程。

   首先，肯定是debug了，显示第二阶段协商失败。

********QM FSM error

********Removing peer from correlator table failed, no match!

********Session is being torn down. Reason: Phase 2 Mismatch

   问百度得知，第二阶段主要是协商ipsec sa的，不成功的原因如下：
   1、crypto ipsec transform数据加密方式不匹配。（这个已经核对过N遍，确定没有问题）
   2、感兴趣流不对称 。（感兴趣流，要求两边对称，否则配置范围小的列表的防火墙向对端发起vpn能够成功，反之则不行。）

    以上2条经检查配置没有任何问题，其他原因我们就不分析了，因为从集团端发起vpn是能成功建立的。

   然后考虑，cisco ios 8.2和cisco ios 8.4.5之间版本差异，看是否漏掉某些参数。

   参阅cisco官方文档和网络上的各种资料没有找到相关说明。

   对照 51cto lmfalllove同学的文章：http://bbs.51cto.com/thread-1104422-1.html 也没有发现任何少配置的命令。

   无奈之际， 用debug crypto ikev1 10 命令，并将debug信息导出到文本。挨个分析

   

Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Static Crypto Map check, checking map = BCTDC-map, seq = 33... Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Static Crypto Map check, map = BCTDC-map, seq = 33, ACL does not match proxy IDs src:10.1.3.240 dst:10.128.0.0 Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Static Crypto Map check, checking map = BCTDC-map, seq = 35... Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Static Crypto Map check, map = BCTDC-map, seq = 35, ACL does not match proxy IDs src:10.1.3.240 dst:10.128.0.0 Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, IKE Remote Peer configured for crypto map: dymap Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, processing IPSec SA payload Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, All IPSec SA proposals found unacceptable!  （匹配到bctdc-map的第35条后，开始匹配动态的 dymap，然后宣告匹配失败。） Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, sending notify message Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, constructing blank hash payload Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, constructing ipsec notify payload for msg id b1c09c5d Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, constructing qm hash payload Oct 11 11:57:59 [IKEv1]IP = 123.1**.***.***, IKE_DECODE SENDING Message (msgid=7968f3a8) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE (0) total length : 84 Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, QM FSM error (P2 struct &0x7796b9d0, mess id 0xb1c09c5d)! Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, IKE QM Responder FSM error history (struct &0x7796b9d0)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_NEGO_SA-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, sending delete/delete with reason message Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Removing peer from correlator table failed, no match! Oct 11 11:57:59 [IKEv1]Group = 123.1**.***.***, IP = 123.1**.***.***, Deleting static route for L2L peer that came in on a dynamic map. address: 10.1.3.240, mask: 255.255.255.240 (路由都删了） Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, IKE SA MM:f57c168d rcv'd Terminate: state MM_ACTIVE  flags 0x0001c042, refcnt 1, tuncnt 0 Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, IKE SA MM:f57c168d terminating:  flags 0x0101c002, refcnt 0, tuncnt 0 Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, sending delete/delete with reason message Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, constructing blank hash payload Oct 11 11:57:59 [IKEv1 DEBUG]Group = 123.1**.***.***, IP = 123.1**.***.***, constructing IKE delete payload

等等，为什么匹配到map 35条就不继续往下匹配了？

 我的配置是这样的。

crypto map BCTDC-map 33 set ikev1 transform-set IPsec-××× crypto map BCTDC-map 35 match address h*** crypto map BCTDC-map 35 set peer 111.**.**.**  crypto map BCTDC-map 35 set ikev1 transform-set IPsec-××× crypto map BCTDC-map 50 ipsec-isakmp dynamic dymap （动态的map在这里） crypto map BCTDC-map 51 match address tobct crypto map BCTDC-map 51 set peer 123.1**.**    (我的map在这里，子公司发起的协商根本就没进行到这里。）  crypto map BCTDC-map 51 set ikev1 transform-set IPsec-××× crypto map BCTDC-map 76 match address ho****** crypto map BCTDC-map 76 set peer 1******

  

    说道这里想必大家都明白是什么原因了吧？从子公司发来的第二阶段协商，只协商到动态map 50为止，后面跟着的map 条目，就不协商了。

 将配置中如下配置：   

crypto dynamic-map dymap 50 set ikev1 transform-set Ez×××-Trans

crypto dynamic-map dymap 50 set reverse-route

crypto map BCTDC-map 50 ipsec-isakmp dynamic dymap

改为：

crypto dynamic-map dymap 1000 set ikev1 transform-set Ez×××-Trans

crypto dynamic-map dymap 1000 set reverse-route

crypto map BCTDC-map 1000 ipsec-isakmp dynamic dymap

 

   至此，只能从单方向发起vpn连接的问题得以解决。由于子公司比较多，初期动态×××的map 序列过于靠前，导致超过动态map序列的 条目都不能从子公司发起vpn连接。

   往上找过很多资料都没有提到过此种情况，故此记录下来，希望能帮到遇到类似问题的同学。