0

Just installed Windows Server 2008R2 SP1 to see if it would fix this problem, but it didn't. Until an administrator logs onto the domain controller, there are many events that WFP blocked a connection from Server60 to Server60 or Server60 to Server70. Both server60 and server70 are the domain controllers. One the admin logs on, the WFP events stop.

The firewall is off by default GPO. Yes, i know that the WFP kicks in during the boot up sequence until the firewall takes over or in my case does not take over (since Vista), but i clearly should not have to autologon to a domain controller and call autolock or something.

Example event
LEVEL = Information Source = Microsoft Windows Security Auditing EventID = 5152 "Filtering Platform Packet Drop" and its evil twin id = 5157 "Filtering Platform Connection"

"The Windows Filtering platform has blocked a connection."  
Direction %%14593 
SourceAddress 192.168.10.60 
SourcePort 49677 
DestAddress 192.168.10.60 
DestPort 389 
Protocol 6 
FilterRTID 65667 
LayerName %%14611 
LayerRTID 48 
RemoteUserID S-1-0-0 
RemoteMachineID S-1-0-0

windows-server-2008-r2 WFP BFE WindowsFilteringPlatform BaseFilteringEngine

rjt
  • 578
  • 6
  • 26
  • Just to be sure, the GPO is a Computer Policy applied to a computer object - right? Otherwise by the sounds of it, requiring a Domain Administrator to logon before it kicks over could be because the GPO is only applied to the user object, hence the domain admin logging on and it all suddenly working... – Ashley Jul 26 '11 at 00:22

2 Answers2

1

You disable this using the following commands:

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:disable /failure: disable
auditpol /set /subcategory:"Filtering Platform Connection" /success: disable /failure: disable
auditpol /set /subcategory:"IPsec Driver" /success:disable /failure:disable
auditpol /set /subcategory:"IPsec Main Mode" /success:disable /failure:disable
auditpol /set /subcategory:"IPsec Quick Mode" /success:disable /failure:disable
auditpol /set /subcategory:"IPsec Extended Mode" /success:disable /failure:disable

Source: The Windows Filtering Platform has blocked a bind to a local port

Guido van Brakel
  • 942
  • 5
  • 10
  • That article is not for 2008 Release **2**. It does suggest these issues would be fixed in a newer release of tcpip.sys. Granted, these events would not show up in the event log by disabling whether they are audited, but it does not fix the underlying issue. Just like YY commented in the article, the server should behave the same whether or not an admin logs on first. – rjt Mar 12 '11 at 03:16
  • I this case, as the lastest comment in het blog, I would suggest you create a support case at Microsoft for this issue. This is one the issues which is very hard to troubleshoot using a forum. – Guido van Brakel Mar 12 '11 at 15:49
  • @rjt - Actually shadowman is right. This also applies to Windows 2008 R2. And you need to use this in a startup script GPO for your dc's or it will be reset when you restart. Also, this can be caused by disabling the firewall service, which you should not do. If you want to disable the firewall, that should be done in the Firewall GPO settings. – Greg Askew Dec 10 '11 at 00:04
1

To disable WFP on non-English version Windows Server or Desktop use GUID way naming:

@auditpol /set /subcategory:{0CCE9225-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
@auditpol /set /subcategory:{0CCE9226-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
@auditpol /set /subcategory:{0CCE9213-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
@auditpol /set /subcategory:{0CCE9218-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
@auditpol /set /subcategory:{0CCE9219-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
@auditpol /set /subcategory:{0CCE921A-69AE-11D9-BED3-505054503030} /success:disable /failure:disable
lin4in
  • 11
  • 1
  • 2
    But wouldnt this still simply prevent the auditing of blocked connections, not actually fix the underlying problem? – rjt Jul 13 '18 at 19:17