移动客户端的服务器配置有几个组件：

• 为VPN创建一个证书结构
• 配置IPsec移动客户端设置
• 为客户端连接创建阶段1和阶段2
• 添加IPsec防火墙规则
• 创建***的用户凭据
• ipsec连接测试
• ipsec故障排除
• ipsec日志说明

为VPN创建IKEv2证书结构

创建一个证书颁发机构

如果证书管理器中没有合适的证书颁发机构（CA），那么我们首先创建一个：

• 导航到系统>证书管理，CAS选项卡
• 单击
  
   添加一个证书颁发机构
• 证书来源选创建一个内部证书颁发机构
• 按照公司或特定地点的信息填写其余的字段
• 单击保存

创建一个服务器证书

注意：请严格按照步骤进行操作，如果任何一部分不正确，则某些或所有客户端可能无法连接。

• 导航到系统>证书管理,证书选项卡
• 单击
  
   添加一个新的证书
• 证书来源选创建内部证书
• 输入描述名称如：IKEv2 Server
• 选择在上一步中创建的证书颁发机构
• 输入密钥长度,摘要算法和有效期
• 选择证书类型为服务器证书
• 根据需要在专用名称字段中填写地区和公司数据，将其从CA中复制并保留原样
• 输入通用名称作为DNS中存在的防火墙的主机名称。如果客户端将通过IP地址连接，请在此处填写IP地址
• 单击
  
  添加 一个新的替代名称
• 在类型字段中选FQDN或主机名
• 在“值”字段中再次输入防火墙的主机名
• 单击
  
   添加另一个替代名称
• 在类型字段选IP地址
• 在“值”字段中输入防火墙的WAN IP地址
• 根据需要为客户端可能用于连接的防火墙上的其他主机名或IP地址添加更多替代名称
• 单击保存

配置IPsec移动客户端设置

在配置移动IPsec实例之前，首先选择一个IP地址范围用于移动客户端。 确保IP地址不与任何现有网络重叠; IP地址必须与托管移动隧道的站点以及客户端连接的LAN不同。 在这个例子中，将使用10.3.200.0/24，但它可以是任何未使用的子网。

首先，请在防火墙上启用IPsec：

• 导航到VPN > IPsec
• 选中启用IPsec
• 单击保存

移动客户端支持也必须启用:

• 导航到VPN >IPsec
• 点击移动客户端标签
• 选中启用IPsec移动客户端支持

启用IPsec移动客户端支持

• 将用户认证设置为“本地数据库”，如下图所示所示。在用户管理（用户管理和认证）中定义的RADIUS服务器可以在这里选择用于在使用EAP-RADIUS时对用户进行认证。

移动客户端认证

某些设置可能会推送到客户端，例如客户端IP地址和DNS服务器。 这些选项显示在“移动客户端推送的设置”中。 不同客户端对这些选项的支持各不相同，但在大多数当前操作系统中得到很好的支持

虚拟地址池:

定义将分配给客户端的IP地址池。 这个例子使用10.3.200.0/24。

虚拟IPv6地址池:

跟上面相同，只不过是IPv6地址。

网络列表:

控制客户端是否尝试通过隧道发送所有流量，或者仅针对特定网络的流量。 如果选中此选项，则移动阶段2定义的本地网络选项中定义的网络将被发送到客户端。 如果未选中此选项，则客户端将尝试通过隧道发送其所有流量，包括Internet流量。 并非所有客户都尊重这一选择。 对于这个例子，客户端只能在阶段2到达网络，所以选中这个选项。

保存Xauth密码:

选中后，支持此控件的客户端将允许用户在使用Xauth时保存其凭据。 这主要是由基于思科的客户端（如iOS和Mac OS X上的客户端）所推崇的。由于本示例使用了IKEv2，因此并不重要。

DNS默认域:选中后，输入到框中的值将作为DNS请求的默认域后缀推送给客户端。 例如，如果将此设置为example.com，并且客户端请求主机，则会尝试执行host.example.com的DNS请求。

拆分DNS:

控制客户端如何将DNS请求发送到提供的DNS服务器（如果有）。 如果未选中此选项，则客户端将把所有DNS请求发送到提供的DNS服务器。 如果该选项被选中，但保留为空，并且设置了DNS默认域，则只有该域名的请求才会转到提供的DNS服务器。 如果选中并输入一个值，那么只有输入框中的域名请求才会被转发到提供的DNS服务器。 在这个例子中，example.com和example.org都被使用，并且这两个域的DNS请求将会到达VPN服务器，所以在这里输入这些值，并用空格隔开。

DNS服务器:

当选中向客户端提供DNS服务器列表时，为本地DNS服务器（如10.3.0.1）输入IP地址，这些值将在VPN连接时发送给客户端使用。

