NMap iflist returns WINDEVICE <None> for a Virtual Wireguard Interface

[TomisderMeister]

Hello everyone, I faced a problem regarding a missing/inaccessible adapter with Wireshark/Scapy created by Wireguard. nmap --iflist returning: eth0 is the Virtual Adapter from Wireguard. The adapter working correctly, but I am unable to sniff data with npcap/scapy/Wirteshark. NMap -> 7.80 Scapy -> 2.4.3 Wireshark -> 3.2.4 Wireguard -> 0.1.0 NPcap -> 0.9991

Diag Report: DiagReport-20200524-155041.txt

I tried mutliple releases and the bug is reproducable on a second device. I would be really glad if you could help regarding this problem.

[guyharris]

So the only occurrences of "WireGuard" in the Diag Report are in:

*************************************************
Network Adapter(s) Info:
*************************************************

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
Ethernet                  Realtek PCIe GbE Family Controller           14 Up           50-46-5D-8D-83-71         1 Gbps
TobiTunnel                WireGuard Tunnel                              7 Up                                   100 Gbps

Caption         : [00000002] Realtek PCIe GbE Family Controller
GUID            : {98D2E49D-710A-48FF-ABDC-89BA36048B9F} = eth1
Index           : 2
InterfaceIndex  : 14
Manufacturer    : Realtek
NetConnectionID : Ethernet
PNPDeviceID     : PCI\VEN_10EC&DEV_8168&SUBSYS_85051043&REV_09\4&21A1C3AE&0&00E5

Caption         : [00000012] Wintun Userspace Tunnel
GUID            : {3B758425-0C12-5B9B-708D-C6F0A39B222C}
Index           : 12
InterfaceIndex  : 7
Manufacturer    : WireGuard LLC
NetConnectionID : TobiTunnel
PNPDeviceID     : ROOT\NET\0000

Can you try to capture with TShark (tshark.exe should be in the same directory as Wireshark.exe), passing it the command-line argument -i \Device\NPF_{3B758425-0C12-5B9B-708D-C6F0A39B222C} ?

What does the command ipconfig/all print?

[per-allansson]

I have the same problem, attached info.

C:\Program Files\Wireshark>tshark.exe -i \Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Capturing on '\Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}'
tshark: The capture session could not be initiated on interface '\Device\NPF_{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}' (No such device exists).
Please check that you have the proper interface or pipe specified.

DiagReport-20200715-102840.txt ipconfig.txt

[guyharris]

The device in question appears in the DiagReport:

