[Help] Why npcap does not capture winpkfilter diverted packets?

[NULL0B]

Hello recently I realised that Wireshark (Npcap based) wasn't showing diverted NAT packets from a router app called Connectify. Which is implemented using WinPkFilter. I can't see arriving packets to the nat Interface, only the ones which are directed to its own ip. It seems that winpkfilter is hooking or something lower than npcap.

I would like to know if is possible to get those packets or whats happening.

Thanks, Greetings

PD: Haven't tried Windivert based apps but I may asume the same behaviour because they're implemented via WFP with same purposes.

[dmiller-nmap]

According to the documentation, WinpkFilter is implemented as a NDIS 6 LWF driver, the same as Npcap. It appears to be using the same FilterClass as Npcap, which uses the "compression" FilterClass. Therefore the binding order is determined by some other factor which I do not know. This is something we could investigate changing, as the "diagnostic" or "custom" classes would make sense and would guarantee Npcap binds lower on the stack than WinpkFilter. However, that would put us below the "vpn" class and may result in changes in the way VPN packet capture happens.

We will keep this in mind as we consider further Npcap development. We'd welcome any input from the community, including reports of other NDIS LWF-based software that interferes or bypasses Npcap this way.

[NULL0B]

Thanks for the fully detailed answer. Oh I see Winpkfilter is using same as Npcap, haven't tested Windivert which is on top of WFP but it seems that fixing NDIS LWF would hook lower. Is it correct to reference #257 and #516 as they seem to be related in some way?

[jtippet]

We (Microsoft networking team) had a customer ping us about essentially the same issue. I agree with @dmiller-nmap in that diagnostic or even custom would seen to be more logical for what npcap is doing. Those FilterClasses are supported on all versions of Windows that have LWFs.

The potential gotcha, as @dmiller-nmap hinted at, is that if some LWF was doing encryption, you will be stuck with ciphertext if you move your capture point below it. Although there might be cases where a customer would want to look at ciphertext, it's probably more common to want to look at plaintext.

We solve that with ndiscap by marking ndiscap as a "monitoring" filter:

HKR, Ndi,FilterType,0x00010001, 1 ; Monitoring filter

This change has only one consequence: NDIS would attach an instance of your LWF directly above the miniport, and also another instance above each other modifying LWF. That means your filter has the opportunity to see inbound traffic directly from the NIC, and again after each LWF has handled it.

Of course, most of the time the admin does not want to see every packet repeated 5 times. So ndiscap, by default, ignores any traffic that arrives at an instance that is not bound directly over the NIC. If the admin is specifically interested in how the various LWFs munge traffic, the admin can use an "AllLayers" flag to tell ndiscap to include traffic from each instance of the filter.

I don't know if this complexity is the right fit for npcap, but it's certainly an option.

As I see it, you can do a few things:

• Don't change anything. Customers can't see traffic out of other, lower LWFs.
• Change the FilterClass to diagnostic or custom. You'll see traffic closer to the wire, for better (more accurate view of the station's actual behavior on the network) and worse (more ciphertext).
• Change to a monitoring LWF, and add some way (registry key?) to suppress nearly-redundant instances unless the admin enables it.
• Ship 2 LWFs: one that binds high and one that binds low. Let the admin decide which to install.

[fyodor]

Hi folks. We had an engineering meeting about this today and I wanted to summarize some points for everyone else and so we don't forget...

Right now Npcap is a "compression" NDIS LWF filter and you can see where those fall in the stack at this Microsoft page. Just changing where we attach on the stack is not a great option. It could break existing users who depend on the current order between Npcap and other drivers, and it isn't clear that there's an overall "better" place to sit. Some users want it earlier in the stack while others have good reasons for wanting it later. We tend to err on the side of attaching closer to the network since Npcap is fundamentally more of a network sniffing library than one for capturing internal communication between drivers in the networking stack. Also for applications which send packets through Npcap rather than just capturing them, I believe the FilterClass also plays an important role. Like you may want to inject them early enough that they can be encapsulated and encrypted and sent through a VPN driver.

Install-time configuration of the FilterClass is not a great option either. For efficiency and implementation reasons, it's very important that multiple applications be able to share the Npcap driver. We don't want a case where it's working for one application, and then another application gets installed on the machine and places Npcap in a different FilterClass which causes problems for the first. There are also some technical challenges to this approach. We would need to ship a separately signed INF file for each configuration option and of course we'd need to test that Npcap works at all of these different points in the stack. And it would need to work on all the versions of Windows (and thus NDIS) that we support.

One possibility would be trying to efficiently attach through NDIS at multiple different stack layers concurrently and allowing applications to control it on a per-capture-handle basis. But we think an even more promising approach is using the Windows Filtering Platform instead. We already use a WFP callout driver and filters for loopback capture, so we already have the functions available to receive packets and give them to the user. The only missing parts are:

1. An API for the user to specify different behavior/layer than just loopback
2. the filter syntax to get the packets at the place where we want them.

There are so many possibilities for layer, direction, etc. that we wouldn't want to expose all of them right away, but it would be important that the API be flexible enough to allow the user to specify the full range. The easiest place to do that is in the adapter name itself, just as we do with loopback ("NPF_Loopback" would become "NPF_WFP/whatever". One non-loopback application we've discussed is the "any" pseudo-adapter, just like on Linux.

Pre-encrypt/post-decrypt capture is another strong use case. It may even be possible do intercept SSL done with SChannel (e.g. IIS) to obtain the cleartext.

In fact, since MAC-layer filtering was added in Windows 8, it's even conceivable that in the future we could replace all of Npcap's capabilities with WFP functions.

These are really exciting capabilities and we'd definitely like to expand Npcap's scope like this at some point. We already have a very packed roadmap of enhancements and improvements to Npcap's existing functionality, so we can't commit to these new features just yet. But we welcome any ideas and suggestions you all may have. Especially full details on any challenges you may face with the current setup and how you would like for it to work instead. Of course we also welcome implementation ideas from folks who happen to be NDIS/LWF/WFP experts.

[guyharris]

Change the FilterClass to diagnostic or custom. You'll see traffic closer to the wire, for better (more accurate view of the station's actual behavior on the network) and worse (more ciphertext).

For what it's worth, this sounds like the way the capture tap mechanisms work on most UN*Xes - the tap is early in the path up the networking stack when receiving, and late in the path down the networking stac when sending. I'm not sure what forms of encryption are being referred to there, but if, for example, the UN*X machine is connected to a VPN, that often results in a new network interface being created. A capture can be done on an interface that corresponds to a network adapter, which shows what's on the network - encrypted, if it's VPN traffic - or on the VPN interface, which shows what's being sent on and received from the VPN, unencrypted.