注意：如果移动客户端将通过VPN路由到Internet，请确保客户端使用此选项从防火墙获取DNS服务器，并且没有启用拆分DNS。 如果没有这样做，客户端将尝试从ISP分配的任何服务器获取DNS，但是通过隧道路由该请求很可能会失败。

WINS服务器：

与DNS服务器类似，但用于WINS。现在已很少使用，最好还是禁用。

Phase 2 PFS组：

覆盖所有移动Phase 2条目的PFS设置。 通常最好在P2条目上单独设置此值，因此请不要选中。

登陆横幅：

可选，只适用于Xauth客户端。 保持未选中并空白

设置完成后如下：

移动客户端推送设置

创建阶段1和阶段2

• 单击“保存”，pfSense将显示警告，指出移动客户端没有定义Phase 1。
• 点击创建Phase 1，为移动客户端创建一个新的Phase1条目。

单击隧道选项卡，配置选项如下:

    密钥交换版本:IKEv2

    Internet协议:IPv4

    接口:WAN

    描述说明: Mobile IPsec

    认证方法:EAP-MSCHAPv2

    我的标识符:从下拉列表中选择“可分辨名称”，然后输入防火墙的主机名，与服务器证书的主机名相同， VPN.example.com

    对端标识符:Any

    我的证书:选择之前创建的IPsec服务器证书

    加密算法:设置为3DES (如果没有iOS / OS X设备，则为AES 256)

    哈希算法:必须设置为 SHA1 (如果没有iOS / OS X设备，则为SHA256)

    DH组:必须设置为2 (1024 bit)

    有效期:必须为 28800

    禁用预授密码:不选中

    禁用重新认证:不选中

    仅响应:不选中

    MOBIKE:设置为启用以允许客户端在IP地址之间漫游，否则设置为禁用。

移动客户端阶段 1

• 单击保存
• 单击
  
   显示阶段 2条目，展开阶段2列表
• 单击
  
   添加新的phase 2条目

• 配置选顶如下：

    模式:选IPv4隧道

    本地网络:设置为LAN子网或其他本地网络。 要通过VPN隧道传输所有流量，请选择网络，并输入掩码为0的0.0.0.0

    NAT/BINAT:设置为None

    协议:设置为ESP, 这将加密隧道流量

    加密算法:必须设置为AES，自动选择密钥长度。 如果有iOS或OS X客户端连接，也选中3DES。

    哈希算法:选SHA1和 SHA256

    PFS密钥组:设为关闭

   有效期: 3600

移动客户端阶段 2

• 单击保存
• 单击应用更改

创建IPsec移动用户

下一步是添加用户以供EAP-MSCHAPv2使用。

• 导航到VPN > IPsec,预共享密钥选项卡
• 单击
  
   添加新密钥

• 配置选项如下:

    标识符：客户端的用户名可以用多种方式表示，例如电子邮件地址 [email protected]

    加密类型：设置为EAP

    预共享密钥：客户端的密码, 如 abc123

• 单击保存

• 为其他的VPN用户重复上述操作。

移动IPsec用户

添加IPsec防火墙规则

与静态站点到站点隧道一样，移动隧道也需要在防火墙>规则策略下的IPsec选项卡中添加防火墙规则。 在这种情况下，流量的来源将是为移动客户端选择的子网，目的地是LAN网络，或者为任意。

创建VPN的用户凭据

Windows IKEv2 客户端配置

Windows 8以上的版本可以轻松支持IKEv2 VPN，而Windows 7也可以，虽然过程略有不同。 本示例过程在Windows 10上执行，与Windows 8几乎完全相同。

导入CA证书到客户端PC上

• 从pfSense导出CA证书并下载或复制到客户端PC:
  • 导航到系统>证书管理,CAS选项卡
  • 在证书列表右侧单击
    
     导出CA证书
• 在客户端计算机上找到下载的文件（例如VPNCA.crt）
• 双击这个 CA 文件
• 单击安装证书

证书属性

• 选择本地计算机

证书导入向导 – 存储位置

• 单击下一步
• 如果出现UAC提示，请单击是
• 选择将所有证书都放入下列存储，如下图所示

证书导入向导 – 浏览存储

• 单击浏览
• 单击“受信任的根证书颁发机构”

选择证书存储

• 单击确定
• 单击完成。

完成证书导入向导

设置 VPN连接

一旦证书正确导入，就可以创建客户端VPN连接了。 确切的步骤将取决于客户端使用的Windows版本，以下是在Win10的设置方法。

• 在客户端PC上打开网络和共享中心
• 点击设置一个新的连接或网络
• 选择连接到工作区
• 单击下一步
• 选择否，创建一个新的连接
• 单击下一步
• 单击使用我的Internet连接（VPN）
• 在Internet地址中输入服务器的IP地址或主机名

注意

这必须与服务器证书通用名称或配置的备用名称中的内容匹配！

Windows IKEv2 VPN连接设置

• 输入目标名称
• 单击创建

连接已经添加，但有几个默认值需要进行修改。 请参阅图下图进行设置：

• 在Windows的网络连接/适配器设置中，找到上面创建的连接
• 右键单击连接
• 单击属性
• 单击安全选项卡
• 设置VPN类型为：KEv2
• 设置数据加密选项为 ：需要加密（如果服务器拒绝将断开连接）
• 设置身份验证为使用可扩展身份验证协议(EAP)(E): Microsoft:安全密码 (EAP-MSCHAP v2) (启用加密)
• 单击确定

Windows IKEv2 VPN连接属性

现在VPN连接已经可以使用了。

禁用EKU检查

在pfSense 2.2.4及更高版本上正确设置了CA和服务器证书后，禁用EKU检查已经不是必需的了。 如果出于某种原因必须使用不正确的服务器证书，则可能需要在Windows上禁用扩展密钥使用检查。 禁用此检查还会禁用证书的公用名称和SAN字段的验证，因此可能会有危险。 禁用此服务器时，可以使用来自同一CA的任何证书，因此请谨慎操作。

要禁用扩展密钥用法检查，请打开Windows客户端上的注册表编辑器，并导航到客户端注册表中的以下位置：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\RasMan\Parameters\

添加一个名为DisableIKENameEkuCheck的新DWORD条目，并将其值设置为“1”。

可能需要重新启动才能激活设置。

iOS 11 IKEv2客户端配置

从IOS9开始，iOS内置了对IKEv2的支持，可以从GUI配置而不需要vpn配置文件。 和其他客户一样，必须安装CA证书。

导入CA到OS设备

将CA证书导入到客户端设备是一个相对容易的过程。 第一步是将CA证书拿到客户端设备上。 最简单的方法是通过电子邮件，如图用iOS邮件客户端接收CA证书

iOS邮件客户端接收CA证书

• 从电子邮件安装证书：
• 仅将CA证书（不是密钥）发送到可从客户端设备访问的电子邮件地址
• 打开客户端设备上的邮件应用程序
• 打开包含CA证书的邮件
• 点击附件安装CA证书

• 点击右上方的“安装”，将出现一个警告屏幕，如下图所示：

• 点击右上方的安装再次确认，然后显示一个最终提示，如下图所示：

• 在确认提示处点击安装，现在将CA证书存储为受信任的条目。

设置VPN连接

一旦安装了CA证书，就必须配置一个VPN条目：

• 进入手机的设置>通用>VPN
• 添加VPN配置
• 设置类型为IKEv2 (default)
• 输入一个描述(例如 ExampleCo VPN)
• 在服务器中输入防火墙主机名或IP地址
• 在Remote ID中再次输入防火墙的主机名

注意:这必须匹配服务器证书的通用名称和SAN条目。

• 本地ID留空
• 将用户鉴定设置为用户名
• 输入用户名或密码

注意:使用EAP-MSCHAPv2，用户名是在“VPN”>“IPsec”下的“预共享密钥”选项卡上为用户条目配置的标识符。 使用EAP-RADIUS，这将是在RADIUS服务器上设置的用户名。

• 点击完成

iOS IKEv2客户端设置

连接和断开

通过访问设置下的VPN条目可以连接或断开VPN。 这两个地方稍有不同：

1. 设置 VPN
2. 设置 >通用 > VPN

一旦存在至少一个VPN连接，直接会在设置里面出现VPN条目。

一旦在VPN列表中，必须选择VPN条目（在其条目旁边显示复选标记），然后滑块可以移动到“开”位置以连接。

IOS VPN列表

测试IPsec连接

对于IPsec隧道来说，最简单的测试就是从防火墙后面的一个客户端ping到另一个客户端。 如果能ping通，隧道就可以正常工作了。

正如pfSense启动的流量和IPsec中所提到的，从pfSense防火墙启动的流量通常不会在没有额外路由的情况下穿越隧道，但是通过PING指定发出的源，可以快速测试防火墙本身的连接。

有两种方法可以执行这个测试：GUI和shell。

在GUI中使用Ping工具

在GUI中，按以下步骤操作

• 导航到系统诊断> Ping
• 在主机字段中输入一个远程路由器远程隧道子网的IP（例如10.5.0.1）
• 协议选 IPv4
• 源地址：在本地防火墙上选择一个接口或IP地址（例如，选择LAN作为LAN IP地址）
• 最大ping数，选默认3
• 单击Ping

如果隧道正常工作，则防火墙将从站点B的局域网地址接收ping回复。

如果最初没有建立隧道，那么在隧道协商过程中丢失几个ping是很常见的，所以如果第一次尝试失败，选择更多的次数或重新运行测试是一个好的做法。

在Shell中使用Ping命令

使用控制台上的shell或通过ssh，可以手动运行ping命令，并可以使用-S参数指定源地址。 如果不使用-s或静态路由，ping生成的数据包将不会尝试穿越隧道。 下面是一个简单的测试语法：

#  ping -S <Local LAN IP> <Remote LAN IP>

本地LAN IP是隧道的本地子网定义的内部接口上的IP地址，而远程LAN IP是远程路由器上列出的远程子网内的IP地址。 在大多数情况下，这只是各个pfSense防火墙的LAN IP地址。 根据上面的站点到站点示例，这是从Site A防火墙的控制台输入的内容：

#  ping -S 10.3.0.1 10.5.0.1

如果隧道正常工作，则防火墙将从站点B的局域网地址接收ping回复。

IPsec故障排除

由于IPsec的挑剔性质，出现问题并不罕见。 幸运的是，有一些基本的故障排除步骤可以用来追踪潜在的问题。

IPsec日志

本章中介绍的例子有为了简洁起见而编辑的日志，但仍有重要的信息。

IPsec日志可以被配置为提供更多有用的信息。 在pfSense中要配置IPsec日志记录来诊断隧道问题，请参照以下步骤：

• 导航到VPN > IPsec高级设置选项卡
• 将IKE SA、IKE Child SA、Configuration Backend 设置为诊断
• 将所有其他日志设置设置为控制
• 单击保存

注意：更改日志记录选项不会中断IPsec活动，也不需要为当前版本的pfSense上的IPsec输入特定的“调试模式”。

隧道不能建立

首先检查系统状态>系统服务的状态。 如果IPsec服务已停止，请在VPN> IPsec检查它是否已启用。 另外，如果使用移动客户端，请确保在移动客户端上的启用框也被选中。

如果服务正在运行，请检查防火墙日志（系统状态>系统日志，防火墙选项卡）以查看连接是否被阻止，如果是，请添加规则以允许阻止的流量。 通常为IPsec自动添加规则，但可以禁用该功能。

IPsec隧道连接失败的最常见原因是配置不匹配。 通常情况下，它是很小的，例如DH组在A侧设置为1，在B侧设置为2，或者在一侧为/ 24或者在另一侧为/ 32的子网掩码。 一些路由器（Linksys）也喜欢隐藏“高级”按钮背后的某些选项。 大量的反复试验可能会涉及到大量的日志阅读，但是确保双方精确匹配最有帮助。

根据隧道两端的互联网连接情况，一方或另一方涉及的路由器也可能无法正确处理IPsec通信。 这是移动客户端和NAT在实际IPsec端点之外涉及的网络引起的更大的关注。 一般来说，ESP协议存在一直被阻塞或处理不当的问题。 NAT穿越（NAT-T）将ESP封装在UDP端口4500流量中，可以解决这些问题。

隧道已建立，但没有流量传递

如果隧道已建立，但没有流量通过，首先应检查IPsec防火墙规则。如果站点A无法到达站点B，请检查站点B的防火墙日志和规则。相反，如果站点B不能联系站点A，请检查站点A的防火墙日志和规则。在查看规则之前，请在“防火墙”选项卡上的系统状态>系统日志中检查防火墙日志。如果存在阻止的条目涉及IPsec隧道中使用的子网，则继续检查规则。

IPsec或enc0接口上的阻塞数据包表明隧道本身已建立，但流量正在被防火墙规则阻止。在局域网或其他内部接口上阻塞的数据包可能表示在该接口规则集上可能需要附加的规则，以允许来自内部子网的流量到达IPsec隧道的远端。 WAN或OPT WAN接口上的阻塞数据包将阻止建立隧道。通常只有当自动VPN规则被禁用时才会发生这种情况。添加一个规则允许来自该远程IP地址的ESP协议和UDP端口500将允许建立隧道。在移动隧道的情况下，允许任何来源的流量连接到这些端口。

IPsec接口的规则可以在IPsec选项卡上的防火墙>规则策略下找到。常见的错误包括设置规则只允许TCP通信，这意味着像ICMP ping和DNS这样的协议不能通过隧道工作。

在某些情况下，设置不匹配也可能导致流量无法通过隧道。在一个例子中，在一个非pfSense防火墙上定义的子网是192.0.2.1/24，而在pfSense防火墙上是192.0.2.0/24。建立了隧道，但是直到子网被纠正，流量才能通过。

路由问题是另一种可能性。使用跟踪路由（Windows上的tracert）检查隧道另一侧的IP地址可以帮助追踪这些类型的问题。重复隧道两侧的测试。当使用跟踪路由（traceroute）时，进入和离开IPsec隧道的流量似乎缺少一些中间跳跃。这是正常的，也是IPsec工作的一部分。没有正确进入IPsec隧道的流量将显示为离开WAN接口并通过Internet向外路由，这将指向路由问题，如pfSense不是网关（如在路由和网关注意事项中）、错误地指定在隧道定义上的远程子网、或已禁用隧道等 。

一些主机工作，但不是全部

如果通过VPN的某些主机之间的流量功能正常，但另外一些主机不通过，则通常是以下四种情况之一：

1.缺少、不正确或被忽略的默认网关:如果设备没有默认网关，或者有一个指向pfSense防火墙之外的其他设备，则不知道如何正确返回VPN上的远程网络。有些设备，即使使用指定的默认网关，也不使用该网关。这已经出现在各种嵌入式设备上，包括IP摄像机和一些打印机。除了修复设备上的软件之外，没有什么可以做。这可以通过在连接到包含该设备的网络的防火墙的内部接口上运行数据包捕获来验证。使用tcpdump进行故障排除，并且可以在IPsec隧道中找到一个IPsec特定的示例。如果观察到流量离开防火墙的内部接口，但没有应答返回，则设备没有正确路由其回复流量，或者可能通过本地客户端防火墙阻止。

2.子网掩码不正确:如果一端使用的子网为10.0.0.0/24，另一端为10.254.0.0/24，并且主机的子网掩码为255.0.0.0或/ 8，则永远不能通过VPN进行通信 因为它认为远程VPN子网是本地网络的一部分，因此路由将无法正常工作。 配置中断的系统将尝试通过ARP而不是使用网关联系远程系统。

3.主机防火墙:如果目标主机上有防火墙，则可能不允许连接。 检查Windows防火墙，iptables或类似的实用程序，可能会阻止主机处理流量。

4.pfSense上的防火墙规则:确保两端的规则允许所需的网络流量。

连接挂起

IPsec不能正常处理分片数据包。 这些问题中的许多问题多年来已经得到解决，但可能会有一些滞后的问题。 如果仅在使用特定协议（SMB，RDP等）时才会看到挂起或丢包，则可能需要VPN设置MSS。 可以在“VPN> IPsec”的“高级设置”选项卡上激活MSS限制。 在该页面上，选中启用VPN通信上的MSS限制，然后输入一个值。 一开始可以输入1400，慢慢地增加MSS值，直到正常连接，然后再降低一点。

嵌入式路由器上的“随机”隧道断开/ DPD故障

在其他嵌入式硬件上，如果IPsec隧道被丢弃，则可能需要禁用隧道上的DPD。 这种故障倾向与高带宽使用时间相关联。 当低功耗系统上的CPU发送IPsec通信或占用其他资源时，会发生这种情况。 由于CPU过载，可能无法花时间来响应DPD请求或者看到自己的请求的响应。 因此，隧道将无法通过DPD检查并断开连接。 这表明硬件正在超越极限。 如果发生这种情况，请考虑使用更强大的硬件。

隧道已建立和工作，但不能重新协商

在某些情况下，隧道正常运行，但是一旦阶段1或阶段2的使用期限届满，隧道将无法正确重新协商。 这可以用几种不同的方式表现出来，每种方式都有不同的分辨方法。

DPD不受支持，一方丢弃，另一方丢弃

从站点A到站点B，从站点A发起的流量建立隧道。

站点B在站点A之前到期的阶段1或阶段2。

站点A将相信隧道已经启动并继续发送流量，就像隧道正常工作一样。

只有在站点A的阶段1或阶段2的使用期限到期时，它才会按预期进行重新协商。

在这种情况下，两种可能的解决方法是：启用DPD，或者站点B必须将流量发送到站点A，这将导致整个隧道重新协商。 实现这一点的最简单方法是在隧道的两侧启用保活机制。

隧道在启动时建立，而不是在响应时建立

如果隧道有时会建立，但并不总是，一般来说，某一方面是不匹配的。 隧道仍然可以建立，因为如果一方提出的设置更安全，另一方可以接受，但不能反过来。 例如，如果在一个IKEv1隧道和设置为Main模式的站点与设置了Aggressive / Main模式的站点通信，虽然不匹配，隧道仍将建立。 但是，如果设置为Aggressive的端口尝试启动隧道，则将会失败。

有效期不匹配不会导致阶段1或阶段2失败。

要跟踪这些故障，请按照“IPsec日志记录”中的说明配置日志，然后尝试从各端发起连接隧道，然后检查日志。

IPsec日志说明

IPsec选项卡上的“系统状态”>“系统日志”中提供的IPsec日志包含隧道连接过程的记录以及来自正在进行的隧道维护活动的一些消息。 本节列出了一些典型的日志条目，包括好的和坏的。 要查找的主要内容是指示连接的哪一部分起作用的关键短语。 如果日志中存在“IKE_SA … established”，则意味着阶段1已成功完成，并且协商了安全协会。 如果“CHILD_SA …已经建立”，那么第二阶段也已经完成，隧道已经建成。

在以下示例中，日志已在IPsec日志记录中配置为侦听，而不相关的消息可能会被忽略。 请记住这些是样本，具体的ID号码，IP地址等等会有所不同。

成功的连接

当隧道成功建立后，双方都会建立一个IKE SA和一个子SA。 当多个阶段2定义与IKEv1一起出现时，针对每个阶段2条目协商子SA。

