[Vadim Smirnov]

That depends of which installer you have downloaded. Two of them (MSI ones) install driver only (x64 or x86 depending on the platform), the third one contains more demo binaries and includes ndisapi.dll.

The source code for ndisapi can be found here. You can use as a static or dynamic library (or even .net class library) depending on your requirements.

[Vadim Smirnov]

Support of NDIS 3.0 was removed from Windows 10 starting 1809, so the NDIS 3.0 of VirtNet can’t be used anymore. You can check this thread for the details and temporary NDIS 6.0 VirtNet driver replacement:

VirtNet does not install on Windows 10 version 1809 x64

However, this problem is not related to Windows Packet Filter, so if you have experienced any problems about it then could please provide the details.

[Vadim Smirnov]

No, in fact NDIS 6.x LWF is a direct replacement for NDIS 5.1 IM drivers.

[Vadim Smirnov]

In two words, NDIS IM is a NDIS 5.1 driver (though, it can be used in Vista, but in fact this is a compatibility mode) while LWF is NDIS 6.x and has a native support.

[Vadim Smirnov]

Yes, sure!

[Vadim Smirnov]

P.S. I was a little bit confused about your claim regarding code signing certificates costs, but yes, if you tried to order directly from the main page then it is a kind of expensive. However, if you try this link then you might be pleasantly surprised. 🙂

[Vadim Smirnov]

Well, yes, this is an option. However, it won’t protect if any other applications using standard winpkfilter build are running.

By the way we can sign your custom build with our code-signing certificate. Some of the customers prefer this option not only because of certificate costs but mostly because a relatively complex driver signing process.

[Vadim Smirnov]

Hmm, interesting question and I’m afraid I don’t have a quick answer. Inspecting all active processes for the open driver handle does not look a good idea. However, I think such functionality could be added to the driver itself, an example store the driver opened handles counter in the registry.

Still, I’m not sure that this type of functionality is really needed though, normally you should tie your NAT application with custom driver build. In this situation your NAT application always knows if it uses the driver or not while no other application are aware about the custom driver build therefore can’t use the driver.

[Vadim Smirnov]

Yes, you are right, it is bug. You should add UDP checksum recalculation in two places:

//DNS hook
//If we receive DNS packet on the NAT client adapter then we redirect it 
//to this system configured DNS server
if((pDlg->m_DNSIp.S_un.S_addr != INADDR_ANY) && (pDlg->m_DNSIp.S_un.S_addr != INADDR_NONE))
{
    if ((hAdapters[dwIndex]->m_NATState == CLIENT)&&
    (PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_RECEIVE))
    {
        if (ntohs(pUdpHeader->th_dport) == 53/*DNS port*/)
        {
            // Save the DNS IP used by the NAT client system
            hAdapters[dwIndex]->m_LocalDNS.S_un.S_addr = ntohl(pIpHeader->ip_dst.S_un.S_addr);
            
            pIpHeader->ip_dst.S_un.S_addr = pDlg->m_DNSIp.S_un.S_addr;
        
            if(bForceRouting) 
            {
                bNeedToBeRouted = pDlg->IsNeedToForceRouting(pEthHeader->h_dest, pIpHeader->ip_dst.S_un.S_addr, pProviderCard->m_Index);
            }

            RecalculateUDPChecksum(&PacketBuffer);
            RecalculateIPChecksum (&PacketBuffer);
        }
    }

    // DNS reply came, substitute source IP back to the original DNS address
    if ((hAdapters[dwIndex]->m_NATState == CLIENT)&&
        (PacketBuffer.m_dwDeviceFlags == PACKET_FLAG_ON_SEND))
    {
        if (ntohs(pUdpHeader->th_sport) == 53/*DNS port*/)
        {
            pIpHeader->ip_src.S_un.S_addr = htonl(hAdapters[dwIndex]->m_LocalDNS.S_un.S_addr);
            RecalculateUDPChecksum(&PacketBuffer);
            RecalculateIPChecksum (&PacketBuffer);
        }
    }
}

Internet Gateway is a very old sample and I have a newer NAT library implementation (not available for public though) where surprisingly this bug was already fixed.

[Vadim Smirnov]

Although sendto() can be called on unbound socket according MSDN “If the socket is unbound, unique values are assigned to the local association by the system, and the socket is then marked as bound”. So, I suspect that this is equivalent to calling bind explicitly. However, worth to test to ensure.

[Vadim Smirnov]

You can use GetExtendedUdpTable to find the dwLocalAddr:dwLocalPort to dwOwningPid association and then if necessary call GetOwnerModuleFromUdpEntry with TCPIP_OWNER_MODULE_INFO_BASIC to obtain pModuleName and pModulePath.

[Vadim Smirnov]

Installers were fixed for Windows 8.1

[Vadim Smirnov]

Thanks for reporting this. Difficult to say before testing but probably it is somehow related to detected Windows version…

Update: from what I can see installer installs the wrong driver version on Windows 8.1. Instead installing Windows 8 driver it installs Windows 10 driver. This behavior is caused by that fact that both Windows 8.1 and Windows 10 have VersionNT value set to 603 and this requires a sort of workaround:

https://support.microsoft.com/en-ie/help/3202260/versionnt-value-for-windows-10-and-windows-server-2016

[Vadim Smirnov]

For C# (and other .NET languages) it is recommended to use .NET C++/CLI class library (source code available on GitHub).

The TestDotNet project (more advanced version of PassThru) demonstrates the usage of the above-mentioned class library.

[Vadim Smirnov]

WinpkFilter 3.2.18.1 update:

• Fixed Receive Segment Coalescing (RSC) task offload issue for wireless WDI drivers (could cause packet loss and performance degradation for some network interfaces)
• Driver signature updated (could cause installation problems on Enterprise and Server editions)

If you are eligible for a free update, please send the following details to [email protected] tо receive an update instruction:

Your order ID.
An approximate date of purchasing.

[Author]

Posts