NDISAPI is the user-mode face of a Windows kernel packet filter

The library is a wrapper around a separate kernel driver

The architecture has two halves and the split matters for anyone deploying it. NDISAPI is a user-mode interface library for interacting with the Windows Packet Filter driver, and the documentation is explicit that the driver is a separate thing, called WinpkFilter. The library itself is described as offering a straightforward, safe and efficient interface for filtering, meaning inspecting and modifying, raw network packets at the NDIS level of the network stack, with the stated goal of minimal impact on network performance. The driver is described as a packet filtering framework tailored for Windows environments, handling raw packets at the NDIS level with capabilities for packet inspection, modification and control, and the documentation credits it with user-friendly APIs, compatibility across various Windows versions and streamlining packet manipulation without the need for kernel-mode programming skills. In practice this means your application links against a DLL, that DLL communicates with a driver installed on the machine, and the driver sits in the network stack below the normal socket layer.

Three capabilities, all of them at the packet level

The key features list is short and every item is about the packet rather than about an application protocol. Network adapter management covers enumerating and managing network adapter properties, which is what the `listadapters` example demonstrates and what a tool needs before it can attach to a specific interface. Packet analysis and modification covers capturing, filtering and modifying network packets, which is the bulk of the library. Packet transmission covers sending raw packets directly through the network stack, which is the capability that makes the library usable for building things rather than only watching them. The three examples that show this last one are worth naming because they are the least obvious. The `gretunnel` example demonstrates IP over GRE tunneling by modifying packet headers, the `udp2tcp` example converts between UDP and TCP protocols, and the `rebind` example rebinds TCP and UDP connections to different network interfaces. All three work by rewriting headers on packets already in flight rather than by asking a socket API to do something different, which is why the library sits where it does.

Four library flavours, from C++/CLI down to Visual C++ 6.0

The library components section shows a range of targets that tells you how seriously the portability question is taken. There is `ndisapi.dll`, a native Win32 DLL wrapper in x86, x64 and ARM64 versions, and `ndisapi.lib`, the native Win32 static library wrapper in the same three architectures. There is `ndisapi.net`, a .NET C++/CLI mixed class library also in x86, x64 and ARM64 versions, which is how the C# example reaches the native code. Then the two project files for older toolchains: `ndisapi.vs2012`, a Visual Studio 2012 project for the native Win32 DLL wrapper supporting Windows XP and 2003 in x86 and x64, and `ndisapi.vc6`, a Visual C++ 6.0 project supporting legacy Windows versions prior to Windows XP and 2003. The C++/CLI layer is a deliberate choice rather than a P/Invoke wrapper, and it is what lets a .NET application call into the native library without hand-written interop. The root of the repository holds the solution file `ndisapi.sln`, the `include/` directory, the prebuilt `ndisapi.dll/` and `ndisapi.lib/` directories, and a `cygwin/` directory alongside a `tools.cmd` script.

Building the examples means vcpkg manifests, or a manual vcpkg install

The examples come with their dependencies handled automatically when you build them in Visual Studio 2022, which the documentation says is the simplest approach and the one recommended for most users. The example projects are set up to automatically manage their dependencies using vcpkg manifests, and the process is described as requiring no additional manual installation. For anyone on a different environment or who prefers manual control, the standalone commands are given with specific triplets. Microsoft GSL is required for all the examples:

  vcpkg install ms-gsl:x86-windows ms-gsl:x64-windows ms-gsl:arm64-windows ms-gsl:x86-windows-static ms-gsl:x64-windows-static ms-gsl:arm64-windows-static

PcapPlusPlus is only needed for the `pcapplusplus` example, and Hyperscan plus llhttp only for the `hyperscan` example:

  vcpkg install pcapplusplus:x86-windows pcapplusplus:x64-windows

    vcpkg install hyperscan:x86-windows hyperscan:x64-windows

The note at the end is worth repeating because it is the practical difference between the two paths: using Visual Studio 2022 with built-in vcpkg support is the preferred method, as it greatly simplifies dependency management, while the standalone commands exist for people who need manual installation or work in different environments.

The beginner examples are grouped by the compiler you have

