Re: Windows Firewall Dropping Return UDP Packets by Roger
Roger
Sun Mar 09 09:26:46 CDT 2008
"Will" <westes-usc@noemail.nospam> wrote in message
news:w5qdnTqblroq9k7anZ2dnUVZ_vGinZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:OhaxJvZgIHA.2268@TK2MSFTNGP02.phx.gbl...
>> Or perhaps not, but I did want to check to make sure you have taken
>> into account any blocking rule that would name the origin IP of the
>> member server, directly or by subnet match. A more origin specific
>> block rule would be the only documented, expected behavior in a
>> non-misbehaving implementation AFAIK.
>
> Hi Roger. Does Windows Firewall have any kind of blocking rules? I
> only see a list of exceptions in Windows 2003 version of Windows Firewall.
>
> The thing is the host that is being blocked is working on those same ports
> just fine with the target domain controller. It appears that only some
> of the UDP packets get blocked. Since UDP is stateless, I am completely
> at a loss as to why the server would reject some but not all similar
> packets.
>
Doh ! Quite right Will, guess I was thinking IPsec which I do
tend to use instead of Windows Firewall on W2k3 / W2k3 R2,
as I have incountered some strange behaviors from Windows
Firewall on W2k3 (there once was a KB that stated firewall
might only enforce rules for one IP on interface with multiple,
a KB that sat without change, except in review date, for over
a year - but I have seen W2k3 firewall block all traffic to one
nic, irregularly/unpredictably, on a multihomed server even
though nothing said to block the traffic.)
So, you are right, I was not thinking of W2k3 firewall in my
reply, but I was trying to politely indicate that you may be
seeing a firewall quirk, as at W2k3 I would not be surprised.
Roger
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:OhaxJvZgIHA.2268@TK2MSFTNGP02.phx.gbl...
>> "Will" <westes-usc@noemail.nospam> wrote in message
>> news:EoudnY9yvvBZNFLanZ2dnUVZ_jCdnZ2d@giganews.com...
>>>I have a Windows 2003 Server Domain Controller with Windows Firewall
>>>enabled and set up correctly, and the domain controller works fine.
>>>But I occasionally see dropped packets for protocols in the pfirewall.log
>>>file that are absolutely authorized for travel through the firewall.
>>>For example, we have rules that allow any incoming packets on UDP ports
>>>53, 88, and 389, yet I still see entries in Windows firewall such as
>>>these:
>>>
>>> 2008-03-05 18:47:00 DROP UDP 192.168.14.121 192.168.105.13 3825 389
>>> 246 - - - - - - - RECEIVE
>>> 2008-03-05 18:47:00 DROP UDP 192.168.14.121 192.168.105.13 3825 389
>>> 246 - - - - - - - RECEIVE
>>> 2008-03-05 18:47:00 DROP UDP 192.168.14.121 192.168.105.13 3825 389
>>> 246 - - - - - - - RECEIVE
>>> 2008-03-05 18:47:00 DROP UDP 192.168.14.121 192.168.105.13 3825 389
>>> 246 - - - - - - - RECEIVE
>>> 2008-03-05 18:47:01 DROP UDP 192.168.14.121 192.168.105.13 3826 53
>>> 105 - - - - - - - RECEIVE
>>> 2008-03-05 18:47:02 DROP UDP 192.168.14.121 192.168.105.13 3830 88
>>> 1403 - - - - - - - RECEIVE
>>>
>>> 192.168.105.13 is the host that is protected by the firewall in this
>>> case, and 192.168.14.121 is a member server communicating to the domain
>>> controller.
>>>
>>> I'm well aware of the many special requirements that domain controllers
>>> have when used with firewalls. I don't need to read Knowledgebase
>>> 555381 for example.
>>>
>>> My question is under what circumstances does it make sense for the
>>> firewall to be blocking the above UDP packets when the firewall rule
>>> explicitly allows them as exceptions? Maybe someone who understands
>>> details about the Windows Firewall's internals could explain why such
>>> packets might be dropped.
>>>
>>
>> Or perhaps not, but I did want to check to make sure you have taken
>> into account any blocking rule that would name the origin IP of the
>> member server, directly or by subnet match. A more origin specific
>> block rule would be the only documented, expected behavior in a
>> non-misbehaving implementation AFAIK.
>>
>> Roger
>>
>> Roger
>>
>
>