I was testing on Windows 2008 Standard Edition (Local Machine IP :- 192.168.2.160) with normal windows firewall (no 3rd party) and created an outbound firewall rule to deny for TCP Ports 80/443 of Remote IP (i.e. 192.168.10.104) (and Local Port All as it could be random). The firewall worked fine and I could block all outbound traffic to Ports 80/443 of that remote IP. Traffic to same ports on any other remote IP worked just fine.
However I would have expected wireshark to have picked up the traffic initiation attempt at least from local PC/random ports and drops when matched against remote IP/Port that I have defined in the Outbound Rules.
== > However I could see absolutely no traffic for this when running wire shark on the Local PC where I had applied such a rule.
== > Checking the windows Firewall Logs I could see the Drops:-
2012-05-20 10:08:34 DROP TCP 192.168.2.160 192.168.10.104 49215 80 0 - 0 0 0 - - - SEND
2012-05-20 10:08:35 DROP TCP 192.168.2.160 192.168.10.104 49216 80 0 - 0 0 0 - - - SEND
== > So the windows firewall clearly shows the drops then why does that not reflect in the wireshark?
== > Is it because the Firewall is software based and the request was made via a browser that it never gets sent down beyond the network layer from the App layer of the same PC when Windows firewall and the PC in fact never sends the packet.
Or is there some setting on wire-shark that can allow such drops to show as well as we can see in the Firewall logs above.
The main reason for me to ask this I want to clarify the way this works as the traffic not showing could be an issue with:-
1.) An application as well which might not be able to invoke the lower layers and initiate from source itself. OR, 2.) It could be an issue with block as well like this and we would not be able to distinguish via packet captures b/w them and more so if no such logs / 3rd party unknown firewall apps are present.
== > I am not sure if I should have posted this concern in Windows forum or wireshark but since I could see nothing in wire-shark unlike in the Windows Firewall Logs.
Regards, Prad :)
Most likely the Windows Firewall will drop the packets before they even get close to the point where dumpcap (which does the actually capture for Wireshark) can see it and pick it up.
My advice is always the same: if you want to verify if a node behaves like it should, do not capture on the node. Capture on a third, passive device, that runs Wireshark and that picks up the nodes packets from a SPAN Port/HUB/TAP. It's the only way to know what really happens (or doesn't happen).
answered 20 May '12, 05:27
The Windows 2008 firewall is implemented with the WFP (Windows Filtering Platform), which is implemented deeply in the windows kernel, as one of the core components. Before a packet is allowed, the related stack (e.g. TCP) uses the WFP API to determine if the connection/packet is allowed, according to the filtering rules.
The NPF driver of WinPcap is implemented as a NDIS protocol driver. Without knowing it for sure, I strongly assume that the NPF filter is located somewhere "below" the windows TCP/IP stack, so you won't see any blocked packets/connections.
For further reading I recommend these links:
Furthermore I second what @Jasper said. If sniffing is your main interest, please do it "off system". If the internal workings of the Windows Firewall is your main interest, I recommend the links above.
answered 20 May '12, 09:10