Not able to block traffic using Npcap

[sbrown89]

Windows 10:

Npcap version 1.31
Added the needed registry keys:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\npcap\Parameters
BlockRxAdapters \Device\{6834AB76-46AB-49C2-9CFF-D391B6FF924D}
SendToRxAdapters \Device\{6834AB76-46AB-49C2-9CFF-D391B6FF924D}

Yes the GUID is the correct one for the adapter:

The service was restarted, box was restarted and verified the service is running:

Packets always make it out of the adapter like normal. Any ideas?
Thanks for looking into this.

[guyharris]

Not able to block traffic using Npcap

That's not what Npcap is designed to do - it's designed to passively capture network traffic and let traffic be passively injected. Have you written a program, using Npcap, that you expected to be able to block traffic?

[sbrown89]

Not able to block traffic using Npcap

That's not what Npcap is designed to do - it's designed to passively capture network traffic and let traffic be passively injected. Have you written a program, using Npcap, that you expected to be able to block traffic?

But it is. The driver has full support and config options to do just this. There is also older examples that describe creating a firewall for just this purpose. user bridge + fw setup That example uses older registry keys ... im using the ones the driver currently uses.

Yes I have a fully working program that can capture / inject and if I can get this working stop / drop packets on windows.

[dmiller-nmap]

@sbrown89 Thanks for reporting this. We made what ought to have been a minor change in the code to read adapter names from the registry in Npcap 1.31, but this ought to still be supported. Does any previous version such as 1.30 work like you expect?

[sbrown89]

@dmiller-nmap Yes, version 1.30 works as expected. Only the packets I allow and send back to npcap driver get through all others are blocked.

[guyharris]

If this is to be a supported feature, it should be documented (somewhere other than an ancient release's release notes), and should perhaps be supported by packet.dll APIs.

[dmiller-nmap]

@sbrown89 Thanks for checking that. I'll review the code change and see what can be done to resolve this issue.

@guyharris I agree that this feature is not well documented. I'm not sure whether it fits with Packet.dll, though, since it's not really about capture or injection. If a user needs this feature for their system, it has to be present from the time Npcap is inserted in the network stack at boot, which makes Registry the appropriate place. On the other hand, that makes it seem like Npcap ought to be a mandatory filter instead of optional as it currently is, which is a whole set of testing and support that we haven't looked at.

[fyodor]

Thanks for the report. We are hoping to fix this regression in the next Npcap release. I have also opened Issue #497 for evaluating the future of this cool but undocumented and in some respects problematic functionality.

[dmiller-nmap]

This issue should be addressed in Npcap 1.50. We also made an improvement in this data path that you may notice as improved performance, though we did not measure that specifically. Let us know if you run into further problems.