[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.

[Vadim Smirnov]

Is it possible to drop limitation #3, so we can use any mac address.

Yes, sure, it is possible. I also wanted to make few more adjustments to this new driver. Will add it this to the list.

[Vadim Smirnov]

Always glad to help 🙂

[Vadim Smirnov]

You have not paid enough attention to my previous post mentioning locally administered MAC address requirement. You can read a little more on this here. In you case addr[0] = 0x74 and it does not meet the condition to be locally administered MAC address. You can use 0x72, 0x76, 0x7A or 0x7E instead.

[Vadim Smirnov]

OK, I have added NetworkAddress property. You can download the updated driver using the same link

Though please note that in this build assigning the network adapter hardware address has a few limitations:

1) It should not be multicast address (addr[0] & 0x01 == 0)
2) It should not be broadcast address (FF-FF-FF-FF-FF-FF)
3) It should be marked as assigned by the local administrator (addr[0] & 0x2 == 1)

Example of valid address is 06-01-02-03-04-05

[Vadim Smirnov]

I’ve created a quick NDIS 6.0 replacement for the original VirtNet driver. You can download it from here. Let me know how it worked for you…

[Vadim Smirnov]

I have devoted some time over the weekend to this issue, but I still don’t have a good idea what was changed by an update and how to fix this. It is definitely not about driver signing because that phase is passed fine. And setupapi.dev.log does not contain any helpful information:

>>>  [Device Install (DiInstallDevice) - ROOT\NET\0000]
>>>  Section start 2019/02/04 11:53:39.838
      cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
     ndv: Flags: 0x00000004
     dvi: {Plug and Play Service: Device Install for ROOT\NET\0000}
!    dvi:      Installing NULL driver!
     dvi:      {DIF_ALLOW_INSTALL} 11:53:39.858
     dvi:           Default installer: Enter 11:53:39.858
     dvi:           Default installer: Exit
     dvi:      {DIF_ALLOW_INSTALL - exit(0xe000020e)} 11:53:39.862
     dvi:      {DIF_REGISTER_COINSTALLERS} 11:53:39.862
     dvi:           Default installer: Enter 11:53:39.862
     dvi:           Default installer: Exit
     dvi:      {DIF_REGISTER_COINSTALLERS - exit(0x00000000)} 11:53:39.866
     dvi:      {DIF_INSTALLDEVICE} 11:53:39.866
     dvi:           Default installer: Enter 11:53:39.866
!    dvi:                Installing NULL driver!
     dvi:                Install Null Driver: Removing device sub-tree. 11:53:39.870
     dvi:                Install Null Driver: Removing device sub-tree completed. 11:53:39.874
     dvi:                Install Null Driver: Restarting device. 11:53:39.878
     dvi:                Install Null Driver: Restarting device completed. 11:53:39.882
     dvi:                Install Device: Configuring device class. 11:53:39.882
     dvi:                Install Device: Configuring device class completed. 11:53:39.882
     dvi:                Device Status: 0x01802401, Problem: 0x1c (0x00000000)
     dvi:                Install Device: Starting device 'ROOT\NET\0000'. 11:53:39.886
     dvi:                Install Device: Starting device completed. 11:53:39.894
     dvi:           Default installer: Exit
     dvi:      {DIF_INSTALLDEVICE - exit(0x00000000)} 11:53:39.898
     ump: {Plug and Play Service: Device Install exit(00000000)}
<<<  Section end 2019/02/04 11:53:39.910
<<<  [Exit status: SUCCESS]

>>>  [Delete Device - ROOT\NET\0000]
>>>  Section start 2019/02/04 11:59:51.125
      cmd: "C:\Windows\system32\mmc.exe" C:\Windows\system32\devmgmt.msc
     dvi: Query-and-Remove succeeded
<<<  Section end 2019/02/04 11:59:51.133
<<<  [Exit status: SUCCESS]

Mentioned Problem: 0x1c is CM_PROB_FAILED_INSTALL for which I could find anything helpful besides https://docs.microsoft.com/en-us/windows-hardware/drivers/install/cm-prob-failed-install

The only solution I can see so far would be creating a new NDIS 6 virtual network adapter driver…

[Vadim Smirnov]

Small update:

Signing VirtNet driver with EV certificate did not help, installation fails with the same error. So it looks that the problem is not related to driver signing and there is another reason for this. Right now it is difficult to say what has changed in 1809, may be Microsoft by chance or by purpose has dropped the support of the legacy versions of NDIS. I hope NDIS 6.0 version of VirtNet may help here…

[Vadim Smirnov]

I’ve installed and tested 1809 during the weekend and I confirm that the problem exists. Probably it is related to driver signing policy changes or another possibility is legacy NDIS versions support (for compatibility across all Windows versions VirtNet followed NDIS 3.0 specification). But no worries, I’ll prepare the new build when have some spare time over the next week.

[Author]

Posts