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:enableauditpol /set /subcategory:"Filtering Platform Connection" /success:enable /failure:enableauditpol /set /subcategory:"IPsec Driver" /success:enable /failure:enableauditpol /set /subcategory:"IPsec Main Mode" /success:enable /failure:enableauditpol /set /subcategory:"IPsec Quick Mode" /success:enable /failure:enableauditpol /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: disableauditpol /set /subcategory:"Filtering Platform Connection" /success: disable /failure: disableauditpol /set /subcategory:"IPsec Driver" /success:disable /failure:disableauditpol /set /subcategory:"IPsec Main Mode" /success:disable /failure:disableauditpol /set /subcategory:"IPsec Quick Mode" /success:disable /failure:disableauditpol /set /subcategory:"IPsec Extended Mode" /success:disable /failure:disable
Many 5159 events are logged in the Security event log after you disable Windows Firewall and enable the "Filtering Platform Connection" auditing policyhttp://support.microsoft.com/kb/969257
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.
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 :)
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.
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.
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?
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.
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.
Process ID: 1260
Application Name: \device\harddiskvolume2\windows\adws\microsoft.activedirectory.webservices.exe
Source Address: ::1
Source Port: 52826
Destination Address: ::1
Destination Port: 389
Filter Run-Time ID: 0
Layer Name: Connect
Layer Run-Time ID: 50
Can anyone help me resolve this?
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.
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
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.