Home / server / Questions / 547593
Accepted
Tim Brigham
Asked: 2013-10-22 09:05:35 +0800 CST

Windows firewall blocks nearly all traffic after reboot?

  • 772

Sometimes when the systems boot they don't accept any inbound traffic at all and my IPSec rules don't work outbound - it appears that the server is stuck in some kind of initial post boot configuration. This is primarily for 2008 r2 and Windows 7.

I was reading some time ago that there is some kind of default configuration in the windows advanced firewall that blocks all inbound traffic and only allows specific outbound traffic - to the domain controllers, DNS, DHCP if my memory serves - but blocks all other access until the 'real' rules are loaded and applied. It sounds like this is the state my systems are getting stuck in post reboot.

What is the name of this state and how can I go about diagnosing my issue? I lost track of those details long since and I'm having a heck of a time finding them again.

EDIT:

I finally found the proper name for this behavior, the windows firewall boot time filter

EDIT:

This just got stranger. It looks like I can now make inbound connections from non IPSEC enabled systems but that any IPSEC requests are failing. I enabled some auditpol logging and I'm getting the following. 

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

I was able to work around this issue temporarily by defining a local IPSEC policy - even the firewall rule work - but I'm not sure why this is the case or what I can do to fix it long term.

windows-server-2008-r2

1 Answers

  1. Best Answer

    The registry changes outlined below have allowed the half dozen or so of my servers that it has been applied to so far boot without issues. While I'm not yet 100% sure that this is a solution - it was about 50/50 if a server would come up cleanly it does appear to have helped tremendously. Half a dozen servers with 3+ reboots each are acting normally. 

    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.

    Background, why I think this is a fix

    Several servers in our environment were exhibiting problems when rebooting having services come up. These services were mostly related to .NET in one fashion or another. They all came up with 7009 events. Some of the services on our problematic firewall servers also show this event id. Although a 7009 never came up for the firewall or base filtering service a timeout during the loading process - especially since it does sometimes load cleanly - seemed like a likely culprit.

    These registry settings came from a technet blog, Configuring Exchange Servers Without Internet Access.

    • 0