IPSec故障排错之路

前言

IPSec从原理、各个场景已经介绍过很多了，但是对于IPSec来说配置其实理解了原理还是不难的，难就难在出现故障，或者说建立不起来等情况，这个时候就需要依赖之前学过的原理跟经验了，原理自己可以多学掌握，经验除了自己积累，还的借助下网络前辈分享的经验，都能够获取有用的帮助，建议配合第37篇以及视频讲解更加，很多现象只能视频才能看出来。

IKE第一阶段容易遇到的问题

（1）IKE没任何反应的可能性

这个时候第一想到的是防火墙的安全策略是否放行了，因为IKE与IPSec隧道建立，依赖于Local与untrust（外网接口所在区域）的安全策略，如果没有放行，那么IKE是发起不了的

安全策略放行了，但是还是没有显示，就要查看内外网路由，内网访问对方的数据包，是否抵达了防火墙（可以通过会话表看），如果数据包都没抵达，那么防火墙根本不会去触发建立。如果抵达了，没有触发建立，则看去往对方的路由出口是否跟IPSec调用的接口是一致，因为只有走这个出口出去，才能够触发IKE的协商。

IPSEC调用的接口是否正确，如果接口下没调用或者调用错了接口也会发生没反应的情况。

如果遇到问题建议用流量发起形式建立IPSec，不用自动建立，方便排错。

排错查看命令跟步骤

display interface |     display ip interface br ：查看当前内外网接口是否正常，排除掉接口跟链路问题

display ip     routing-table：查看去往内网跟外网的路由是否正常

Ping x.x.x.x ：路由正确的情况下内网是否能够通，以及ping -a 源地址 | 目的地址形式。（有的场景有多出口，可能流量并没有从防火墙出去）

display firewall     session table | display firewall statistic ：查看是否有会话信息以及安全策略丢包导致的情况，只有安全策略正常配置才能够发起建立。

Display firewall     server-map | display      current-configuration configuration policy-pbr：来查看是否有NAT server与策略路由影响了。

display  acl ：数据流是否匹配，如果数据流不匹配是不会触发IKE建立的（自动建立除外）

display ike sa | display  ipsec      statistics：查看当前IKE的发送与接收包的情况，如果有状态显示，说明防火墙已经开始正常发包了，故障解除。

（2）IKE协商不成功的常见故障解析

IKE协商不成功，最终会体现在IKE的SA里面，通过display ikesa就可以查看，里面的flag会体现出来，目前为第一阶段，状态是NEG|A，表示在协商中，一定时间内（通常几十秒）没协商起来的话，则会删除。

这种通常是IKE第一阶段没有成功，但是第一阶段里面协商的内容非常的多，这个时候就需要来进行排错了。（这里说下经验，通常情况下排错两边能同时登录一起查看是最佳的，因为建立是两台设备之间的，无法确定问题出在哪台设备上面，所以一起排查更加容易定位到问题，但是在实际中会有很多情况出现，比如你只有一边的登录权限、或者无法登录到对方设备等情况，这个时候也只能先从一端开始排查）

安全策略检查是否正确，建议开启PING允许，方便定位。（就算不允许，排查的时候开启下，后续在关闭）

ping：双方各自ping对方的公网地址，检测基本的连通性。（如果基本连通性都没通，那么对方可能没收到发送过去的IKE协商包，）

display ike proposal：检查两边的IKE安全提议是否一致（认证方式、认证算法、加密算法、DH组、生存时间）

display ike peer：检查两边的参数，这里面的参数就比较重要

（1）remote-address一定要是对方用于IPSec建立的地址。（可能对方存在多个公网IP）

（2）NAT穿越，虽然在华为下一代防火墙里面是默认开启的，但是在华三、华为路由器以及其他厂商里面是没有开启的，并且有的厂商必须要在野蛮模式下才能够进行。

（3）模式：双方一定要处于同一个模式下面，比如主模式或者都是野蛮模式，否则会协商失败。

（4）共享密钥：这个双方一定要保持一致，否则建立不起来。

（5）调用安全提议：这个容易被忽略，忘记调用了，造成两边提议不一样，如果不调用，可能会采用默认的策略（不同厂商有差异）

（6）版本：双方要用相同的版本，比如IKEV1或者IKEV2，注意配置上面的细节问题，像下一代防火墙中，两个版本默认都开启，但是以IKEV2发起优先，但是很多现网中只支持IKEV1的。

（7）ID类型：这个在一端有固定/动态公网IP，一端没有的的情况下特别要注意，大部分以野蛮模式为主，并且起别名的方式来对接，这个时候要注意remote-id-type与local-id-type的匹配。（TP、华三的ER/GR系列路由器、Juniper NS防火墙为分支的时候要特别注意）

display  ipsec      statistics：双方通过查看数据包是否有IKE发起，是否有IKE收到，这样可以判断IKE的包是否双方都能收到没有被限制。（有的地方可以ping通，但是有可能会限制IKE的包）

当这些都检查完毕了，还是没有发现问题？这个也是实际中最头疼的，第一个就靠经验了，第二个利用debug。

（这里特别强调：启用debug的时候，一定要注意精确问题，不要全部开启，否则容易导致设备死机，特别是现网环境！）

terminal monitor

terminal debugging

debugging ikev1 error

Apr  6 2021 12:26:40.250.1 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:10315 Ikev1 error-info record(peer address:202.100.2.1, error reason: phase1 proposal mismatch,list number: 16).

第一阶段的安全提议不匹配，这个时候就要检测两边的IKE安全提议了。

Apr  6 2021 12:32:56.60.3 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:8030 Exchange-mode mismatch for peer"202.100.2.1", received exchange type is ID_PROTECTION, localconfiguration (exchange type is AGGRESSIVE, not auto mode, compatiable mode isnot compatible).

Apr  6 2021 12:32:56.60.4 BJ_FWIKE/7/IKE_DEBUG:IKE_ERROR 0:10315 Ikev1 error-info record(peer address:202.100.2.1, error reason: exchange mode mismatch,list number: 34).

两边peer的模式不对，可能一边是主模式，一边是野蛮，这里列举了排错解决的思路与常见的问题，常见的第一阶段错误都能够解决，其余特殊的就要依靠经验了。当第一阶段完成后，会进入第二阶段。（用完后记得关闭debug，直接输入un debug all，全部关闭）

当出现了这个状态的时候，就说明第一阶段已经协商OK了，卡在了第二阶段，第二阶段排错步骤（双方都要看）

display  ipsec      proposa：检查双方第二阶段的安全提议是否一致。

display acl all：检查双方受保护流量是否为“镜像”

display ipsec  policy ：能查看到当前Policy下面调用的内容是否正确，接口调用是否正确。

当然还是没定位到问题的话，也可以用debug，还是强调用最精细的显示。

terminal monitor

terminal debugging

debugging  ipsec error

Apr  6 2021 13:08:20.850.1 BJ_FWIPSEC/7/IPSEC-DEBUG:

[IPSEC-Error]flow or peer mismatch.(Ifindex=[7], SeqNum=[0],PeerAddress=[202.100.2.1],PeerPort=[500]

提示flow or peer 不匹配，这种提示通常指的是ACL里面两边的内容不匹配

Apr  6 2021 13:13:34.760.2 BJ_FWIPSEC/7/IPSEC-DEBUG:

[IPSEC-Error]phase2 proposal mismatch.(Ifindex=[7], SeqNum=[0],PeerAddress=[202.100.2.1],PeerPort=[500])

Apr  6 2021 13:13:35.390.1 BJ_FWIPSEC/7/IPSEC-DEBUG:IPSEC_ERROR 20:1363 IKE is negotiating SA for IPsec policy:p1-10

这个提示主要看phase2 proposal mismatch，这个提示的是第二阶段的安全提议不匹配。（这里要注意PFS，有的厂家默认是开启的，容易被忽略）

IPSec隧道终于起来了，业务不通？

隧道建立起来后，业务不通，这个也是比较常见的，这里介绍比较容易遇到的情况。

（1）client1发出的数据包能够正常抵达BJ防火墙以及转发出去。（可能会遇到内网是三层交换机当网关等场景，但是没写路由过来）

（2）安全策略明确放行了

Client1与server1的双向放行，如果单向的话，可能会出现一边可以通，一边不能通的情况

Local与untrust之间的IKE 500、4500、ESP双向放行

NAT策略，通常会配置trust到untrust的NAT策略，如果配置了一定要配置nonat，顺序要放到前面

互联网设备没有过滤UDP 500/4500、ESP报文（通过display  ipsec      statistics可以看加解密情况来判断）

CS防火墙需要有到server1的路由，保障连通性（包括安全策略放行等，否则会造成单向通）

IPSec性能等问题

在实际中也会遇到IPSec建立后，比如丢包、延迟大、不稳定等情况，特别是多厂商的情况下，那么这种情况下排错就非常困难，只能采用一些排除法，把能判断的先排除掉。

1、IPSec反复进行隧道协商建立

两边之间运营商链路不稳定，这种情况可能出现在不同运营商之间的情况会多些。

DPD的时间检测太快，导致误认为对方出现问题，把SA信息清除掉了。

生存时间：IKE默认的时间为一天，IPSec SA则为一小时，但是在华为里面还有一个流量的生存时间，这个流量生存时间，有的厂商并不支持，如果分支到总部的流量非常大，把这个流量生成时间消耗完了，但是分支感知不到，那么总部这边会把SA信息清空，更糟糕的是如果总部是模板形式的话，不能主动发起建立，导致隧道断开。

2、设备性能不够

防火墙承载的业务不单单有IPSec，可能还有策略路由、安全策略、选路、以及IPS等，这个时候都一起工作的时候，随着IPSec的隧道越多，流量越大，就会出现性能不够的情况，特别是在分支之间的流量都通过总部去访问的时候，对总部设备的压力更大。

display  cpu-usage：查看CPU的利用率，是否超过80%以上

display     current-configuration：优化一些不必要的配置，或者暂时关闭某些功能，看看是否改善

display  firewall      statistics system      transmitted：查看是否有分片，因为IPSec由于包结构加大，分片的可能性更大。所以建议在部署IPSec的网络中，把MTU 1350~1400，可以减少分片的可能性。（ESP头部最少占用56个字节，隧道模式会形成新的IP头部，占用20个字节，如果GRE出现会占用4~12，PPPOE占用8个，NAT-T占用8个）

结尾

这个就是整体IPSec相关的排错，从第一阶段、第二阶段、以及通了后业务不通等方明，把常见的故障都列出来了，配合视频讲解更加理解深刻，另外实际环境由于厂商过多，很多特殊的情况都会发生，这个就只能自己经验的积累，多查询双方设备的特性跟案例库来进行解决，往往对接容易出现问题的就是在两个不同厂商之间。

以上就是IPSec故障排错之路的介绍，Vecloud提供全球网络优化服务、MPL专线、SD-WAN组网、IPLC专线等海外专线业务。