NDIS Intermediate Driver or WFP?

Using a WinPCAP for our VPN NAT component to sniff packets from the real adapter is currently not sufficient. The receive packet is still being delivered to NDIS and causes TCP reset issues and eventually firewall problems.

As such, I was asked to solve this problem. From what I’ve read, protocol drivers such as WinPCAP can only sniff packets. I need to create an NDIS intermediate driver to filter packets from the real adapter - copy it to the virtual adapter and drop it (dont pass it to NDIS). WDK has a sample code for NDIS intermediate driver - the PassThru sample.
Thomas Divine has also provided an extension of this code to filter packets based on specified IP address, which is basically what I need.

Questions… Am I in the correct path? Will NDIS5 PassThru NDIS Intermediate driver base code work in Vista and 7 or only in XP? I need something that works on XP, Vista, 7. There is a NDIS 6 Lightweight filter driver sample for NDIS 6 so does it mean I have to maintain separate filter drivers for Windows XP and Vista/7?

Should I use Windows Filtering Platform instead? Microsoft seems pushing on using WFP but WFP seems to only filter TCP packets(?). Although the firewall issue is not causing problems in UDP, I also want to filter UDP packets as well.

Any advice would be appreciated. Thanks!!!

> I need something that works on XP, Vista, 7.

Approach the problem from the perspective of building two implementations:
NT5 and NT6. You should really eschew trying to ‘live within’ what NT5 /
NDIS5 compatibility exists in NT6 in the flawed pursuit of a single driver
solution. It is not worth it, especially for a ‘new’ development. Build
the NT6 driver and then go back and contemplate how to make something work
on NT5. NT6 has the architectural and public DDI support to do what you
want in a rational and interoperable way. NT5 will be an exercise in
compromise so don’t let it drive your design.

On NT6 use WFP unless your packet processing requires you to deal with MAC
layer frames. Since you mention VPN and the only transport left is IP, I
presume you mean an IPv{4|6} VPN. So WFP will be just what you want.

On NT5 do what you have to do. That is probably an NDIS IM Filter Driver
since the choices are limited. Hooking into the NT5 TCPIP.SYS is too much
trouble, pain, and fragile. Which is why NDIS5 IM drivers exist for every
conceivable reason to perform packet processing on that platform.

But perhaps you could more concisely define what your packet processing
requirements are and we could perhaps give you more specific guidance.

Good Luck,
Dave Cattley

Thanks for the quick response and advice. Ok, so I need to maintain 2 code base for Windows XP and Vista/7.

For XP, I have no choice but to do NDIS5 IM driver (WDK PassThru sample and Thomas Divine’s PassThruEx sample). While for Vista and 7, WFP should be sufficient and more efficient that NDIS6 Lightweight Filter (WDK NDISLWF sample). NDIS5 IM driver (WDK PassThru sample) is not an option for Vista and 7 because of its performance issues, right?

The packet processing will just be simply based on IP address, not MAC address or ports. So I think WFP will suffice. All packets that PC2SubnetA sends to PC3SubnetB via PC1SubnetA should be filtered on the real adapter of PC1SubnetA to enable changing of NAT ports and IP address before sending to PC3SubnetB via virtual adapter tunnelled through the real adapter.

> Ok, so I need to maintain 2 code base for Windows XP and Vista/7.

In my experience you maintain a code-base for you application specific logic
in a form that is sufficiently multi-targeted (or polymorphic on NDIS_PACKET
/ NET_BUFFER, both of which are just chains of MDLs) and then have target
specific drivers that use that logic. But sure, if you want to write it
twice, that works too.

For XP, I have no choice but to do NDIS5 IM driver (WDK PassThru sample
and Thomas Divine’s PassThruEx sample).

I don’t think I said “no choice” but yeah, I think that is the only
practical choice.

While for Vista and 7, WFP should be sufficient and more efficient that
NDIS6 Lightweight Filter (WDK NDISLWF sample).

Efficient of your time. You have an IP datagram processing problem or a IP
packet processing problem or both. But you sure do not have a Etherent,
TokenRing (my new favorite dinosaur to work into network related posts to
displace ArcNET), WWAN, and the myriad other framing schemes that Windows
supports if you go for a MAC level interecept. It is not an easy thing to
pick a packet intercepted off of the Ethernet adapter and divert it into the
RASWAN (PPP) adapter. So to the extent you can avoid that bit of headache
and play entirely at the IP network (forwarder) layer, your task will be
much simpler.

NDIS5 IM driver (WDK PassThru sample) is not an option for Vista and 7
because of its performance issues, right?

Oh, it would probably work. And you would find that getting it to play
along in the NDIS6/NDIS5 IM driver ‘harness’ would generally be fine. Yes,
the perf drops but really it is wonkyness of the interop between LWFs and IM
drivers that NDIS6 so valiantly tries to achieve that just will drive one
nuts when it does not quite do what you wish it would. Example: When the
interface has to have a new LWF inserted, everything has to pause. Well,
for an NDIS5 IM driver that means it has to be unbound because it has no
idea what a pause is. So elements above your IM can get torn down (not
paused necessarily). But I digress.

