☰

FreeBSD 重大更新破坏了 vpnc 连接，传入的 ESP 流量在接口上未显示为未加密

tag-icon • tag-icon freebsd ipsec cisco-vpn vpn-client
FreeBSD 重大更新破坏了 vpnc 连接，传入的 ESP 流量在接口上未显示为未加密

我最近将一个FreeBSD盒子从更新10.4到11.2-RELEASE-p4，但它似乎破坏了vpncVPN 连接。

以下是vpnc.conf： 

IPSec gateway 10.1.0.1
IPSec ID vpnuser
IPSec secret su0hoh8liNgeiT8
Xauth username vpnuser
Xauth password miuthei3Niew2ee
Nat Traversal Mode none
Noninteractive

以下是接口配置；em0 是具有私有 IP 地址的硬件接口，tun0 是具有公共地址的 vpnc 接口。

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
  options=209b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC>
  inet 10.2.2.1 netmask 0xfffffe00 broadcast 10.2.3.255
  nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
  media: Ethernet autoselect (100baseTX <full-duplex>)
  status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
  options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
  inet6 ::1 prefixlen 128
  inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
  inet 127.0.0.1 netmask 0xff000000
  nd6 options=21
  groups: lo
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1412
  options=80000<LINKSTATE>
  inet x.11.11.60 --> x.11.11.60 netmask 0xffffffff
  nd6 options=29
  groups: tun
  Opened by PID 90343

到目前为止我发现：

  • vpnc 显然可以建立 VPN 连接，使用 运行 vpnc--no-detach不会显示任何严重错误。我使用与以前相同的配置，并且使用以前的FreeBSD版本，它运行完美。我也尝试了几个版本vpnc-scripts。我还使用 刷新了 pf 防火墙规则对其进行了测试pfctl -F all。

  • 从本地机器发送的 ping 命令 ( ping 8.8.8.8) 确实显示tcpdump -ni tun0为传出流量：

    00:58:24.017976 IP x.11.11.60 > 8.8.8.8: ICMP echo request, id 42593, seq 4, length 64

  • 从本地机器发送的 ping 命令显示在tcpdump -ni em0；有趣的是，VPN 数据包似乎每次都能得到正确的响应，并且响应到达本地机器的硬件接口：

    00:58:24.018029 IP 10.2.2.1 > 10.1.0.1: ESP(spi=0x1bcc60be,seq=0x3c), length 132
00:58:24.078558 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x6b), length 132

  • 然而，返回的数据包没有出现在tcpdump。

  • 从随机外部（互联网）主机到 x.11.11.60 的 ping 数据包确实会产生类似的流量，可以在上看到em0但在上看不到tun0：

    01:35:32.612015 IP 10.1.0.1 > 10.2.2.1: ESP(spi=0xe48f7620,seq=0x124), length 132

改变sysctl的值net.inet.ip.forwarding似乎没有任何效果。

VPN（tun0）应该是主机的默认路由。根据示例 ping 得到响应的发现，em0这似乎不是路由问题。

您能发现我遗漏了什么吗？您知道如何才能让 VPN 连接重新正常工作吗？

更新 - 新发现：

现在看来，这可能不是一个vpnc特定的问题。相反，可能是 ESP 处理方面的问题FreeBSD 11。

  • 我找到了一种解决方法，即强制使用 NAT 遍历模式，--natt-mode force-natt尽管主机之间没有 NAT。出于某种原因，封装的 UDP 没有问题：

em0...上有什么节目

14:15:18.500251 IP 10.2.2.1.4500 > 10.1.0.1.4500: UDP-encap: ESP(spi=0x66842bb7,seq=0x3), length 132
14:15:18.527137 IP 10.1.0.1.4500 > 10.2.2.1.4500: UDP-encap: ESP(spi=0x3a4661f0,seq=0x3), length 132

...现在也可以在以下位置看到未加密的内容tun0：

14:15:18.500200 IP x.11.11.60 > 172.217.21.142: ICMP echo request, id 64016, seq 2, length 64
14:15:18.527188 IP 172.217.21.142 > x.11.11.60: ICMP echo reply, id 64016, seq 2, length 64

  • racoon我使用以下方法建立了一个单独的解决方案FreeBSD 手册并且它在显然不处理传入的 ESP 数据包时表现出类似的行为。出于某种原因，vpnc[3372]: esp sendto: Invalid argument当我尝试 pingvpnc以 开头的程序时，现在会收到错误--natt-mode none。

  • 似乎 IPsec、ESP 和 NAT-T 发生了一些变化FreeBSD 11.0R和11.1R。也许这些变化现在会干扰某些事情。

任何帮助都将不胜感激。

相关内容