The example projects are sorted by skill level, but the sorting axis is really the toolchain. The basic C++ examples are described as ideal for beginners, showcasing the fundamental capabilities of NDISAPI, and as adaptable to different development environments and Windows versions. Within that group the split is by compiler: built with Visual C++ 6.0 the binaries are compatible with Windows 95/NT and later, and built with Visual Studio 2012 they suit Windows XP/2003 and later. The projects themselves are `listadapters` for enumerating adapters and their properties, `packetsniffer` for the basics of sniffing, `passthru` for single packet processing, `packthru` for handling multiple packets simultaneously, `ndisrequest` for sending NDIS requests to adapters, `filter` for selective filtering using built-in static filters, `wwwcensor` for content filtering in HTTP packets based on specific keywords, and `gretunnel` for IP over GRE tunneling. The advanced Visual Studio 2012 group adds `snat`, a simple MFC Internet Connection sharing application, and `lfnemu`, a Long Fat Network emulator for simulating LFN behaviour over local networks.

The Visual Studio 2022 examples cover interception, bridging and fingerprinting

The advanced examples for experienced users are where the library's range becomes visible, and each one names a distinct technique. `capture` captures and saves network packets in PCAP format. `dns_proxy` implements a transparent UDP proxy for the DNS protocol, and `dnstrace` intercepts and decodes DNS responses. `ethernet_bridge` bridges wired and wireless network connections, and `ipv6_parser` intercepts IPv6 packets and parses protocol headers. `sni_inspector` extracts SNI and Host headers from HTTPS and HTTP packets, which is the mechanism behind a large amount of traffic classification. `socksify` redirects TCP connections through a SOCKS5 proxy, and `udp2tcp` converts between the two protocols. `rebind` rebinds connections to different interfaces, `pcapplusplus` uses PcapPlusPlus for packet parsing and TLS fingerprinting, and `hyperscan` detects HTTP sessions using Hyperscan and parses HTTP with llhttp. There is a single example above those, described as a very advanced one: ProxiFyre, an advanced evolution of the Windows Packet Filter's socksify example that adds UDP support and facilitates the management of multiple proxy instances.

C# developers get a .NET example and the C++/CLI bridge underneath

The .NET story is deliberately thin in the examples and thick in the library. The C# section lists one project, TestDotNet, which showcases NDISAPI in filtering scenarios and uses PacketDotNet for network packet header analysis. The reason it can be that simple is the `ndisapi.net` component, the .NET C++/CLI mixed class library built in x86, x64 and ARM64 versions. A mixed-mode C++/CLI assembly exposes native types directly to .NET, so the .NET side manipulates real native structures rather than marshalled copies, and the header parsing that a native developer would do by hand is handed to PacketDotNet instead. The `examples/` directory at the root is split into `cpp/`, `dotNet/` and `legacy/`, which mirrors the three tiers of the library itself. The `legacy/` folder corresponds to the Visual C++ 6.0 and Visual Studio 2012 projects, and the `cpp/` folder holds the modern Visual Studio 2022 work. So the same API surface is demonstrated at three levels of Windows, from Windows 95/NT forward.

Where this is the wrong tool

The boundary is Windows, and it is not negotiable. Everything here depends on a Windows kernel driver that sits at the NDIS level of the network stack, so a project that has to run on Linux or macOS cannot use it, and even the cross-platform parts of your product cannot share a core with it. The second limit is deployment. The library is a wrapper, not the filter itself, so the driver has to be installed on every machine where your tool runs, and that is a different kind of conversation with an operations team than dropping in a user-mode library. The third is scope. The features list is three items long, and everything is at the packet level, which means building an HTTP-aware tool on top means writing the HTTP awareness yourself, as the `wwwcensor` and `hyperscan` examples do. The alternative to weigh against is a packet capture library built on the platform's own filtering APIs, Npcap or WinPcap on Windows, which gives you packets without a custom driver but also without the ability to modify traffic in flight or bind traffic to a different interface, which is exactly the set of things the `socksify`, `udp2tcp`, `rebind` and `gretunnel` examples depend on. If you need to observe only, the standard capture path is smaller. If you need to rewrite traffic, you need this.

Editorial conclusion

NDISAPI is worth adopting if you are writing a Windows network tool that has to see traffic the application layer cannot, because the library gives you packet inspection, modification and raw transmission at the NDIS level without kernel-mode programming, and because the example set covers everything from a packet sniffer to a transparent DNS proxy and a SOCKS5 redirector. It is a poor fit for a cross-platform product, since the driver it talks to is a Windows component and the library ships only Windows builds, and a poor fit if you need something that works out of the box, because the dependency driver has to be installed separately and the examples need a Visual Studio toolchain. Before adopting it, confirm which Windows versions you must support, since the legacy projects target Windows XP/2003 and earlier, and note that the last push to the repository was on 2026-10-15 while the most recent tagged release is v3.6.2 from 2025-10-23.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. wiresock/ndisapi on GitHub