This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Why Does wireshark not capture any traffic from Source Machine with Outbound Firewall Rules?

0

Hi,

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.

Please suggest

Regards, Prad :)

asked 19 May '12, 22:00

im_prad's gravatar image

im_prad
5114
accept rate: 0%

edited 19 May '12, 22:03


2 Answers:

1

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

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks for the suggestion Jasper,

However if the packet capture from Same system where the firewall is implemented doesn't show in Wireshark, then while capturing for a third, passive device, that runs Wireshark and is port spanned for System where firewall is, will that show the traffic initiation there?

Thanks, Prad

(28 May '12, 16:49) im_prad

Yes, because if you use a third system that captures the traffic between the other two will see packets that are already "on their way" and on the wire. They can't be "hidden" inside internal OS channels or paths. As long as they have been put on the wire you will see them, unless they get damaged (which means: discarded) or your capture device is too slow to pick them all up.

(29 May '12, 10:18) Jasper ♦♦
1

Even when you are on a third system, any traffic originating on the firewall machine and blocked by the firewall (Windows internal, for example) will still not show up, since it never reaches the network. But if you are looking for packets that are managing to evade the firewall in some way and get out anyway, then they will be seen.

(29 May '12, 11:47) inetdog

Conflicting views here from the experts.

I'll mark this as answered for now as it's on VM and can't test anytime soon with the port span/ 3rd Machine option.

Thanks a lot to all of you here.

(30 May '12, 20:15) im_prad

1

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:

http://www.winpcap.org/docs/docs_41b5/html/group__NPF.html
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366510(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366509(v=vs.85).aspx

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.

Regards Kurt

answered 20 May '12, 09:10

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

You have to keep in mind TCP chimney offloading as well, setting up some kind of "vitrual tunnel" between application/network stack interface and an NDIS capable NIC, which also has an impact on the data wireshark is able to "see".

So I'd always go for a by-system analysis if those question are of interest, because with simply changing the NIC to another driver version / manufacturer things could change at all

(20 May '12, 09:21) Landi