Ipsec在H3C MSR 810 与飞塔防火墙之间建立,保护的是192.168.240.0/24到192.168.101.0/24之间私网数据流。
在H3C MSR 810和Test Fortigate之间已经成功建立IPsec隧道。阶段1(IKE V2)和阶段2(IPsec)都已建立。MSR 810侧私网地址192.168.240.1 ping 192.168.101.153,但只有一个icmp数据包能通。
在H3C MSR 810和Test Fortigate的外网口抓包看。Test fortigate已经收到了MSR 810的加密ESP包,但是Test fortigate只回复了一个。 ping成功回一个包的情况有两种:
1)当重置H3C MSR路由器中的ike或ipsec会话时,Test Fortigate会回复一个数据包。
2)MSR下的终端持续ping,Test Fortigate会偶尔回复一个包。
进行如下测试:
1)当在 MSR 810和Test Fortigate中使用IKE v1时,ping测试是没有问题的,所有包都能通。
2)使用两个相同型号的H3C MSR设备相互连接,用IKE v2也没有问题。
3)测试了Fortigate的2个版本,都有这个问题: FortiOS v6.4.5 build1828(GA) /FortiOS v7.0.0 build 0066(最新版本)
在MSR上看Ipsec加密后的ping包ESP包已经发出,且已经到达了Fortigate侧,对端外网口抓包看只回了一个,这个需要重点排查Fortigate侧。
默认情况下, Fortigate侧中NPU Offload Function处于启用状态,在Fortigate侧禁用NPU卸载功能时,故障恢复。
似是 飞塔防火牆 既防禦機制, 因會把不正確的 SPI 報文丟棄。 ***.***/document/fortigate/7.0.2/administration-guide/201046/blocking-unwanted-ike-negotiations-and-esp-packets-with-a-local-in-policy 加上, NP6 係ASIC chipset 來, 這會影響服務品質。 但同時, 飞塔對其他品牌既防火牆既 IKEV2 如 帕洛阿托, SonicWall , 及云計算如 Azure 及 AWS 都正常通訊。 所以希望來緊H3C 可以正視看如何解決, 而不只會滿足這就是最終方案。
(0)
严重同意,如果飞塔侧由于客户原因不能修改这个配置呢,难道H3C就不卖这个产品了吗
接楼主问题补充,我遇到H3C 的IPSEC VPN对接飞塔存在第一个ping通,后续ping丢包问题解决方法:
1、在对应策略里面关闭auto-asic-offload 功能:
FGT # config firewall policy
FGT (policy) # edit 27 //Note that 27 here is the policy ID number, not the policy sequence number. Modify the strategy corresponding to arch.
FGT (27) # set auto-asic-offload disable //Temporarily turn off NP acceleration in the policy
2、在对应隧道关闭NPU功能:
config vpn ipsec phase1-intercae
edit“jude”
set type ddns
......
cllin(jude)#set npu-offload disable
在飞塔端配置上述命令后,ping一直正常。
(0)
✖
案例意见反馈
亲~登录后才可以操作哦!
确定你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作