Caption             : [00000000] Wintun Userspace Tunnel
GUID                : {3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Index               : 0
InterfaceIndex      : 6
Manufacturer        : WireGuard LLC
MACAddress          : 
Speed               : 100000000000
NetConnectionID     : AppGateSDP
NetConnectionStatus : 2
PNPDeviceID         : ROOT\NET\0000
ServiceName         : wintun
AdapterType         : 

but does not appear in the ipconfig/all output.

The Hyper-V virtual adapter appears in both:

Caption             : [00000003] Hyper-V Virtual Ethernet Adapter
GUID                : {1ED37246-AA38-47E3-9D32-8D89AD4D054E}
Index               : 3
InterfaceIndex      : 29
Manufacturer        : Microsoft
MACAddress          : 00:15:5D:BB:38:A1
Speed               : 10000000000
NetConnectionID     : vEthernet (Default Switch)
NetConnectionStatus : 2
PNPDeviceID         : ROOT\VMS_MP\0000
ServiceName         : VMSNPXYMP
AdapterType         : Ethernet 802.3

and

Ethernet adapter vEthernet (Default Switch):

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : Hyper-V Virtual Ethernet Adapter
   Physical Address. . . . . . . . . : 00-15-5D-BB-38-A1
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::7547:886:90f6:53c6%29(Preferred) 
   IPv4 Address. . . . . . . . . . . : 172.19.128.1(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.240.0
   Default Gateway . . . . . . . . . : 
   DHCPv6 IAID . . . . . . . . . . . : 486544733
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-26-62-76-D9-90-1B-0E-4E-3B-EF
   DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                       fec0:0:0:ffff::2%1
                                       fec0:0:0:ffff::3%1
   NetBIOS over Tcpip. . . . . . . . : Enabled

[per-allansson]

Well I change the description in my code when setting up the device, so the device you are looking for is the one with in diag txt "NetConnectionID : AppGateSDP" - which matches the "Unknown adapter AppGateSDP" in ipconfig. Apart from that description change the setup code is the same that the normal Wireguard client uses.

[guyharris]

Well I change the description in my code when setting up the device, so the device you are looking for is the one with in diag txt "NetConnectionID : AppGateSDP"

Yes. that's the entry I mentioned.

• which matches the "Unknown adapter AppGateSDP" in ipconfig. Apart from that description change the setup code is the same that the normal Wireguard client uses.

OK, so that's

Unknown adapter AppGateSDP:

   Connection-specific DNS Suffix  . : 
   Description . . . . . . . . . . . : AppGate SDP VPN Tunnel
   Physical Address. . . . . . . . . : 
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd00:ffff:b:20::714(Preferred) 
   IPv4 Address. . . . . . . . . . . : 192.168.100.172(Preferred) 
   Subnet Mask . . . . . . . . . . . : 255.255.255.255
   Default Gateway . . . . . . . . . : 
   DNS Servers . . . . . . . . . . . : 172.17.40.65
                                       172.17.40.66
                                       172.17.40.9
  NetBIOS over Tcpip. . . . . . . . : Enabled

So what's the difference between the two?

[per-allansson]

Sorry don't follow - difference between the two what?

[guyharris]

The difference between the AppGate SDP VPN Tunnel/Wintun Userspace Tunnel device and the Hyper-V Virtual Ethernet Adapter device.

If capturing on the latter doesn't work, there may not be a difference. If capturing on the latter does work, then the first one gets ERROR_BAD_UNIT back from an attempt to open it, the second one doesn't, so why?

That means that either:

• PacketFindAdInfo() returns NULL for the device;
• the Flags field of what PacketFindAdInfo() found has a bogus type (either not an NPF device or has the "not exported" flag set.

"Not exported" appears to happen only for FireWire devices, which the device almost certainly isn't. Perhaps there is no entry for it in the Registry, or the open attempt on it failed for some reason while constructing the list of devices?

[per-allansson]

Ah. Capturing on the the Hyper-V Virtual Ethernet Adapter is fine, at least wireshark/tshark/etc finds and connects fine to it.

Yeah, so maybe there is something funny going on in how the Wintun device gets registered / set up - that's more than I know - I only reuse the WG code for setting it up.

[per-allansson]

These are the logs for testing directly with the official WireGuard client - I attached the WG profile I used as well (dummy keys ofc) - you could test this by yourself by just installing the WireGuard client and giving it that profile and activate it - there is no need for an actual WG server - the Wintun device gets set up anyway.

You can find the WG client here: https://www.wireguard.com/install/

tshark.txt DiagReport-20200715-110019.txt ipconfig.txt W10.conf.txt

[timg11]

I have a similar issue on Windows 10.
nmap --iflistand Wireshark using npcap 0.9995 are unable to detect the Wireguard interface created by Mozilla VPN. I posted details on Stackoverflow

DiagReport-20200801-093901.txt

[per-allansson]

So I started to see if I could figure out something more and found the iflist example in the npcap source code - it also fails to list the Wintun Virtual NIC as expected, but together with a debug version of packet.lib/dll I could at least get out some more logs that might shed some more light for those more familiar with the inner workings of npcap.

So the diagreport on this machine shows the Wintun NIC nic:

Caption             : [00000013] Wintun Userspace Tunnel
GUID                : {3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
Index               : 13
InterfaceIndex      : 9
Manufacturer        : WireGuard LLC
MACAddress          : 
Speed               : 100000000000
NetConnectionID     : AppgateSDP
NetConnectionStatus : 2
PNPDeviceID         : ROOT\NET\0000
ServiceName         : wintun
AdapterType         : 

while the Packet.log shows this when it tries to grab hold of the device npcap path thing:

[00005D88] 2020-09-08 18:03:29     14) Successfully retrieved info for adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}, trying to add it to the global list...
[00005D88] 2020-09-08 18:03:29 --> PacketAddAdapterNPF
[00005D88] 2020-09-08 18:03:29     Trying to add adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
[00005D88] 2020-09-08 18:03:29     Trying to open the NPF adapter and see if it's available...
[00005D88] 2020-09-08 18:03:29 --> PacketOpenAdapterNPF
[00005D88] 2020-09-08 18:03:29     Trying to open adapter \Device\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}
[00005D88] 2020-09-08 18:03:29 --> PacketStartService
[00005D88] 2020-09-08 18:03:29     PacketStartService: Already tried once.
[00005D88] 2020-09-08 18:03:29 <-- PacketStartService
[00005D88] 2020-09-08 18:03:29 --> NpcapIsAdminOnlyMode
[00005D88] 2020-09-08 18:03:29 <-- NpcapIsAdminOnlyMode
[00005D88] 2020-09-08 18:03:29     SymbolicLinkA = \\.\Global\NPCAP\{3F2E7B29-EE1D-4BAF-9572-5546CBED90F1}, lpAdapter->hFile = ffffffff
[00005D88] 2020-09-08 18:03:29     PacketOpenAdapterNPF: CreateFile failed, LastError= 8034002b
[00005D88] 2020-09-08 18:03:29 <-- PacketOpenAdapterNPF
[00005D88] 2020-09-08 18:03:29     NPF Adapter not available, do not add it to the global list
[00005D88] 2020-09-08 18:03:29 <-- PacketAddAdapterNPF
[00005D88] 2020-09-08 18:03:29 --> IsFireWire
[00005D88] 2020-09-08 18:03:29 <-- IsFireWire

The adapter properties for the Wintun adapter does show the "Npcap Packet Driver (NPCAP)" and "Npcap Packet Driver (NPCAP) (Wi-Fi)" as enabled.

Using npcap 0.9997 - and the debug build of packet.lib/dll built from latest git sources when running the iflist.exe

[fghzxm]

Is there any easy way we can talk to the WireGuard people about this problem? They don't use GitHub issues, and the WireGuard mailing list doesn't look particularly hospitable.

[zx2c4]

Hi, Wintun developer here. I noticed the same issue a few weeks ago actually. I assume that npcap only binds to ethernet interfaces and doesn't know about layer 3 interfaces on Windows. Wintun uses these specification in its inf:

Characteristics = 0x1 ; NCF_VIRTUAL
*IfType = 53 ; IF_TYPE_PROP_VIRTUAL
*MediaType = 19 ; NdisMediumIP
*PhysicalMediaType = 0 ; NdisPhysicalMediumUnspecified

I assume that npcap doesn't know about either IF_TYPE_PROP_VIRTUAL or NdisMediumIP or both.

Looking at npcap's inf, we see this:

HKR, Ndi\Interfaces,UpperRange, , noupper
HKR, Ndi\Interfaces,LowerRange, , "ndis5,ndis4"
HKR, Ndi\Interfaces, FilterMediaTypes,,"ethernet, fddi, wan, ppip, wlan, bluetooth, ndis5, vwifi, flpp4, flpp6, vchannel, nolower"

This suggests that it's left out whatever is needed to match on Wintun. I don't know if NdisMediumIP corresponds to adding , ip to that list, or some other string.

[stvitaly]

Now when WinTun is a part of OpenVPN 2.5 installation this became much more important to support WinTun in npcap. Is there any intention to change something here or in WinTun in the near future, so this pair would work?

[zx2c4]

to change something here or in WinTun in the near future, so this pair would work

This appears to be a npcap issue, rather than a Wintun one.

[stvitaly]

I have another virtual adapter on the system with the below properties in the .inf:

Characteristics = 0x1 ; NCF_VIRTUAL (0x1) ; NCF_NOT_USER_REMOVEABLE (0x20); NCF_HIDDEN (0x8); NCF_HAS_UI (0x80) IfType = 0x6 ; IF_TYPE_ETHERNET_CSMACD MediaType = 0x0 ; NdisMedium802_3 *PhysicalMediaType = 14 ; NdisPhysicalMedium802_3

Which is detected just fine. If the problem was with filtering of MediaType as you suggest above, I suppose it was excluded as well. So, IfType seems to be more relevant. BTW as I said this interface is virtual as well, but it still present itself as ethernet one and I can see MAC in ipconfig and captures on it. Is this specific to WinTun to omit any layer2 detail?

[zx2c4]

NCF_VIRTUAL != IF_TYPE_PROP_VIRTUAL. That adapter is Ethernet+802.3, so of course it's covered by npcap.

The issue with wintun concerns IF_TYPE_PROP_VIRTUAL+NdisMediumIP.

[stvitaly]

Bumping. @fghzxm I would really appreciate if you could take a look. You have a wintun developer in the thread here (@zx2c4) as you asked.

[zx2c4]

the WireGuard mailing list doesn't look particularly hospitable.

@fghzxm It's actually a pretty hospitable place, so if you'd like to discuss there instead of here, that's fine too.

Either way, I remain at your disposal for helping to fix this.

[stvitaly]

the WireGuard mailing list doesn't look particularly hospitable.

@fghzxm It's actually a pretty hospitable place, so if you'd like to discuss there instead of here, that's fine too.

Either way, I remain at your disposal for helping to fix this.

@zx2c4 I have tried to join it twice through wintun site, didn't get any reply. I got a message that joining should be approved by list admin, maybe your admin stopped to approve people joining.

[zx2c4]

I don't see anything from you, in the spam box or otherwise.

[dovholuknf]

@zx2c4 I had that same issue recently and you fixed it for me somehow so that i was subbed to the mailing list. I'm following this thread with interest as we use wintun as well

[fyodor]

Thanks folks. I was talking to @dmiller-nmap about this issue and he noted that Npcap currently doesn't bind to NdisMediumIP virtual adapters. We specifically check for a set of known values when a binding request comes in, and reject it if it's not known. NdisMediumIP is not in the list. So it is possible that all we need to do is add this to the list (or even remove the list checking). It may not really matter what the value is, since we don't create layer-2 headers within the driver anyway. As long as we can map the value to something that a user can understand via Packet.dll -> libpcap, we should probably allow the bind to continue. Of course, once we allow the binding, it's possible there's something we've overlooked and it ends up interfering with the connection.

So we will probably make this new change for the next release and then hopefully you folks who have experienced the issue can test whether this resolves it. Or maybe we can test with Wireguard/Wintun ourselves. The next release will probably be sometime in May since we're currently in the middle of WHQL (Windows Hardware Qualification Labs) certification process which involves setting up a bunch of new hardware, virtual machines, testing, etc. We're hoping to make a new release after that.

[dovholuknf]

I see npcap 1.31 was released, i see the commit was pushed but I don't quite know how to verify if this fix is in 1.31 or not.

So we will probably make this new change for the next release and then hopefully you folks who have experienced the issue can test whether this resolves it.

I am happy to try to test this in some way. Is there a preferred mechanism you'd like to test? When I run:

nmap -v -A 100.64.0.0/10
Starting Nmap 7.90 ( https://nmap.org ) at 2021-06-08 15:50 Eastern Daylight Time
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating NSE at 15:50
Completed NSE at 15:50, 0.00s elapsed
Initiating ARP Ping Scan at 15:50
dnet: Failed to open device eth1
QUITTING!

I also tried to use a hostname which resolves for me that is assigned to this adapter:

nslookup mattermost.openziti.org
Server:  UnKnown
Address:  100.64.0.1

Name:    mattermost.openziti.org
Address:  100.64.2.46

C:\Program Files\Npcap>nmap -v -A mattermost.openziti.org
Starting Nmap 7.90 ( https://nmap.org ) at 2021-06-08 15:52 Eastern Daylight Time
NSE: Loaded 153 scripts for scanning.
NSE: Script Pre-scanning.
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
Initiating NSE at 15:52
Completed NSE at 15:52, 0.00s elapsed
pcap_activate(eth1) FAILED: No such device exists.
my_pcap_open_live(eth1, 50, 1, 25) failed three times.

If you can help me with the proper command to use to test - I'm happy to try it out

[dmiller-nmap]

@dovholuknf Thanks for offering to test. This change did not make it into 1.31, so we will have to wait for the next release to test it.

[4-FLOSS-Free-Libre-Open-Source-Software]

Seems fixed now in latest :)

Npcap 1.40 • Npcap driver no longer excludes adapters based on media type, which may allow capture on some devices that were previously unavailable.

[dovholuknf]

I dl'ed the 1.4 installer yesterday to test it out but it failed to install. I see it's no longer on the download page. I'll be happy to test it out once I can get my hands on it :) and now i see you filed https://github.com/nmap/npcap/issues/513 :)

[fyodor]

1.50 is out now at https://npcap.org and hopefully resolves the issue. Please let us know how it goes!

-Gordon

[fghzxm]

@fyodor Thanks for your work on this issue, and my apologies for my previous judgmental comment.

However, it seems like with the newest version of npcap Wireshark does not correctly identify the packets inside Wintun as IP, instead decoding them as Ethernet. Is it a bug in npcap, Wireshark, or one related to the Wintun project?

[guyharris]

However, it seems like with the newest version of npcap Wireshark does not correctly identify the packets inside Wintun as IP

The current version of Npcap doesn't correctly identify NdisMediumIP, which is what the Wintun device provides as its link-layer type, as DLT_RAW, which is the pcap (libpcap, WinPcap, Npcap) way of saying "the packets begin with an IPv4 or IPv6 header...

...and that's the fault of the libpcap code, not of the Npcap code that's combined with the libpcap code to make Npcap, so please file a bug on the libpcap issues list, not on the Npcap issues list.

Wireshark trusts pcap (libpcap/WinPcap/Npcap) to provide the right link-layer type, and libpcap defaults to DLT_EN10MB (meaning Ethernet - the "10MB" is a historical artifact, dating back to the days where there were the Xerox 3Mb experimental Ethernet and the DEC/Intel/Xerox 10Mb standard Ethernet, with all subsequent versions of Ethernet having the same link-layer header) for Windows link-layer types it doesn't understand, so it tells Wireshark that it's Ethernet.

What Wireshark is doing wrong is not reporting the warning that Npcap is returning for that case, and thus not telling you that there's a bug that needs to be reported. That's a separate bug, which I'll work on.

[guyharris]

@fghzxm's fix doesn't compile with VS 2015, probably because the Windows SDK that comes with VS 2015 is too old to have NdisMediumIP.

What's the oldest version of VS that can be used to build Npcap? If it's newer than VS 2015, I'll remove them from the AppVeyor CI builds and note that libpcap requires that version or later.

[guyharris]

What Wireshark is doing wrong is not reporting the warning that Npcap is returning for that case, and thus not telling you that there's a bug that needs to be reported. That's a separate bug, which I'll work on.

I've checked that in, although, on most platforms, the capture mechanism providing an unknown link-layer type should probably be a fatal error. Linux is the only platform where it's not, because we can do the capture in "cooked mode" with a link type of DLT_LINUX_SLL as a workaround, so, for that, we can issue a warning (so the user knows they're not getting the link-layer header).

[dmiller-nmap]

@guyharris I'm not sure what the oldest VS that can be used to build Npcap is. We do use VS 2019 currently. Our primary intent is to be able to build it ourselves, so we don't have any particular requirement to support older build environments. Of course we want to make it easy for others to link with and use Npcap, but the intent is that they would use our builds under license.

[guyharris]

OK, I went with doing a check in CMake, so it should still build with pre-8.1 Windows SDKs, albeit without NdisMediumIP support. You can grab change 74be794fe7b3540999149f976e4a829289ad43ef from the main branch or ef0e7b15fe871d79e678a3482b0c5a02171dacfe from the libpcap-1.10 branch; we recently released 1.10.1, so it probably won't show up in a release soon.

[dovholuknf]

@dmiller-nmap any expectation setting you can do for when this might be able to incorporated and tested? I'm eager to be able to capture wintun traffic. :) I gave a shot at building locally but hit some compilation bumps and didn't end up getting it working.

Thanks for pushing this issue along everyone !

[per-allansson]

Putting a comment here since searches about Wireshark + Wintun support eventually end up in this ticket - to get Wireshark working it needs to pull in the fixed npcap build (which it does now I think), but also an updated build of libpcap - which it pulls from vcpkg - and which does not have a recent build of libpcap at the moment. So if anyone want this to happen sooner than later, please make a PR to https://github.com/microsoft/vcpkg to update libpcap to 1.10 - I might try do it when I have caught up on 100 other things that have more prio - but that is likely to qualify as "later".

[DentonGentry]

Confirmed that wireshark 3.5.0rc0 includes npcap 1.5.0 and sees the wintun device. There is a popup message "Unknown NdisMedium value 19, defaulting to DLT_EN10MB", and it is trying to decode the IP header bytes as an Ethernet header. (from https://github.com/tailscale/tailscale/issues/1660)

I think we need the NdisMediumIP handling added in https://github.com/the-tcpdump-group/libpcap/blob/728f4339fac6bddb0350e69cb62a862b917ad3e3/pcap-npf.c#L1112 which should be included in libpcap 1.10.2, but 1.10.2 isn't quite out yet.

[dmiller-nmap]

Thanks everyone for commenting. We will be using the latest from the head of upstream's libpcap-1.10 branch to ensure this change is incorporated in the next release, even if libpcap 1.10.2 is not yet released.

[kaplun]

Hi @DentonGentry , @dmiller-nmap! Is there somewhere an unofficial build of WireShark built as you describe, that could be used in order to support Wintun, while waiting for official releases?

[per-allansson]

A very easy workaround is to capture the packets with Wireshark, save them as normal pcap (not pcapng) file, and then change the pcap file header so it says the link format is Raw IP (0x65) and not Ethernet (0x01). Simple python script for this is:

import sys

with open(sys.argv[1], "r+b") as fh:
    fh.seek(20)
    fh.write(bytes([0x65]))

[per-allansson]

Thank you @dmiller-nmap, looks good now when capturing from Wireshark

[dmiller-nmap]

Fixed in Npcap 1.55 release.