Well, I express my appreciation again. Without your input I never would've gone down that path. Thanks!
From: [email protected] [mailto:[email protected]] On Behalf Of Woody Blackman Sent: Thursday, February 6, 2014 10:42 AM To: '[email protected]' Subject: RE: [NTSysADM] RE: windows advanced firewall "One is glad to be of service" From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Andrew S. Baker Sent: Thursday, February 06, 2014 7:04 AM To: ntsysadm Subject: Re: [NTSysADM] RE: windows advanced firewall Awesome! Thanks for that info, Woody. ASB http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker> Providing Virtual CIO Services (IT Operations & Information Security) for the SMB market... On Wed, Feb 5, 2014 at 5:14 PM, Michael B. Smith <[email protected]<mailto:[email protected]>> wrote: And the winner is.... Thanks! That was ridiculously complicated (but probably because I had never used those tools before). Windows Server has decided that DS1 is doing a port scan on DS2 (which it isn't, but I know why it thinks that). And DS2 is using the "Port Scanning Prevention Filter" to drop RPC and UDP packets from DS1. This is an inbuilt rule. In the over-arching wisdom of the Windows architects, they know best and there is not any supported way to disable this filter. Nonetheless, there are unsupported ways to make this change and I will give them a go. From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Woody Blackman Sent: Wednesday, February 5, 2014 3:46 PM To: '[email protected]<mailto:[email protected]>' Subject: [NTSysADM] RE: windows advanced firewall The below approach has been hit or miss for me in trying to debug Windows Firewall weirdness: If you are getting "Filtering Platform Packet Drop" Event 5152 Could be something from Stealth Mode is blocking and not logging http://social.technet.microsoft.com/Forums/windowsserver/en-US/b627fbdf-e51b-4671-911e-3308271e3a0e/windows-adv-firewall-drops-allowed-traffic-to-closed-ports?forum=winserversecurity You can try running at an elevated command prompt "Netsh.exe WFP Capture Start" Reproduce the event Execute "NetSh.exe WFP Capture Stop" In the output, there will be a section for NetEvents which indicate whether the drop was due to a filter or the stack. stack drops can occur because no endpoint is listening, invalid headers, etc. You can use "NetSh.exe WFP Show State" to show you the list of filters on the machine. In the event, you should see the filterId for the filter that caused the drop. http://social.msdn.microsoft.com/Forums/en-US/f623bffb-4ff1-496b-9dc4-65136bc6e88b/loads-of-filtering-platform-packet-drop-event-5152-with-firewall-configured-to-allow-all?forum=wfp From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Michael B. Smith Sent: Wednesday, February 05, 2014 10:00 AM To: [email protected]<mailto:[email protected]> Subject: [NTSysADM] windows advanced firewall I'm stumped. Server 2008 R2. All current patches. We have DS1 and DS2. I built these servers a couple of years ago using my handy-dandy deployment scripts. They are identical. They are physical. They have exactly the same firewall rules (and yes, I have compared those rules from a rules dump). They are on the same subnet. They have this subnet in their Scope --> Allowed Remote IP Addresses. They are both DCs and GCs. They point to themselves as primary DNS and each other as alternate DNS. They are both running Endpoint Protection 2012 R2 using the standard DC template provided by MSFT. They plug into the same switch. DS2 dumps all AD-related RPC and DNS traffic from DS1. I turned on firewall logging on DS2. The firewall even says it's dropping the packets. For example: 2014-02-05 11:18:15 DROP TCP 10.0.59.36 10.0.59.37 54897 389 40 FA 1470786861 397644096 253 - - - RECEIVE 2014-02-05 11:39:13 DROP UDP 10.0.59.36 10.0.59.37 53 58716 123 - - - - - - - RECEIVE (DS1 is 10.0.59.36, DS2 is 10.0.59.37) But rules say that traffic should be allowed. So I created another rule on DS2 that allows ALL traffic from DS1 to DS2. NO change. DS2 dumps all RPC and DNS traffic from DS1. So AD replication initiated on DS1 toward DS2 doesn't work. DS2 has to initiate replication. DNS requests from DS1 to DS2 don't work. Etc. There are a variety of problems. Some RPC related things do work (on DS1, I can "tasklist /s ds2", I can open the ds2 services console, the ds2 event console, etc.). What have I missed? What next to check? Thanks for any assistance...