发起者的日志显示:

charon: 09[IKE] IKE_SA con2000[11] established between 192.0.2.90[192.0.2.90]...192.0.2.74[192.0.2.74]charon: 09[IKE] CHILD_SA con2000{2} established with SPIs cf4973bf_i c1cbfdf2_o and TS 192.168.48.0/24|/0 === 10.42.42.0/24|/0

响应者的日志显示:

charon: 03[IKE] IKE_SA con1000[19] established between 192.0.2.74[192.0.2.74]...192.0.2.90[192.0.2.90]charon: 16[IKE] CHILD_SA con1000{1} established with SPIs c1cbfdf2_i cf4973bf_o and TS 10.42.42.0/24|/0 === 192.168.48.0/24|/0

失败的连接示例

这些示例显示由于各种原因而失败的连接 在大多数情况下，从示例中可以清楚地看到，启动器没有收到有关特定项目不匹配的消息，因此响应者日志更有参考性。 这样做是为了保护隧道的安全，向潜在的***者提供消息是不安全的，这将给他们提供关于隧道配置的信息。

阶段1的Aggressive / Main不匹配

在此示例中，启动程序设置为Aggressive模式，而响应者设置为Main模式。

发起者的日志显示:

charon: 15[IKE] initiating Aggressive Mode IKE_SA con2000[1] to 203.0.113.5charon: 15[IKE] received AUTHENTICATION_FAILED error notifycharon: 13[ENC] parsed INFORMATIONAL_V1 request 1215317906 [ N(AUTH_FAILED) ]charon: 13[IKE] received AUTHENTICATION_FAILED error notify

响应者的日志显示:

charon: 13[IKE] Aggressive Mode PSK disabled for security reasonscharon: 13[ENC] generating INFORMATIONAL_V1 request 2940146627 [ N(AUTH_FAILED) ]

请注意，响应者状态中的日志清楚地表明， Aggressive 模式已被禁用，这是模式不匹配的一个很好的线索。

在相反的情况下，如果为Main模式设置的端点启动，则由于Main模式更安全，因此到pfSense防火墙的隧道将建立。

阶段1标识符不匹配

当标识符不匹配时，发起者只显示认证失败，但没有理由。 响应者指出无法找到对等点，表明找不到匹配的阶段1，这意味着不能找到匹配的标识符。

发起者的日志显示:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]charon: 10[IKE] received AUTHENTICATION_FAILED error notify

响应者的日志显示:

charon: 12[CFG] looking for pre-shared key peer configs matching 203.0.113.5...198.51.100.3[someid]charon: 12[IKE] no peer config foundcharon: 12[ENC] generating INFORMATIONAL_V1 request 4216246776 [ HASH N(AUTH_FAILED) ]

阶段1预共享密钥不匹配

不匹配的预共享密钥可能难以诊断。 说明这个值不匹配的错误不会显示在日志中，而是显示以下消息：

发起者的日志显示:

charon: 09[ENC] invalid HASH_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

响应者的日志显示:

charon: 09[ENC] invalid ID_V1 payload length, decryption failed?
charon: 09[ENC] could not decrypt payloads
charon: 09[IKE] message parsing failed

当上述日志消息存在时，请检查双方的预共享密钥值以确保它们匹配。

阶段1加密算法不匹配

发起者的日志显示:

charon: 14[ENC] parsed INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 14[CFG] received proposals: IKE:AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 3851683074 [ N(NO_PROP) ]

在这种情况下，日志条目确切地说明了问题：启动器设置为AES 128加密，响应者设置为AES 256。将两个设置为匹配的值，然后再试一次。

阶段1哈希算法不匹配

发起者的日志显示:

charon: 10[ENC] parsed INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/MODP_1024charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 2774552374 [ N(NO_PROP) ]

哈希算法由记录提供的HMAC部分显示。 从上面可以看出，接收和配置的propsals没有匹配的HMAC条目。

阶段1 DH组不匹配

发起者的日志显示:

