Windows Server 2003 IPSec 隧道已连接，但不工作（可能与 NAT/RRAS 相关）

Question

配置

我已经根据 Microsoft KB816514 中的说明在 Windows Server 2003 (SBS) 机器和 Netgear FVG318 之间设置了“原始”IPSec 隧道。配置如下（使用与文章相同的约定）：

NetA         | SBS2003   | FVG318   | NetB
10.0.0.0/24  | 216.x.x.x | 69.y.y.y | 10.0.254.0/24

主模式和快速模式安全关联都成功完成并出现在 IP 安全监视器中。我还可以从 NetB 上的任何计算机在其私有地址上 ping SBS2003 服务器。

问题

从 NetA 上的计算机发送到 NetB，或从 SBS2003 发送到 NetB 的任何流量（不包括 ICMP Ping响应），都在 IPSec 隧道外的公共网络接口上发送（没有加密或标头身份验证，就好像隧道不存在一样） .

从 NetB 上的计算机发送到 NetA 上的计算机的 Ping 成功到达 NetA 上的计算机，但响应被 SBS2003 静默丢弃（它们不会以明文形式发出，也不会生成任何加密流量）。

可能的解决方案

配置不正确

我可能在某处打错了某些东西，或者 KB816514 可能在某些方面不正确。我非常努力地消除了第一个选项。已经多次重新创建配置，尝试调整和调整所有我能做的设置，但没有成功（大多数情况下都阻止了 SA 的建立）。

NAT/RRAS

我在其他地方看到多篇帖子表明这可能是由于 NAT 和 IPSec 过滤器之间的交互造成的。可能 NetA 私有地址在与快速模式 IPSec 过滤器进行比较之前被重写为 216.xxx，并且不会因为不匹配而被隧道化。事实上，电缆专家 2005 年 6 月的文章“TCP/IP 数据包处理路径”表明情况就是如此（请参阅 Transit Traffic 路径的第 2 步和第 4 步）。如果是这种情况，有没有办法从 NAT 中排除 NetA->NetB 流量？

任何想法、想法、建议和/或评论表示赞赏。

更新 (2011-06-26)

在未能解决问题后，我求助于付费的 Microsoft 支持。他们无法解决问题。从那时起，我实施了一个基于 Linux 的解决方案，该解决方案运行良好。我将尝试尽可能地评估任何建议的答案，但当前的配置和时间限制会使这变得缓慢......

Answer 1

检查您的绑定订单。网络属性>高级>高级设置 将您希望路由通过的网络移至顶部。