The packet processing will just be simply based on IP address, not MAC
address or ports.

Except in NT5 where of course you will have to deal with IP packets in MAC
frames. And you will have to deal with IP to MAC address resolution before
sending them along on whatever the link is you choose. You are now going to
have to be an IP forwarder, perform fragmentation (potentially), ARP
resolution, all the good stuff.

Good luck,
Dave Cattley


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

>Lightweight filter driver sample for NDIS 6 so does it mean I have to maintain separate filter drivers

for Windows XP and Vista/7?

Better yes. The mere presence of NDIS5 IM in Vista+ causes perf loss.

Should I use Windows Filtering Platform instead?

It is above and inside TCP/IP, not below like IM or LWF are.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

Using WFP usermode API solved the TCP RST problem. Inbound packets with the specified range of NAT ports are now being intercepted in TCP/IP stack. VPN is now working with or without the built-in firewall enabled in Windows 7.

I need the same API in Windows XP. Is there a Packet Filtering API in Windows XP that supports filtering inbound packets based on TCP/UDP ports? I don’t need access to the payload, just ports.

> I need the same API in Windows XP. Is there a Packet Filtering API in Windows XP

No.

Re-implement the whole WFP stuff in an NDIS IM. No other ways.


Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

In our VPN system, WFP usermode application currently works together with WinPCAP to intercept packets. WinPCAP is being used to sniff/copy the actual “raw” ethernet packet while WFP usermode application is used to drop the packet.

I need to replace WinPCAP with a WFP Callout Driver. I would just like to confirm if my understanding is correct:

  1. WFP Callout Driver can be used to get the actual ethernet packet (or TCP/UDP payload ONLY?).
  2. WFP Win32 API can NOT be used to get the actual ethernet packet (or TCP/UDP payload ONLY?).

> 1. WFP Callout Driver can be used to get the actual ethernet packet (or
TCP/UDP payload ONLY?).

If you want to process Ethernet frames then use an NDIS Light Weight Filter
(LWF). If your problem is one of processing IP packets then use WFP.

  1. WFP Win32 API can NOT be used to get the actual ethernet packet (or
    TCP/UDP payload ONLY?).

That is correct. The Usermode API to WFP manipulates filters. If you need
to ‘inspect’ or ‘modify’ the flow it requires a callout driver.

Good Luck,
Dave Cattley


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

Done with WFP Callout Driver for Windows Vista and 7. Now I would like to start developing NDIS 5 Intermediate Driver for Windows XP while fixing some issues with the WFP.

I tried building and installing the PassThru sample from WDK 7600.16385.1 but OS is hanging after installation. Before system hang, a Windows Explorer popup window appears then a DrWatson Postmortem Debugger popup window appears. When I checked Windbg, PtUnload is called after DriverEntry.

After reboot, I checked the hidden devices in the Device Manager and the IM’s virtual miniport driver has a yellow mark with the following error: “This device is not working properly because Windows cannot load the drivers required for this device. (Code 31)”. I checked that passthru.sys is there in C:\WINDOWS\system32\drivers. I am testing on VirtualBox.

Why is the driver not being loaded? VirtualBox issue? WDK build version issue? PassThru sample issue?

Did you sign the driver? Enable test signing mode? Attach a debugger?

In my experience the PassThru driver works as advertised on XP through Win7
and beyond.

How are you installing it? (Shell Network UI or BindView?)

Did you analyze the Dr. Watson crash? This is unlikely to have been caused
by Passthru since it is running in kernel only. But perhaps you have some
collection of other ‘stuff’ installed on your system which is sensitive to
the NetCfg operations like binding an IM driver and that stuff crashed.

Good Luck,
Dave Cattley

I did not sign the driver nor test signing mode since I tested on Windows XP 32-bit. I just installed it using Network UI. I previously installed Network Monitor, OpenVPN, iTunes, UltraVNC, Java and our miniport adapter but I have removed all of them and the issue is still happens. But when I reverted to some old snapshot of the virtual machine, the issue did not happen. It must be one of those I previously installed. Thanks!

What value does DriverEntry return when it is called? What value does
AddDevice return? Are you using debug print statements in every failure
path?
joe

Done with WFP Callout Driver for Windows Vista and 7. Now I would like to
start developing NDIS 5 Intermediate Driver for Windows XP while fixing
some issues with the WFP.

I tried building and installing the PassThru sample from WDK 7600.16385.1
but OS is hanging after installation. Before system hang, a Windows
Explorer popup window appears then a DrWatson Postmortem Debugger popup
window appears. When I checked Windbg, PtUnload is called after
DriverEntry.

After reboot, I checked the hidden devices in the Device Manager and the
IM’s virtual miniport driver has a yellow mark with the following error:
“This device is not working properly because Windows cannot load the
drivers required for this device. (Code 31)”. I checked that passthru.sys
is there in C:\WINDOWS\system32\drivers. I am testing on VirtualBox.

Why is the driver not being loaded? VirtualBox issue? WDK build version
issue? PassThru sample issue?


NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer