Alexa device not found via nmap in WSL2

I'm running Windows 11 Home (21H2, build 22000.434) with WSL2 Ubuntu 20.04.

On my Windows local machine (and local LAN), I run

sudo nmap -sn 192.168.1.0/24

The output of that command is:

Starting Nmap 7.92 ( ) at 2022-01-17 09:44 Central Standard Time
Nmap scan report for raspberryshake.attlocal.net (192.168.1.74)
Host is up (0.024s latency).
MAC Address: B8:27:EB:69:C6:C6 (Raspberry Pi Foundation)
Nmap scan report for amazon-7e9f85f5b.attlocal.net (192.168.1.237)
Host is up (0.40s latency).
MAC Address: 00:71:47:21:7B:1A (Amazon Technologies)
Nmap scan report for dsldevice.attlocal.net (192.168.1.254)
Host is up (0.010s latency).
MAC Address: 08:9B:B9:89:B2:82 (Nokia Solutions and Networks GmbH & KG)
Nmap scan report for host.docker.internal (192.168.1.243)
Host is up.
Nmap done: 256 IP addresses (4 hosts up) scanned in 4.82 seconds

Now, after entering WSL2/Ubuntu and running the same command, I get the following:

Starting Nmap 7.80 ( ) at 2022-01-17 09:42 CST
Nmap scan report for raspberryshake.attlocal.net (192.168.1.74)
Host is up (0.016s latency).
Nmap scan report for host.docker.internal (192.168.1.243)
Host is up (0.00060s latency).
Nmap scan report for dsldevice.attlocal.net (192.168.1.254)
Host is up (0.010s latency).
Nmap done: 256 IP addresses (3 hosts up) scanned in 12.26 seconds

Do you see the difference? In WSL2, the Amazon device is missing, and I don't know why. Why does the Alexa (or Amazon) device not register from the WSL side?

PS: Yes, I've looked at Why nmap sometimes does not show device name?, but that question/answer does not resolve my confusion.

2 Answers

Short answer:

From WSL2, you should be able to add any Alexa devices on the network into the scan via:

sudo nmap -sn -PE -PS443,4070 -PA80 -PP 192.168.1.0/24

Explanation:

It appears that the Echo devices don't show up on a default scan from WSL2 due to the Nmap host discovery process:

If no host discovery options are given, Nmap sends an ICMP echo request, a TCP SYN packet to port 443, a TCP ACK packet to port 80, and an ICMP timestamp request. (For IPv6, the ICMP timestamp request is omitted because it is not part of ICMPv6.) These defaults are equivalent to the -PE -PS443 -PA80 -PP options.

All of the required ports/services/protocols for it to be detected via Nmap are disabled on the Echo.

It shows up when scanned from Windows host because of the next qualifier:

The exceptions to this are the ARP (for IPv4) and Neighbor Discovery (for IPv6) scans which are used for any targets on a local ethernet network.

You can see this if you increase the debug level of Nmap under the Windows host:

sudo nmap -d 192.168.1.237

You should see, in the output, something like:

Host is up, received arp-response

On the flip side, arp discovery does not work in WSL2 because (a) arp is a link-layer protocol, and (b) you aren't on the same network. The WSL2 network interface is a virtual NIC provided by the Hyper-V subsystem. It's running NAT'd behind the Windows host.

So we need some way of detecting the Amazon device even though (a) it's on a different network, and (b) all of the ports it usually uses for detection are filtered.

First off, running sudo nmap -Pn 192.168.1.237 -p1-65535 should show you something like:

Host is up (0.0092s latency).
Not shown: 49146 filtered ports, 16385 closed ports
PORT STATE SERVICE
4070/tcp open tripe
4071/tcp open aibkup
55442/tcp open unknown
55443/tcp open unknown

Using the knowledge that port 4070/tcp is open, along with knowing the default discovery method from the Nmap book quoted above, we can add it together and get:

sudo nmap -sn -PE -PS443,4070 -PA80 -PP 192.168.1.0/24

which should get you a complete report, including the Alexa, from WSL2.

A new possibility that wasn't necessarily available at the time of the original question has been confirmed to work in this Reddit post.

At this time, it is currently in Preview/Experimental stage per Microsoft. To utilize it, you need to:

• Be on Windows 11 Professional or higher (needed for Hyper-V management)

• Install the Preview version of WSL from the Microsoft Store (WSL is not necessarily Preview, of course, but the version that you can install as an App is).

• Create a bridged, external Hyper-V network switch

• Configure bridged mode networking in WSL2 by creating or editing .wslconfig in your Windows (not Linux) profile folder with the following contents:

  [wsl2]
  networkingMode=bridged
  vmSwitch=my-switch

  ... replacing my-switch with the name of the switch created in Hyper-V.

• Exit all WSL sessions and then wsl --shutdown from PowerShell

• Restart

See this Github comment for the original info. Also, this blog post has some more details and good information on other scenarios. Finally, this Github comment has some details on handling VPNs in this type of configuration.