5

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.

4
  • 1
    I have seen something similar with Win7 and Server 2008 R2 machines not allowing RDP access until you have logged in directly.
    – DanBig
    Oct 21, 2013 at 17:11
  • I had a similar issue, but it turned out it was just a bad local policy being applied at boot up. Are you manually able to manage the firewall settings after the system boots up (until the next reboot)?
    – CIA
    Oct 21, 2013 at 19:52
  • @CIA - unfortunately not. The firewall policy is totally managed via GPO so that isn't an option. It does display properly via the MMC console however. Oct 21, 2013 at 20:23
  • For troubleshooting purposes, you could clear the firewall policies while the machine is off the network using a local admin account (Administrative Tools > Local Security Policy > Windows Firewall Policy; Right-Click > Clear Local Policy), then reboot. If the issue returns at boot up, there's probably a corruption in the registry. If the issue doesn't return, connect the machine back to the network and GPUPDATE /FORCE to re-pull the GPO, then reboot and see if the issue returns.
    – CIA
    Oct 22, 2013 at 0:19

1 Answer 1

0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .