Windows 防火墙在重新启动后会阻止几乎所有流量?

Tim*_*ham 5 windows-server-2008-r2 windows-firewall

有时,当系统启动时,它们根本不接受任何入站流量,并且我的 IPSec 规则无法出站 - 看起来服务器陷入了某种初始启动后配置。这主要适用于 2008 r2 和 Windows 7。

我前一段时间读到,Windows 高级防火墙中有某种默认配置,它会阻止所有入站流量,只允许特定的出站流量 - 到域控制器、DNS、DHCP(如果我没记错的话) - 但会阻止所有其他访问,直到加载并应用“真实”规则。听起来这就是我的系统在重新启动后陷入困境的状态。

这个状态的名称是什么?我该如何诊断我的问题?我很久以前就忘记了这些细节,现在要再次找到它们却很费劲。

编辑:

我终于找到了这种行为的正确名称,Windows防火墙启动时间过滤器

编辑:

这变得陌生了。看起来我现在可以从未启用 IPSEC 的系统建立入站连接,但任何 IPSEC 请求都会失败。我启用了一些auditpol日志记录,并且得到以下信息。

Additional Information:
Keying Module Name: IKEv1
Authentication Method:  Unknown authentication
Role:           Responder
Impersonation State:    Not enabled
Main Mode Filter ID:    0

Failure Information:
Failure Point:      Local computer
Failure Reason:     No policy configured <<< Looks wrong. 

State:          No state
Initiator Cookie:   cec5de8d625d2196
Responder Cookie:   0d40a3b58c477709
Run Code Online (Sandbox Code Playgroud)

我能够通过定义本地 IPSEC 策略暂时解决这个问题 - 甚至防火墙规则也有效 - 但我不确定为什么会出现这种情况,也不知道我可以采取什么措施来长期解决它。

Tim*_*ham 0

下面概述的注册表更改使迄今为止已应用的大约六台服务器能够顺利启动。虽然我还不能 100% 确定这是一个解决方案 - 如果服务器能够干净地启动,则大约是 50/50,它似乎确实提供了巨大的帮助。六台服务器均已重新启动 3 次以上,均运行正常。

Name: ChainUrlRetrievalTimeoutMilliseconds
Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type: REG_DWORD
Decreasing the amount of time to allow CRL retrieval can significantly improve performance when internet access is poor or non-existent. Setting the value to 200 (milliseconds) may be a reasonable timeout.


Name: ChainRevAccumulativeUrlRetrievalTimeoutMilliseconds
Location: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CertDllCreateCertificateChainEngine\Config
Type: REG_DWORD
Decreasing the amount of time to allow all CRL retrievals can significantly improve performance when internet access is poor or non-existent. Setting the value to 500 (milliseconds) may be a reasonable timeout.
Run Code Online (Sandbox Code Playgroud)

背景,为什么我认为这是一个修复

我们环境中的几台服务器在重新启动并启动服务时出现问题。这些服务大多以某种方式与 .NET 相关。他们都想出了7009事件。我们有问题的防火墙服务器上的一些服务也显示此事件 ID。尽管 7009 从未出现过防火墙或基本过滤服务,但加载过程中的超时(尤其是因为它有时加载得很干净)似乎可能是罪魁祸首。

这些注册表设置来自 technet 博客“在没有 Internet 访问的情况下配置 Exchange 服务器”