Share via

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

  • Article

You may notice event 5159 being logged on your Windows 2008 Server(s) indicating a connection has been blocked/dropped, etc.
The Process ID will indicate which application was blocked (tasklist /SVC can be used to get details on running PID's) and which protocol was involved.

The actual enforcement of the firewall rules is done by WFP through traffic filters derived from the firewall policy.
To further troubleshoot this you can enable WFP auditing and monitor the event viewer to see what is happening in WFP while you reproduce the problem that you want to troubleshoot.

One common event we have observed is where the initial attempt is made using UDP (protocol 17) which is blocked and then a second attempt is made using TCP which is allowed, this is typical of Kerberos traffic which first tries UDP and then attempts TCP if UDP fails.

By default the drop is not logged, so you should really only see this event if one of the Audit subcategories (Filtering Platform Packet Drop) has been turned on.

To enable WFP auditing:
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
auditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Driver" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Main Mode" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Quick Mode" /success:enable /failure:enable
auditpol /set /subcategory:"IPsec Extended Mode" /success:enable /failure:enable

...Repro the failure, go to the Security event log and monitor for the events.

To disable WFP auditing:
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

 

See also:

Many 5159 events are logged in the Security event log after you disable Windows Firewall and enable the "Filtering Platform Connection" auditing policy
http://support.microsoft.com/kb/969257

Comments

  • Anonymous
    January 01, 2003
    Yuriy - this blog post was for Windows 2008, not Windows 2008 R2.   I can only advise opening up a support case to get someone to assist you live with this as this is likely to require extensive communcation and log gathering from your side - troubleshooting this on a blog isn't likely to help resolve the issue.

  • Anonymous
    January 01, 2003
    The fix in KB969257 should also apply to the audit events 5152, 5157 and 5159 even if it is only explicitly referencing 5159. Whether that is the exact issue you're encountering only time (and installing the hotfix) can tell.

  • Anonymous
    January 01, 2003
    You don't specify what "communicating" means in this context so it's hard to comment specifically on it. The Windows Firewall can however block DC-DC communication same as any firewall if it is configured to do so. The best way to troubleshoot your scenario would be to start a network monitor trace on both DC's at the same time and then force active the communication you're having a problem with (f.x. repadmin /syncall for replication problems). Chances are you'll see the packet leaving the interface on one DC and never arriving at the other Dc's interface.   At that point it's time to knock on the door of your friendly networking department and show them your trace :)

  • Anonymous
    January 01, 2003
    Problem still there - inbound and outbound connections between 2008R2 servers blocking randomly - no matter to which port or by which application they're established. That's not funny - users cannot work

  • Anonymous
    January 01, 2003
    KB969257 is only for Windows 2008 - not for Windows 2008 R2. The latest update for tcpip.sys for W2k8 R2 is in KB2028625 - not sure whether the change in KB969257 was included in the RTM of Windows 7/2008 R2 or if it is included in a post-RTM hotfix (or if it is even an applicable change). From the event it looks like IPv6 traffic by the AD web services application to port 389 on itself was blocked - don't remember off-hand what protocol 6 is. The real question is if you're seeing any problems related to this or just the event being logged.

  • Anonymous
    January 01, 2003
    It's not really feasible to troubleshoot in any detail through a blog entry, but there is one pending fix for tcpip.sys that is scheduled to be released within the next couple of weeks that could potentially be related to the problem you're seeing. When it has been released you should be able download it at http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=969257&kbln=en-us I would also recommend checking out the Networking team's blog and see if they have any further information on this. http://blogs.technet.com/networking/

  • Anonymous
    April 28, 2009
    Will this event (ID 5159) block one server from communicating with another? I have two servers on the same domain, they can communicate (ping, trace, terminal, etc) in and out from the domain and within the domain but they can't communicate with one another.

  • Anonymous
    May 25, 2009
    Hi, I have the this error whenever a user logoff from the server or server rebooted without user logging in at the console. This causes my microsoft NAP failing to work. However, when a user logon to the server console, my NAP works fine. Strange? Any idea what has gone wrong? is there a workaround to this? Ayway of disabling blocking of local port bind? Thanks in advance. YY

  • Anonymous
    March 10, 2010
    I know this thread is old, but I hope you still get notified. We are getting numerous 5152, 5157 and 5159 event id's, even though the Windows Firewall is turned off.  I have looked at the KB article you have a link to above, but I'm wondering.. does the hotfix apply only to the 5159 errors, or to all of them?

  • Anonymous
    September 08, 2010
    I downloaded the hotfix and attempted to install it on a Windows 2008 R2 DC and received the error "This update is not applicable to your computer". The Event ID 5157 is occuring on all of my Windows 2008 R2 DCs, the firewall is disabled. Here is an example: The Windows Filtering Platform has blocked a connection. Application Information: Process ID: 1260 Application Name: deviceharddiskvolume2windowsadwsmicrosoft.activedirectory.webservices.exe Network Information: Direction: Outbound Source Address: ::1 Source Port: 52826 Destination Address: ::1 Destination Port: 389 Protocol: 6 Filter Information: Filter Run-Time ID: 0 Layer Name: Connect Layer Run-Time ID: 50 Can anyone help me resolve this?