ER3260G3的IPsec功能是完整的吗？

不是标准的IPSec,

关于你提到的ER3260G3的IPsec功能是否完整的问题，请放心，它是完整的。它支持所有标准的IPsec功能，能够胜任你这种中心-分支结构的VPN组网。

你遇到的通信故障，根源在于双方的安全联盟参数定义不一致。你的描述中A点网络（中心）配置可能过于简化，缺少了IKE协商模式、NAT穿透（NAT-T）等相关参数，导致从B点（分支）主动发起的协商无法与A点有效协商。因此，B点虽然能收到从A点发起的、已加密的通信，但自身发出的数据包却无法建立有效的安全隧道进行加密。

解决方案（由简到难进行排查）

根据你的描述，可以从最基础也最关键的“路由与策略”开始排查，逐步深入到核心的IKE协商参数。

第一步：检查核心配置，确保“路”是通的

这是最关键的一步，也是最容易出差错的地方。

• 检查安全策略ACL是否互为镜像：请在A点和B点分别检查IPsec策略中的“本地子网”和“对端子网”的配置。

  • A点（中心）：本地子网应为A点内网段，对端子网应为B点内网段。

  • B点（分支）：本地子网应为B点内网段，对端子网应为A点内网段。
    这两个ACL必须以“互为镜像”的方式配置，否则加密数据流无法匹配。

• 检查网关设置，避免“绕路”：请检查B点内网的PC，其网关是否指向ER3260G3。如果网关设置错误，可能导致数据包不经过VPN隧道，从而不通。

第二步：统一关键IKE协商参数

由于你的A点（静态公网IP）是可被B点访问的，因此协商模式必须设为野蛮模式 (Aggressive Mode)。请详细比对并统一以下参数，确保两端完全一致：

• 协商模式 (Mode)：野蛮模式

• 预共享密钥 (Pre-shared Key)：完全一致

• 加密算法 (Encryption Algorithm)：如 AES、3DES

• 认证算法 (Authentication Algorithm)：如 SHA1、MD5

• Diffie-Hellman (DH) 组：如 Group 2、Group 5、Group 14

• 安全协议 (Security Protocol)：通常是 ESP

• NAT穿透 (NAT-Traversal)：必须开启

第三步：处理路由问题，确保数据“隧”道中走

请检查两端的路由表，确保有去往对方内网的路由指向IPsec虚接口。

• A点（中心）：需有去往B点内网段的路由，下一跳为IPsec隧道接口。

• B点（分支）：需有去往A点内网段的路由，下一跳为IPsec隧道接口。

第四步：检查与验证隧道状态

1. 查看隧道状态：在路由器Web界面或CLI下，检查IKE SA和IPsec SA的状态，确认是否为ESTABLISHED或READY等正常状态。

2. 测试通信：在故障重现时，使用 ping -t 命令持续发流，然后查看隧道接口上的TRAFFIC或OCTETS计数器是否在增长，以验证数据是否确实走了隧道。

备用排查方案

如果上述排查后问题依旧，可以尝试以下操作，来进一步缩小问题范围。

1. 恢复关键节点配置：如果对A点的配置不熟悉，可先恢复出厂设置，然后只配置外网接入和中心端IPsec所需的最简参数，以确保没有历史配置产生干扰。

2. 启用NAT穿透并调整MTU：确保B点（分支）路由器已开启NAT-T功能（部分型号可能默认即开启），并检查WAN口MTU值（可尝试设置为1400或更小），以避免因数据包过大导致的分片问题。

3. 开启日志与抓包：短暂开启H3C路由器的IPsec调试日志或使用Wireshark抓包分析，检查IPsec协商过程中是否出现错误信息。

02-IPsec VPN典型配置举例

需要设置策略路由，把感兴趣流量指向IPSec隧道接口，就能正常访问了。