SecPath F1080+IPSec VPN协商失败
- 0关注
- 1收藏，1335浏览
问题描述：
*Dec 5 13:00:28:442 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; IKE thread 1099297116848 processes a job. *Dec 5 13:00:28:442 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; Info packet process started. *Dec 5 13:00:28:442 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; Received informational exchange packet, but IKE SA is inexistent or incomplete. *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; Received packet successfully. *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/PACKET: -COntext=1; vrf = 0, local = 172.1.0.2, remote = 218.202.218.131/500 Received packet from 218.202.218.131 source port 500 destination port 500. *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/PACKET: -COntext=1; vrf = 0, local = 172.1.0.2, remote = 218.202.218.131/500 I-COOKIE: a36e683fe39392f4 R-COOKIE: de02b7083361c77d next payload: KE version: ISAKMP Version 1.0 exchange mode: Main flags: message ID: 0 length: 220 *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; IKE thread 1099297116848 processes a job. *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/EVENT: -COntext=1; Phase1 process started. *Dec 5 13:00:32:445 2019 XTNY_F1080 IKE/7/PACKET: -COntext=1; vrf = 0, local = 172.1.0.2, remote = 218.202.218.131/500 Discard duplicate packet with no response.
组网及组网描述：
对接对端是启明星辰防火墙
- 2019-12-05提问
- 举报
-
(0)
最佳答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
是的，ike sa没有起来，对端配置已经核对过几遍了，问题依旧
3.1 当两边均没有任何ike/ipsec sa 1. 首先检查两端设备是否可以相互ping通，保证两端设备通信正常。 2. 检查两端设备配置是否一致，主要从感兴趣流、预共享密钥确认一致、ike算法确认一致。 3. 确认下两端设备出接口上是否有NAT业务，如果有NAT业务的话，流量会先匹配NAT模块走掉而不匹配IPSec，所以需要在NAT的acl中先配置rule deny掉感兴趣流。对于V5平台的设备就方便得多，可以在外网口配置ipsec no-nat-process enable这个命令来实现。 4. 还有一种情况，FW1-----路由器，做野蛮模式的ipsec vpn,已经针对acl 3200这条保护流建立了一条ipsec vpn隧道了，客户参照这个在两端针对这个acl 3201再做一条ipsec vpn，就是建立不起来，连lke sa都没有。 其中acl advanced 3200 rule 0 permit ip source 10.100.0.0 0.0.255.255 destination 192.168.2.0 0.0.0.255 # acl advanced 3201 rule 0 permit ip source 10.100.0.0 0.0.255.255 destination 10.103.10.0 0.0.0.255 # 这样的话，两个感兴趣流的源IP是同一个网段，这样在协商的过程中可能出现一些错误，需要在对端配置ipsec策略的时候需要写fqdn而不能写address。 5. 注意下面这一种情况： ike profile 1 keychain 1 local-identity address 221.238.76.226 match remote identity address 0.0.0.0 0.0.0.0 proposal 1 2 3 4 5 6 # ike profile GE1/0/0_IPv4_5 keychain GE1/0/0_IPv4_5 local-identity address 221.238.76.226 match remote identity address 0.0.0.0 0.0.0.0 proposal 65534 以上配置有冲突，这条流在匹配profile的时候就会看到两个local和remote都包含的，所以他选择了proposal号大的去匹配，所以出现debug里面Failed to find proposal 4 in profile GE1/0/0_IPv4_5。 另外也要注意，如果配置了多个号码不一样的proposal，而且这些proposal中的算法一样的话，配置中profile引用的是号小的proposal也是有问题的，会优先匹配算法一致的大号的proposal，需要注意保持配置的清洁性，不要配置多余的配置，如果有多个profile使用一样的算法，可以只配置一个proposal给多个profile来引用。