HUAWEI USG6000E, USG6000, USG9500, NGFW Module V500, V600 维护宝典
IPSec隧道建立失败导致业务不通
故障案例：IKE安全提议参数不一致
现象描述
如图1所示，FW间部署IPSec后，PC间互访不通。
- 在FW1上执行命令display ike sa发现IKE SA没有建立成功。
<FW1> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 1342 0.0.0.0 RD|A v2:1 Number of IKE SA : 0 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW1上执行命令display ike error-info查看IKE协商失败原因为phase1 proposal mismatch，说明两端IKE安全提议参数不一致。
<FW1> display ike error-info current info Num :2 Ike error information: current ike Error-info number :2 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 2.1.1.1 500 phase1 proposal mismatch v2 2017-09-05 15:22:32 2.1.1.1 500 phase1 proposal mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
相关告警与日志
无
原因分析
IKE安全提议中参数不一致，例如：认证算法、加密算法、DH密钥交换参数。
操作步骤
- 执行命令display ike proposal [ number proposal-number ]，查看两端的IKE安全提议参数是否一致。
<FW1> display ike proposal number 10 ------------------------------------------- IKE Proposal: 10 Authentication Method : PRE_SHARED Authentication Algorithm : SHA2-256 Encryption Algorithm : AES-128 Diffie-Hellman Group : MODP-2048 SA Duration(Seconds) : 86400 Integrity Algorithm : HMAC-SHA2-256 Prf Algorithm : HMAC-SHA2-256 ------------------------------------------- <FW2> display ike proposal number 10 ------------------------------------------- IKE Proposal: 10 Authentication Method : PRE_SHARED Authentication Algorithm : SHA2-256 Encryption Algorithm : AES-256 Diffie-Hellman Group : MODP-2048 SA Duration(Seconds) : 86400 Integrity Algorithm : HMAC-SHA2-256 Prf Algorithm : HMAC-SHA2-256 -------------------------------------------
从上可以看出Encryption algorithm不一致。
- 更改IKE安全提议中不一致的参数。
由于两端Encryption algorithm不一致，所以在FW1修改加密算法。
ike proposal 10 encryption-algorithm aes-256
修改后，IPSec隧道建立成功，PC间可以互相访问。
建议与总结
配置IPSec时，需先保证路由可达，否则IKE协商肯定失败。
配置IPSec时，务必保证IKE安全提议一致，特别是与其他厂商设备对接时，有些缺省参数不一样，使用默认的参数时，就会导致IKE SA协商失败。当无法获取其他厂商设备的配置信息时，可以在本端设备执行命令debugging ikev2 all查看其他厂商设备发送过来的IKE安全提议信息。
用户在Debugging信息中可以查看本端解析的IKE安全提议。例如：
IKE_INFO 47:2699 Number of proposal : 1 IKE_INFO 47:2868 Proposal No 1: Protocol ID: ISAKMP IKE_INFO 47:2521 ENCRYPTION ALGORITHM: AES_256 //加密算法 IKE_INFO 47:2274 INTEGRITY ALGORITHM: SHA_256 //加密算法 IKE_INFO 47:2243 PRF ALGORITHM: SHA2_256 //伪随机数产生函数的算法 IKE_INFO 47:2308 GROUP_TYPE: MODP_1024 //DH密钥交换参数
如果用户使用IKEv1协议，则执行命令debugging ikev1 all查看本端解析的IKE安全提议。例如：
IKE_INFO 17:3513 Message from peer 1.1.1.1: validate payload SA IKE_INFO 17:813 Message from peer 1.1.1.1: Parsing payload PROPOSAL IKE_INFO 17:813 Message from peer 1.1.1.1: Parsing payload TRANSFORM IKE_INFO 2:2924 Attribute ENCRYPTION_ALGORITHM value AES_CBC //加密算法 IKE_INFO 2:2924 Attribute KEY_LENGTH value 256 //加密算法长度 IKE_INFO 2:2924 Attribute HASH_ALGORITHM value SHA2-256 //认证算法 IKE_INFO 2:2924 Attribute AUTHENTICATION_METHOD value PRE_SHARED //认证方法 IKE_INFO 2:2924 Attribute GROUP_DESCRIPTION value MODP_1024 //DH密钥交换参数 IKE_INFO 2:2924 Attribute LIFE_TYPE value SECONDS IKE_INFO 2:2924 Attribute LIFE_DURATION value 86400 //IKE SA的生存周期
故障案例：预共享密钥不一致
现象描述
如图1所示，FW间部署IPSec后，PC间互访不通。
- 在FW1上执行命令display ike sa发现IKE SA没有建立成功。
<FW1> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 1342 0.0.0.0 RD|A v2:1 Number of IKE SA : 0 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW1上执行命令display ike error-info查看IKE协商失败原因为authentication fail，说明身份认证失败。
<FW1> display ike error-info current info Num :2 Ike error information: current ike Error-info number :2 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 2.1.1.1 500 authentication fail v2 2017-09-05 15:22:32 2.1.1.1 500 authentication fail v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
两端采用IKEv1协商时，如果预共享密钥不一致，则执行命令display ike error-info显示失败原因为malformed-message或authentication fail。
相关告警与日志
无
原因分析
两端预共享密钥不一致。
操作步骤
- 执行命令display ike proposal [ number proposal-number ]，查看两端的认证方法是否为预共享密钥认证。
例如在FW1上查看。
<FW1> display ike proposal number 10 ------------------------------------------- IKE Proposal: 10 Authentication Method : PRE_SHARED Authentication Algorithm : SHA2-256 Encryption Algorithm : AES-128 Diffie-Hellman Group : MODP-2048 SA Duration(Seconds) : 86400 Integrity Algorithm : HMAC-SHA2-256 Prf Algorithm : HMAC-SHA2-256 -------------------------------------------
如果两端Authentication Method不一致，请修改一致。还没解决时，请修改预共享密钥。
- 更改预共享密钥。
假设两端的预共享密钥认证密钥为huawei@123。
ike peer spub pre-shared-key huawei@123
修改后，IPSec隧道建立成功，PC间可以互相访问。
故障案例：IKE对等体remote地址不匹配
现象描述
如图1所示，FW间已成功建立IPSec隧道。当在FW1的公网接口增加了sub地址并修改某些配置后，发现IPSec隧道建立不成功。经检查，两端IPSec和IKE参数配置均正确。
- 在FW2上执行命令display ike sa发现IKE SA没有建立成功。
<FW2> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 83891196 1.1.1.5:500 NEG|A v2:1 Number of IKE SA : 1 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW2上执行命令display ike error-info查看IKE协商失败原因为peer address mismatch，说明两端的IKE对等体remote地址不匹配。
<FW2> display ike error-info current info Num :1 Ike error information: current ike Error-info number :1 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 1.1.1.5 500 peer address mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
- 查看FW1接口配置的sub地址。
interface GigabitEthernet0/0/1 ip address 1.1.1.1 255.255.255.0 ip address 1.1.1.5 255.255.255.0 sub ipsec policy map1
相关告警与日志
无
原因分析
发起方的本端地址与响应方配置的对端地址不一致。
操作步骤
- 执行命令display ike peer [ name peer-name ]，查看两端的IKE对等体地址是否匹配。
<FW1> display ike peer name b ------------------------------------------------ Peer name : b IKE version : v2 VPN instance : - Remote IP : 2.1.1.1 Authentic IP address : - Proposal : 10 Pre-shared-key : %^%#=Q90U4SSw&~$c]YM.}!$}HWfFOm+G&i@`BW'7ETS%^ %# Local ID type : IP Local ID : - Remote ID type : - Remote ID : - ......... ------------------------------------------------ <FW2> display ike peer name b ------------------------------------------------ Peer name : a IKE version : v2 VPN instance : - Remote IP : 1.1.1.5 Authentic IP address : - Proposal : 10 Pre-shared-key : %^%#.SBO>Q{o#@_BHQ/%ULL;f3%rOo4+*3fs3TI7sX\'%^ %# Local ID type : IP Local ID : - Remote ID type : - Remote ID : - .......... ------------------------------------------------从显示信息可以看出，FW2配置的对端地址为FW1接口的sub地址，而IKE协商时，缺省情况下，FW1使用接口的主地址作为本端地址，所以发起方的本端地址与响应方配置的对端地址不一致，导致IKE SA协商失败。
- 修改FW1的本端地址。
ipsec policy map1 10 isakmp tunnel local 1.1.1.5
修改后，IPSec隧道建立成功，PC间可以互相访问。
建议与总结
对于ISAKMP方式安全策略，一般不需要配置IPSec隧道的本端地址，SA协商时会根据路由选择IPSec隧道的本端地址。而如下情况则需要配置本端地址：
- 当安全策略实际绑定的接口IP地址不固定或无法预知时，可以执行命令tunnel local ip-address指定设备上的其他接口（如LoopBack接口）的IP地址作为IPSec隧道的本端IP地址，也可以执行命令tunnel local applied-interface指定安全策略应用接口的地址作为IPSec隧道的本端IP地址。
- 当安全策略实际绑定的接口配置了多个IP地址（一个主IP地址和多个从IP地址）时，可以执行命令tunnel local ip-address指定其中一个IP地址作为IPSec隧道的本端IP地址，也可以执行命令tunnel local applied-interface指定该接口的主地址作为IPSec隧道的本端地址。
- 当本端与对端存在等价路由时，可以执行tunnel local{ ip-address | applied-interface }，来指定IPSec隧道的本端IP地址。
故障案例：IPSec安全提议参数不一致
现象描述
如图1所示，FW间部署IPSec后，PC间互访不通。
- 在FW1上执行命令display ike sa发现IPSec SA没有建立成功。
<FW1> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 83891320 2.1.1.1:500 RD|A v2:1 Number of IKE SA : 1 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW1上执行命令display ike error-info查看IKE协商失败原因为phase2 proposal or pfs mismatch，说明两端IPSec安全提议参数或PFS算法不一致。
<FW1> display ike error-info current info Num :2 Ike error information: current ike Error-info number :2 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 2.1.1.1 500 phase2 proposal or pfs mismatch v2 2017-09-05 15:22:32 2.1.1.1 500 phase2 proposal or pfs mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
相关告警与日志
无
原因分析
两端IPSec安全提议参数或PFS算法不一致。
操作步骤
- 执行命令display ipsec proposal [ name proposal-name ]，查看两端的IPSec安全提议参数是否一致。
<FW1> display ipsec proposal name tran1 IPSec proposal name: tran1 Encapsulation mode: Tunnel Transform : esp-new ESP protocol : Authentication SHA2-HMAC-512 Encryption AES-128 <FW2> display ipsec proposal name tran1 IPSec proposal name: tran1 Encapsulation mode: Tunnel Transform : esp-new ESP protocol : Authentication SHA2-HMAC-512 Encryption AES-256从上可以看出两端IPSec安全提议的加密算法不一致。
- 更改IPSec安全提议中不一致的参数。
由于两端加密算法不一致，所以在FW1修改加密算法。
ike proposal 10 encryption-algorithm aes-256
修改后，IPSec隧道建立成功，PC间可以互相访问。
建议与总结
配置IPSec时，务必保证IPSec安全提议一致，特别是与其他厂商设备对接时，有些缺省参数不一样，使用默认的参数时，就会导致IPSec SA协商失败。当无法获取其他厂商设备的配置信息时，可以在本端设备执行命令debugging ikev2 all查看其他厂商设备发送过来的IPSec安全提议信息。
用户在Debugging信息中查看本端解析的IPSec安全提议。例如：
IKE_INFO 47:2699 Number of proposal : 1 IKE_INFO 47:2868 Proposal No 1: Protocol ID: IPSEC_ESP //安全协议类型 IKE_INFO 47:2521 ENCRYPTION ALGORITHM: AES_256 //加密算法 IKE_INFO 47:2282 AUTHENTICATION ALGORITHM: SHA_256 //认证算法
如果用户使用IKEv1协议，则执行命令debugging ikev1 all查看本端解析的IPSec安全提议。例如：
IKE_INFO 17:2267 Proposal No: 1 Protocol ID: IPSEC_ESP //安全协议类型 IKE_INFO 2:1997 ENCRYPTION ALGORITHM: AES //加密算法 IKE_INFO 2:2924 Attribute SA_LIFE_TYPE value SECONDS IKE_INFO 2:2924 Attribute SA_LIFE_DURATION value 3600 //以时间为基准的IPSec SA的生存周期 IKE_INFO 2:2924 Attribute SA_LIFE_TYPE value KILOBYTES IKE_INFO 2:2924 Attribute SA_LIFE_DURATION value 1843200 //以流量为基准的IPSec SA的生存周期 IKE_INFO 2:2924 Attribute ENCAPSULATION_MODE value TUNNEL //封装模式 IKE_INFO 2:2924 Attribute AUTHENTICATION_ALGORITHM value SHA_256 //认证算法 IKE_INFO 2:2924 Attribute KEY_LENGTH value 256 //加密算法长度
故障案例：设备异常重启后，对端设备未删除原有隧道
现象描述
如图1所示，FW间建立IPSec隧道。FW2设备异常重启后，之前与FW1建立的IPSec隧道长时间存在，造成FW1侧的客户端无法访问FW2侧的客户端。
执行命令display ike sa，发现FW1的SA建立成功，FW2的SA建立失败。
<FW1> display ike sa
IKE SA information :
Conn-ID Peer VPN Flag(s) Phase
----------------------------------------------------------------------
8388 2.1.1.1:500 RD|ST|A v2:2
8378 2.1.1.1:500 RD|ST|A v2:1
Number of IKE SA : 2
----------------------------------------------------------------------
Flag Description:
RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT
HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP
M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING
<FW2> display ike sa
在FW1上带源地址Ping不通PC2，但在FW2上带源地址可以Ping通PC1，再在FW1上执行命令display ike sa发现SA建立成功，PC1可以Ping通PC2。
相关告警与日志
无
原因分析
对于流量触发SA协商，FW2重启后，SA被清空，但FW1上的SA尚未到达生存周期（IPSec SA默认生存周期为1小时，IKE SA的默认生存周期为24小时），故一直未释放。当从FW1发起访问时，数据流匹配到原有的SA导致新的SA无法建立，所以PC1无法访问PC2。当从FW2发起访问时，数据流触发重新建立SA，SA建立成功后，PC2和PC1可以互相访问。
操作步骤
- 在FW1上手动复位SA。
执行命令reset ike sa后，两端IPSec隧道建立成功。
- 两端配置IKE对等体DPD检测功能。
配置后，IPSec隧道断掉后会自动清除SA，并重新触发SA协商。
DPD检测可以在全局或IKE对等体下配置。系统优先使用IKE对等体下的配置，IKE对等体下未开启DPD检测时才采用全局配置。
两端对等体配置的DPD报文中的载荷顺序需要一致，否则对等体存活检测功能无效。
例如，在全局下配置DPD报文中的载荷顺序为seq-hash-notify、检测模式为periodic、DPD空闲时间20秒、DPD报文重传间隔10秒、重传次数4次。以FW1为例。
<FW1> system-view [FW1] ike dpd msg seq-hash-notify [FW1] ike dpd type periodic [FW1] ike dpd idle-time 20 [FW1] ike dpd retransmit-interval 10 [FW1] ike dpd retry-limit 4
建议与总结
设备支持heartbeat和DPD两种对等体检测功能。推荐开启DPD检测功能。
heartbeat检测和DPD检测的区别：heartbeat检测定期发送报文，本端和对端配置需要匹配；DPD检测中本端和对端不需要匹配（除DPD报文中的载荷顺序需要匹配外），当IKE对等体间有正常的IPSec流量时，不会发送DPD消息，只有当一段时间内收不到对端发来的IPSec报文时，才发送DPD消息，节省了CPU资源。
故障案例：L2TP over IPSec场景，Security ACL未匹配L2TP封装后的地址
现象描述
如图1所示，FW间建立L2TP over IPSec隧道，PC间互访不通。
- 在FW1上执行命令display l2tp tunnel，发现L2TP隧道建立失败。
<FW1> display l2tp tunnel L2TP::Total Tunnel: 0 LocalTID RemoteTID RemoteAddress Port Sessions RemoteName VpnInstance ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Total 0, 0 printed - 在FW1上执行命令display ike sa，发现IPSec SA建立失败。
<FW1> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase ---------------------------------------------------------------------- 83891196 2.1.1.1:500 NEG|A v2:1 Number of IKE SA : 1 ---------------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW1上执行命令display ike error-info查看IKE协商失败原因为flow mismatch，说明Security ACL配置错误。
<FW1> display ike error-info current info Num :2 Ike error information: current ike Error-info number :2 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 2.1.1.1 500 flow mismatch v2 2017-09-05 15:22:32 2.1.1.1 500 flow mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
相关告警与日志
无
原因分析
要想建立L2TP隧道，必须先建立IPSec隧道，转发时先封装L2TP再封装IPSec。
从上面原因可以看出，ACL配置错误导致建立IPSec隧道建立失败，最终导致L2TP隧道建立失败。
操作步骤
- 执行命令display ipsec policy和display acl acl-number查看Security ACL配置是否正确。
<FW1> display ipsec policy =========================================== IPSec policy group: "map1" Using interface: GigabitEthernet0/0/1 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3000 ...... <FW1> display acl 3000 Advanced ACL 3000, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 (0 ti mes matched)FW2与FW1配置类似，这里不再赘述。
从上看出，保护的数据流为PC的目的网段。深入了解L2TP over IPSec原理，经过L2TP封装后，新增IP头，改变了原有的IP地址。所以IPSec保护的数据流不再是PC网段地址，而是L2TP封装后新增IP头里的网段地址。
- 修改Security ACL的配置。
FW1：
acl number 3000 rule 5 permit ip source 1.1.1.0 0.0.0.255 destination 2.1.1.0 0.0.0.255
FW2：
acl number 3000 rule 5 permit ip source 2.1.1.0 0.0.0.255 destination 1.1.1.0 0.0.0.255
修改后，IPSec隧道建立成功，同时L2TP隧道也建立成功。PC间可以互相访问。
建议与总结
对于组合应用的特性，需深入了解原理及转发流程，如L2TP over IPSec，首先进行IPSec协商，建立IKE SA和IPSec SA；然后再建立L2TP隧道。报文在隧道中传输时先进行L2TP封装再进行IPSec封装。IPSec需要保护的是从L2TP的起点到L2TP的终点数据流。L2TP封装过程中增加的IP头即源IP地址为L2TP起点地址，目的IP地址为L2TP终点的地址。
在L2TP over IPSec场景下，若移动办公用户采用搭载Android 6.0操作系统的终端与设备建立IPSec隧道，则隧道双方的认证算法只能使用SHA-1。这是由于Android 6.0系统的SHA2-256算法是根据草案实现的，与RFC标准不一致，如果使用SHA2-256算法建立IPSec隧道，则隧道两端设备将无法正常通信。
故障案例：IPSec与NAT同时部署在一台设备上，业务报文被NAT导致其未能匹配Security ACL
现象描述
如图1所示，PC通过FW进行NAT后访问Internet。FW间部署IPSec，并且使用流量触发协商建立IPSec隧道，部署后，PC间无法互相访问。
- 在FW1上执行命令display ike sa，发现显示为空，说明IPSec隧道建立失败。
<FW1> display ike sa
- 在FW1上执行命令display ipsec statistics，发现outbound ok为零，说明没有发起IKE协商。
<FW1> display ipsec statistics ....... negotiate about packet statistics: IKE fwd packet ok: 0, err: 0 IKE ctrl packet inbound ok: 0, outbound ok: 0 SoftExpr: 0, HardExpr: 0, DPDOper: 0 trigger ok: 0, switch sa: 0, sync sa: 0 recv IKE nat keepalive: 0, IKE input: 0 - 检查发现公私网路由可达和IPSec配置无误。
相关告警与日志
无
原因分析
- Security ACL与待保护数据流不匹配。
- NAT策略干扰IPSec保护数据流。
操作步骤
- 执行命令display ipsec policy和display acl acl-number检查Security ACL配置与待保护数据流是否匹配。
<FW1> display ipsec policy =========================================== IPSec policy group: "map1" Using interface: GigabitEthernet0/0/1 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3000 ...... <FW1> display acl 3000 Advanced ACL 3000, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255 (0 ti mes matched) <FW2> display ipsec policy =========================================== IPSec policy group: "map1" Using interface: GigabitEthernet0/0/1 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3000 ...... <FW2> display acl 3000 Advanced ACL 3000, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 ti mes matched)从上可以看出，Security ACL配置与待保护数据流相匹配。
- 执行命令display current-configuration configuration policy-nat检查NAT策略是否包含待保护数据流。
<FW1> display current-configuration configuration policy-nat rule name policy_nat2 source-zone trust destination-zone untrust source-address 10.1.1.0 0.0.0.255 action source-nat easy-ip
FW2与FW1的配置类似，这里不再赘述。
从上可以看出，NAT策略包含待保护数据流。由于设备优先处理NAT流程，故在IPSec封装之前，PC访问对端的数据流会首先进行NAT转换。所以需经过IPSec封装的数据流不进行NAT转换。以FW1为例。
[FW1] system-view [FW1] nat-policy [FW1-policy-nat] rule name policy_nat1 [FW1-policy-nat-rule-policy_nat1] source-zone trust [FW1-policy-nat-rule-policy_nat1] destination-zone untrust [FW1-policy-nat-rule-policy_nat1] source-address 10.1.1.0 0.0.0.255 [FW1-policy-nat-rule-policy_nat1] destination-address 10.1.2.0 0.0.0.255 [FW1-policy-nat-rule-policy_nat1] action no-nat [FW1-policy-nat-rule-policy_nat1] quit [FW1-policy-nat] rule move policy_nat2 after policy_nat1
需注意的是，配置完新的NAT规则后，还需要执行命令rule move移动NAT策略规则，使得policy_nat1优先生效。
修改后，IPSec隧道建立成功，PC间可以互相访问。
建议与总结
当IPSec与NAT配置在同一台设备时，要确认经过IPSec封装的数据流是否还需要进行NAT转换。
- 如果需要进行NAT转换，则Security ACL要匹配NAT后的地址。
- 如果不需要进行NAT转换，则Security ACL要匹配NAT前的地址。且经过IPSec隧道的数据流不进行NAT转换。
如果自动触发协商建立IPSec隧道，则执行命令display ike sa可以看到IPSec隧道建立成功，但PC间无法互相访问。
故障案例：ACL的rule规则范围不匹配
现象描述
如图1所示，FW间部署IPSec后，PC间无法互相访问。
- 在FW1上执行命令display ike sa，发现IKE SA协商成功，但IPSec SA没有成功，说明IPSec隧道建立失败。
<FW1> display ike sa IKE SA information : Conn-ID Peer VPN Flag(s) Phase --------------------------------------------------------------- 151003222 2.1.1.1:500 NEG|A v1:2 151003215 2.1.1.1:500 RD|A v1:1 Number of IKE SA : 2 --------------------------------------------------------------- Flag Description: RD--READY ST--STAYALIVE RL--REPLACED FD--FADING TO--TIMEOUT HRT--HEARTBEAT LKG--LAST KNOWN GOOD SEQ NO. BCK--BACKED UP M--ACTIVE S--STANDBY A--ALONE NEG--NEGOTIATING - 在FW1上执行命令display ike error-info查看IKE协商失败原因为flow or peer mismatch，说明两端ACL的rule规则范围不匹配。
<FW1> display ike error-info current info Num :2 Ike error information: current ike Error-info number :2 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 2.1.1.1 500 flow or peer mismatch v2 2017-09-05 15:22:32 2.1.1.1 500 flow or peer mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
相关告警与日志
无
原因分析
两端ACL的rule规则范围不匹配。
操作步骤
- 执行命令display ipsec policy和display acl acl-number检查Security ACL的rule规则范围是否匹配。
<FW1> display ipsec policy =========================================== IPSec policy group: "map1" Using interface: GigabitEthernet0/0/1 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3000 ...... <FW1> display acl 3000 Advanced ACL 3000, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.2.2.0 0.0.0.255 (0 ti mes matched) <FW2> display ipsec policy =========================================== IPSec policy group: "map1" Using interface: GigabitEthernet0/0/1 =========================================== Sequence number: 10 Policy Alias: map1-10 Security data flow: 3000 ...... <FW2> display acl 3000 Advanced ACL 3000, 1 rule ( Reference counter 1 ) Acl's step is 5 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 (0 ti mes matched)从上可以看出，两端Security ACL的rule规则范围不匹配。
对于IKEv1，若两端都配置ISAKMP方式IPSec安全策略，发起方配置的ACL规则范围必须是响应方的子集。若一端配置ISAKMP方式IPSec安全策略，另一端配置策略模板方式IPSec安全策略，ISAKMP方式IPSec安全策略的ACL规则的范围可以小于策略模板方式IPSec安全策略的ACL规则，取双方ACL规则交集作为协商结果。
- 修改Security ACL的rule规则范围。
分析发现FW1的Security ACL的rule规则范围错误。
acl number 3000 rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
修改后，IPSec隧道建立成功，PC间可以互访。
建议与总结
配置ACL规则需注意：
- IPSec隧道两端ACL规则定义的协议类型要一致。例如，一端使用IP协议，另一端也必须使用IP协议。
- 当IPSec隧道两端的ACL规则镜像配置时，任意一方发起协商都能保证SA成功建立；当IPSec隧道两端的ACL规则非镜像配置时，只有发起方的ACL规则定义的范围是响应方的子集或两端的ACL规则存在交集时，SA才能成功建立。因此，建议IPSec隧道两端配置的ACL规则互为镜像，即一端配置的ACL规则的源地址和目的地址分别为另一端配置的ACL规则的目的地址和源地址。具体来说：
- 对于IKEv1，镜像不是必要条件，只要发起方配置的ACL规则范围是响应方的子集即可。协商时，取双方ACL规则交集作为协商结果。
- 对于IKEv2，镜像不是必要条件，只要两端的ACL规则存在交集即可。协商时，取双方ACL规则交集作为协商结果。
- ACL中各条rule的地址段要避免出现重叠。因为地址段重叠的rule之间容易相互影响，造成数据流匹配rule规则时出现误匹配的情况。
- 同一个IPSec安全策略组中配置的ACL不能包含相同的rule规则。
- 同一个IPSec安全策略组中所有IPSec安全策略引用的ACL的rule之间不能存在交集。例如引用的ACL3001和ACL3002存在交集：
acl number 3001 rule 5 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255 acl number 3002 rule 5 permit ip source 10.1.0.0 0.0.255.255 destination 10.1.0.0 0.0.255.255
- 协商响应方采用策略模板方式IPSec安全策略时：
响应方可不定义需要保护的数据流，此时表示接受发起方定义的需要保护的数据流范围；如果响应方要指定需要保护的数据流，则需要与发起方镜像配置或者包含发起方指定的保护的数据流范围。
- 如果应用IPSec安全策略的接口同时配置了NAT，由于设备先执行NAT，会导致IPSec不生效，此时需要：
- NAT引用的ACL规则deny目的IP地址是IPSec引用的ACL规则中的目的IP地址，避免对IPSec保护的数据流进行NAT转换。
- IPSec引用的ACL规则匹配经过NAT转换后的IP地址。
故障案例：中间有NAT设备，认证地址不匹配
现象描述
如图1所示，FW间存在NAT设备，FW1经过NAT转换后FW2进行对接，部署IPSec后，PC间互访不通。
- 在FW2上执行命令display ike sa，发现显示为空，说明IPSec隧道建立失败。
<FW2> display ike sa
- 在FW2上执行命令display ike error-info查看IKE协商失败原因。
<FW2> display ike error-info current info Num :3 Ike error information: current ike Error-info number :3 ----------------------------------------------------------------------------------------- peer port error-reason version error-time ----------------------------------------------------------------------------------------- 1.1.1.1 2049 authentication fail v2 2017-09-05 15:22:32 1.1.1.1 2049 config ID mismatch v2 2017-09-05 15:22:32 10.4.1.1 2049 peer address mismatch v2 2017-09-05 15:22:32 -----------------------------------------------------------------------------------------
IKE协商失败原因为authentication fail、config ID mismatch，说明FW2校验FW1发送的ID信息失败。
另外，IKE协商失败原因为peer address mismatch，且peer为10.4.1.1，说明FW1携带的ID为一个私网地址10.4.1.1，造成IKE协商地址1.1.1.1与认证地址10.4.1.1不一致，导致IPSec隧道建立失败。
相关告警与日志
无
原因分析
IKE协商地址与认证地址不一致。
操作步骤
- 执行命令display ike peer查看两端的对等体地址是否匹配。
<FW1> display ike peer Number of IKE peers: 1 ----------------------------------------------------------- Peer name : spr IKE version : v1v2 VPN instance : - Remote IP : 2.1.1.1 Authentic IP address : - Proposal : 10 Pre-shared-key : %^%#VGKG:L@YD(|F>VCrTw2W"Qx<&;6dU2(`ZP9!B"HT%^%# Local ID type : IP ...... <FW1> display ike peer Number of IKE peers: 1 ----------------------------------------------------------- Peer name : spr IKE version : v1v2 VPN instance : - Remote IP : 1.1.1.1 Authentic IP address : - Proposal : 10 Pre-shared-key : %^%#VGKG:L@YD(|F>VCrTw2W"Qx<&;6dU2(`ZP9!B"HT%^%# Local ID type : IP ......
从显示信息可以看出，两端的对等体地址匹配，因为FW1在NAT设备后面，IKE协商时，FW1的协商地址10.4.1.1变为1.1.1.1。
但是，从协商原因分析出IKE协商地址与认证地址不一致。查看配置发现两端都是采用ISAKMP方式IPSec安全策略，此时需在FW2上执行命令remote-address authentication-address配置认证地址。因为FW1位于NAT设备后面，两端采用IP地址认证时，FW2会收到FW1发起IKE协商消息，消息中会携带ID身份信息（私网地址作为自己的ID身份信息），然后FW2将配置的remote-address和收到的FW1的ID身份信息进行比较，发现不一致，造成认证失败。
- 在FW2上执行命令remote-address authentication-address配置认证地址。
ike peer spr remote-address authentication-address 10.4.1.1 10.4.1.255
配置后，两端IPSec隧道建立成功，PC间能相互访问。
建议与总结
两端使用IKEv2协议协商建立IPSec场景中，当对端设备使用的是内网IP地址，穿越了NAT设备时，如果两端采用ISAKMP方式IPSec安全策略，并使用IP地址进行认证，需注意：
- 本端需执行命令remote-address ip-address指定的IP地址为对端NAT转换后的IP地址。
- 本端需执行命令remote-address authentication-address指定NAT转换前的IP地址为对端认证地址。
针对此场景，建议本端采用策略模板方式IPSec安全策略，因为策略模板下不需要执行命令remote-address ip-address指定对端地址。