问题现象

某客户网络拓扑大致如图所示,MSR36作为公司出口路由器,需要通过ipsec隧道来访问位于微软公有云服务器上的资源,微软云服务器侧采用ikev2的方式来建立ipsec,所以需要我们设备侧也采用ikev2的方式,但是在建立隧道的过程中,发现隧道无法建立。

原因分析

建立IPSec隧道时候,发现本端存在ikev2 sa,但是没有ipsec sa。检查本端配置,配置未发现问题,从未建立成功的debug ikev2的过程来看,发现如下报错:

*Jan 12 10:34:29:986 2018 MSR3640 IKEV2/7/EVENT: vrf = 0, src = A.A.A.A, dst = B.B.B.B/500

[IKE->IPsec] Send get IPsec policy request.

*Jan 12 10:34:29:988 2018 MSR3640 IKEV2/7/FSM: vrf = 0, src = A.A.A.A, dst = B.B.B.B/500

Construct NOTIFY payload: TS_UNACCEPTABLE.

该报错表示ikev2ipsec get sp失败导致协商失败。需要检查两端配置是否匹配,或者打开ipsec debug,收集下协商过程中,看下ikev2ipsec get sp处理时,有什么报错。从收集的debug ipsec信息来看,有如下报错:

*Jan 15 15:04:30:146 2018 MSR3640 IPSEC/7/EVENT:

The policy's acl or ike profile does not match the flow, Name = ipsec1, Seqnum = 1

从该报错可以看出协商流和ipsec acl不匹配,这种错误一般都是两端配置不匹配,导致协商失败。需要确认下两端协商流是否在acl保护范围内。

从微软侧了解到,微软侧进行ipsec建立的时候,采用了基于SVTI建立ipsec sa,即采用隧道的方式建立ipsec,该隧道的模式为ipsec模式;我司侧使用物理口引用ipsec policy方式与微软云对接。ikev2协商过程中,微软云发过来的流信息为保护tunnel口上的所有流量,即permit all,而我司配置的流范围窄,导致获取sp失败。所以解决的办法有两个:我们路由器采用SVTI的方式与微软对接,即设备创建interface tunnel number mode ipsec,或者保护的ACL流允许所有的流量。

解决办法

1、MSR36路由器采用基于tunnel口的ipsec建立方式。

2、修改ipsec保护的数据流,允许所有的流量进行ipsec封装。

建议与总结

与第三方设备对接ipsec的时候,建议先了解下第三方设备建立ipsec的方式,在出现问题的时候,可以debug查看具体的交互过程,这样才可以找到问题的原因。

案例信息

案例类型:经验案例
案例号:201804090005
创建时间:2018年4月9日
更新时间:2018年5月29日
发布时间:2018/4/26 17:20:37
文章密级:游客可见
有效期:长期有效
发布者:杨楠 [y11770]
点击次数:1951
评论平均得分:0
关键词:IPSec,微软公有云
产品线:中低端路由器
产品系列:
产品版本:
故障类型:

常用操作
收藏