飞塔和飞塔对接注意事项

1.尽量优先使用默认的接口模式IPsec VPN

2.静态IP地址方式对接的IPsec VPN第二阶段可以不需要填写明细感兴趣流网段，使用默认的0.0.0.0/0.0.0.0即可，感兴趣流通过路由来引导

3.动态拨号方式对接的IPsec VPN，总部侧（HUB）第二阶段可以不需要填写明细感兴趣网段，可使用默认的0.0.0.0/0.0.0.0即可，而分部侧（SPOKE）第二阶段必须填写明细的感兴趣流，以便让总部侧（HUB）可以动态的学习去往分部（SPOKE）的业务网段（自动生成路由），以及反向的感兴趣流

4.配置多个动态拨号方式IPsec/动态拨号方式IPsec与静态IPsec方式混用的时候，需要使用Peer ID区分不同的IPsec VPN连接

5.动态拨号方式IPsec的连接隧道数目较大，此时推荐使用策略模式的IPsec VPN

飞塔和友商对接注意事项

1.第二阶段是否需要填写明细，根据友商的配置要求来定，比如思科的ACL+IPsec方式，则FortiGate必须配置匹配的第二阶段感兴趣流

2.第二阶段存在多个感兴趣流，FortiGate可以尝试配置多个第二阶段或者将感兴趣流配置成IP-Group<->IP-Group。如果对方只能配置一条感兴趣流，那么可以尝试扩大感兴趣流的子网掩码（汇总感兴趣流网段）

3.注意Peer-ID的一致性，双方的Loacl ID 和Peer ID需反向对应起来

4.如果IPsec VPN协商不成功，需要查看双方的IPsec协商报错日志，查找协商失败的线索

IPsec隧道协商失败定位步骤：第一步

先通过sniffer抓包确认用于协商的IKE协议UDP 500是否通信正常（202.106.2.1为对方的公网IP地址），是否中间ISP出现了故障，正常应该有去有回：

FGT#diagnose sniffer packet any “host 202.106.2.1 and (port 500 or port 4500)” 4 0 l

12.650762 wan1 out 119.100.1.35.500 -> 202.106.2.1.500: udp 716

12.652838 wan1 in 202.106.2.1.500 -> 119.100.1.35.500: udp 192

12.664391 wan1 out 119.100.1.35.500 -> 202.106.2.1.500: udp 380

12.665846 wan1 in 202.106.2.1.500 -> 119.100.1.35.500: udp 380

要注意：有时候需要关闭IPsec第一阶段里的NP加速，才可以抓取到完整的IKE协商过程。

FGT # config vpn ip phase1-interface

FGT (phase1-interface) # edit Center

FGT (Center) # set npu-offload disable

FGT (Center) # end

只有确保UDP 500/UDP 4500通信正常，才有接下来协商产生，才有协商成功或失败的定位，因此这是排查的第一步。

IPsec隧道协商失败定位步骤：第二步

然后，通过日志信息以及debug app ike 确认问题是出在Ipsec 协商第一阶段还是第二阶段

diagnose vpn ike log-filter dst-addr4  202.106.2.1 //IP换成对方公网IP

diagnose debug  application ike  -1

diagnose debug  enable

要注意：debug app ike的时候，自己不要主动发起连接，否则可能看不出故障的原因，特别是和友商对接的时候，由于报错的信息格式不一致，友商的报错信息，我们未必可以准确的读出来，而如果是被动接受协商，报错信息则在本地产生，应该一定可以知道协商失败的原因所在，因此我们需要把第一阶段/第二阶段的自动协商关闭。

排错举例1：Center和Side均为静态固定IP的IPsec VPN场景 （预共享密钥认证 ） Debug协商全过程（静态VPN 主模式）

 正常IPsec VPN协商全过程：

 第一阶段：主模式6个包

 第二阶段：快速模式3个包

 协商失败的错误情况dbeug举例：