charon: 11[ENC] parsed INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]charon: 11[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 14[CFG] received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192charon: 14[CFG] configured proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024charon: 14[IKE] no proposal foundcharon: 14[ENC] generating INFORMATIONAL_V1 request 316473468 [ N(NO_PROP) ]

DH组由示例的“MODP”部分表示。 如日志消息所示，发起人被设置为8192（组18），响应者被设置为1024（组2）。 通过将隧道两端的DH组设置为匹配值，可以纠正该错误。

阶段2网络不匹配

在以下示例中，启动端的阶段2条目设置为10.3.0.0/24到10.5.0.0/24。 响应者没有设置为匹配，因为它列出了10.5.1.0/24。

发起者的日志显示:

charon: 08[CFG] proposing traffic selectors for us:charon: 08[CFG] 10.3.0.0/24|/0charon: 08[CFG] proposing traffic selectors for other:charon: 08[CFG] 10.5.0.0/24|/0charon: 08[ENC] generating QUICK_MODE request 316948142 [ HASH SA No ID ID ]charon: 08[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (236 bytes)charon: 08[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 08[ENC] parsed INFORMATIONAL_V1 request 460353720 [ HASH N(INVAL_ID) ]charon: 08[IKE] received INVALID_ID_INFORMATION error notify

响应者的日志显示:

charon: 08[ENC] parsed QUICK_MODE request 2732380262 [ HASH SA No ID ID ]charon: 08[CFG] looking for a child config for 10.5.0.0/24|/0 === 10.3.0.0/24|/0charon: 08[CFG] proposing traffic selectors for us:charon: 08[CFG] 10.5.1.0/24|/0charon: 08[CFG] proposing traffic selectors for other:charon: 08[CFG] 10.3.0.0/24|/0charon: 08[IKE] no matching CHILD_SA config foundcharon: 08[IKE] queueing INFORMATIONAL taskcharon: 08[IKE] activating new taskscharon: 08[IKE] activating INFORMATIONAL taskcharon: 08[ENC] generating INFORMATIONAL_V1 request 1136605099 [ HASH N(INVAL_ID) ]

在响应者日志中，它列出了它收到的网络（日志中的“child config”行）以及它在本地配置了什么（在日志中提出了“proposing traffic selectors for us….”行）。 通过比较两者，可以发现不匹配。 当发生这种不匹配时，日志中的“no matching CHILD_SA config foundcharon”行将始终存在，并且直接表示无法找到阶段2定义以匹配从启动端收到的内容。

阶段2加密算法不匹配

发起者的日志显示:

charon: 14[CFG] configured proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 14[ENC] generating QUICK_MODE request 759760112 [ HASH SA No ID ID ]charon: 14[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (188 bytes)charon: 14[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 14[ENC] parsed INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]charon: 14[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 13[CFG] selecting proposal:charon: 13[CFG] no acceptable ENCRYPTION_ALGORITHM foundcharon: 13[CFG] received proposals: ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQcharon: 13[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 13[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 13[IKE] queueing INFORMATIONAL taskcharon: 13[IKE] activating new taskscharon: 13[IKE] activating INFORMATIONAL taskcharon: 13[ENC] generating INFORMATIONAL_V1 request 1275272345 [ HASH N(NO_PROP) ]

在这种情况下，发起者收到响应者找不到合适提议的消息（“收到NO_PROPOSAL_CHOSEN”），并且从响应者日志中可以看出，这是由于网站被设置为不同的加密类型，一端为AES 128 ，而另一端是AES 256。

阶段 2 哈希算法不匹配

发起者的日志显示:

charon: 10[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 10[ENC] generating QUICK_MODE request 2648029707 [ HASH SA No ID ID ]charon: 10[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (188 bytes)charon: 10[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 10[ENC] parsed INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]charon: 10[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 11[CFG] selecting proposal:charon: 11[CFG] no acceptable INTEGRITY_ALGORITHM foundcharon: 11[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA2_512_256/NO_EXT_SEQcharon: 11[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 11[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 11[IKE] queueing INFORMATIONAL taskcharon: 11[IKE] activating new taskscharon: 11[IKE] activating INFORMATIONAL taskcharon: 11[ENC] generating INFORMATIONAL_V1 request 757918402 [ HASH N(NO_PROP) ]

与阶段1哈希算法不匹配类似，日志条目中的HMAC值不对齐。 然而，当阶段2中发生这种情况时，响应者还会记录更清晰的消息“找不到可接受的INTEGRITY_ALGORITHM”。

阶段2 PFS不匹配

发起者的日志显示:

charon: 06[ENC] generating QUICK_MODE request 909980434 [ HASH SA No KE ID ID ]charon: 06[NET] sending packet: from 198.51.100.3[500] to 203.0.113.5[500] (444 bytes)charon: 06[NET] received packet: from 203.0.113.5[500] to 198.51.100.3[500] (76 bytes)charon: 06[ENC] parsed INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]charon: 06[IKE] received NO_PROPOSAL_CHOSEN error notify

响应者的日志显示:

charon: 08[CFG] selecting proposal:charon: 08[CFG] no acceptable DIFFIE_HELLMAN_GROUP foundcharon: 08[CFG] received proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_2048/NO_EXT_SEQcharon: 08[CFG] configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/NO_EXT_SEQcharon: 08[IKE] no matching proposal found, sending NO_PROPOSAL_CHOSENcharon: 08[ENC] generating INFORMATIONAL_V1 request 3861985833 [ HASH N(NO_PROP) ]

PFS像第一阶段的DH组一样工作，但是是可选的。 当选择的PFS选项不匹配时，会记录一条明确的消息，指出这一事实：“找不到可接受的DIFFIE_HELLMAN_GROUP”。PFS（Perfect Forward Secrecy完美的前向保密）是一种安全通信协议，可防止一次加密会话的破坏导致多次加密会话的破坏。通过PFS，服务器为每个与客户端建立的安全会话生成唯一的私钥。如果服务器私钥遭到破坏，则只有与该密钥建立的单个会话易受攻击 -攻击者无法从过去和将来的会话中检索数据，因为服务器使用唯一生成的密钥来建立每个连接。

注意：在某些情况下，如果一方的PFS设置为关闭，而另一方设置了值，隧道仍然可以建立和工作。 上面显示的不匹配只有在值不匹配的情况下才能看到，例如1对5。

与NAT不匹配的标识符

在这种情况下，pfSense被配置为对等IP地址的对等标识符，但是远程设备实际上在NAT之后。 在这种情况下，strongSwan期望实际的私有NAT-IP地址作为标识符。 在旧版本上使用的racoon守护进程要轻松得多，可以匹配任何一个地址，但strongSwan更为正式，需要正确匹配。

响应者的日志显示:

   charon: 10[IKE] remote host is behind NAT
   charon: 10[IKE] IDir '192.0.2.10' does not match to '203.0.113.245'[...]
   charon: 10[CFG] looking for pre-shared key peer configs matching 198.51.100.50...203.0.113.245[192.0.2.10]

要纠正这种情况，请将对等标识符设置更改为IP地址，然后输入NAT之前的IP地址，在本例中为192.0.2.10。

消失的流量

如果IPsec通信到达但从未出现在IPsec接口（enc0）上，请检查是否有冲突的路由/接口IP地址。 例如，如果一个IPsec隧道配置了一个192.0.2.0/24的远程网络，并且有一个本地OpenVPN服务器和一个192.0.2.0/24的隧道网络，那么ESP流量可能到达，strongSwan可能会处理这些数据包，但是 他们从来没有出现在到达操作系统交付的enc0as。

解决重复的接口/路由，流量将开始传递。

IPsec状态页面问题

如果IPsec状态页面出现错误，如：

Warning: Illegal string offset 'type' in /etc/inc/xmlreader.inc on line 116

这表示不完整的xmlreader XML解析器处于活动状态，这是由文件/ cf / conf / use_xmlreader的存在触发的。 这个替代解析器可以更快地读取大型config.xml文件，但是缺少其他区域运行良好所必需的某些功能。 删除/ cf / conf / use_xmlreader会立即将系统返回到默认解析器，这将纠正IPsec状态页面的显示。

IPsec术语

在深入研究配置之前，在本章中有几个术语需要解释。 其他术语在配置选项中用于更详细地解释。

IKE

IKE代表互联网密钥交换，分为两种：IKEv1和IKEv2。 几乎所有支持IPsec的设备都使用IKEv1。 越来越多的设备也支持较新的IKEv2协议，这是IKE的更新版本，它解决了早期版本中存在的一些问题。 例如，IKEv2具有MOBIKE，这是移动客户端的标准，允许他们动态地切换地址。 它也具有内置的NAT穿越功能，以及类似于DPD的可靠性标准机制。 一般而言，IKEv2提供了更稳定和可靠的体验，但两端必须同时支持。

ISAKMP安全联盟

ISAKMP代表互联网安全联盟和密钥管理协议。 它为双方提供了一个机制，可以建立一个安全的通信渠道，包括交换密钥和提供认证。

ISAKMP安全联盟（ISAKMP SA）是一种单向策略，定义了如何加密和处理流量。 每个活动的IPsec隧道将有两个安全关联，每个方向一个。 ISAKMP安全关联设置在每个端点的公共IP地址之间。 这些活动安全关联的数据保存在安全关联数据库（SAD）中。

安全策略

安全策略是管理IPsec隧道的完整规范。 与安全协会一样，这些是单向的，所以每个隧道在每个方向都会有一个。 这些条目保存在安全策略数据库（SPD）中。 一旦添加了隧道，每个隧道连接就为SPD填充两个条目。 相比之下，SAD条目仅在成功协商连接时才存在。

在pfSense软件中，安全策略控制内核将拦截那些通过IPsec传递的流量。

阶段 1

IPsec隧道有两个阶段的协商。 在阶段1中，隧道的两个端点之间建立一个使用ISAKMP协商SA条目和交换密钥的安全通道。 这还包括身份验证，检查标识符以及检查预共享密钥（PSK）或证书。 第一阶段完成后，两端可以安全地交换信息，但尚未决定通过隧道或其加密的流量。

阶段 2

在阶段2中，两个端点根据安全策略协商如何加密和发送专用主机的数据。 这部分构建了用于在端点处理流量的端点和客户端之间传输数据的隧道。 如果双方的策略相同并且第二阶段成功建立，则隧道将被启动并准备好用于与第二阶段定义匹配的流量。