Open jeffbrl opened 1 year ago
This isn't specific to Tailscale. I'm having this exact same issue when connected to an OpenVPN connection.
I tried using the --unprivileged parameter, but didn't work. I am not getting an error, but nmap isn't even getting a ping response. When I ping the vpn device ip using command line, it responds fine.
Pinging 10.129.102.198 with 32 bytes of data: Reply from 10.129.102.198: bytes=32 time=52ms TTL=63 Reply from 10.129.102.198: bytes=32 time=52ms TTL=63
Nmap: Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn Nmap done: 1 IP address (0 hosts up) scanned in 2.20 seconds
Same problem with ProtonVPN on. If ProtonVPN off - nmap works ok.
-e <interface>
Use specified interface
I tried adding "-e unk1" and it did not work differently. This is a new error as of nmap 7.94, 7.93 worked. I'm using OpenVPN 2.6.8 (has not changed since using nmap 7.93).
Command line: nmap -sn -e unk1 192.168.24.* Complete error message: Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-07 12:33 Central Standard Time Only ethernet devices can be used for raw scans on Windows, and "unk1" is not an ethernet device. Use the --unprivileged option for this scan. QUITTING!
Adding --unprivileged resulted in unfinished scan.
Pertinent portions of "nmap -iflist" output: Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-07 12:43 Central Standard Time ****INTERFACES**** unk1 (unk1) 10.0.24.2/24 other up 1500 unk1 \Device\NPF{79FDD721-7A4D-4F62-8777-E875A9358906} unk1 \Device\NPF{79FDD721-7A4D-4F62-8777-E875A9358906}
**ROUTES** 192.168.24.0/24 unk1 25 10.0.24.1 224.0.0.0/4 unk1 281 fe80::4d59:7dfb:7b37:f3cd/128 unk1 281 fe80::/64 unk1 281 ff00::/8 unk1 281
Same problem with iVPN.
I think that's because windows change the interface and MTU when connect to a VPN ? Same problem when connect VPN with WireGuard and Mullvad VPN which also the root network issue in WSL1 or 2
I also am getting this error message with PIA. Not sure why. Don't know if it's a windows 10 issue or new nmap version issue? Works great without VPN. Clearly it's having issue with the new VPN virtual adapter and doesn't like something.
Edit:
I misunderstood and thought this disables npcap on a specific interface (i.e. VPN). Turns out it uninstalls npcap system-wide and nmap falls back to full TCP connect scan mode (-sT
) without warning, which defeats the purpose of the fix.
Until further solutions are found, either you have to use the inefficient -sT
switch or reinstall Windows and pray it won't break soon.
Found a solution that involves uninstalling npcap driver for the VPN adapter (https://github.com/nmap/npcap/issues/549#issuecomment-1207505550), summary:
1. Open the Network Connections panel (
ncpa.cpl
)2. Double-click on the VPN network interface that you are using to open its properties page
3. Uninstall Npcap driver from the list if it exists, (if it doesn't then you are out of luck :/)
Use the -sT -Pn with your VPN (I have tried this and it works with WireGuard and OpenVPN)
-sT: This flag is used to perform a TCP connect scan1. This type of scan creates a full TCP connection with the host, completing the full TCP handshake2. It is considered more accurate than a SYN scan but is slower and generates more network traffic2. -Pn: This flag is used to disable host discovery1. When this option is used, nmap assumes the target hosts are online and will not attempt to ping them before scanning1. This can be useful if a host blocks ICMP ping requests or is otherwise unreachable by conventional discovery methods, but still has open ports.
Don't thank me, thank GPT-4 :-)
Use the -sT -Pn with your VPN (I have tried this and it works with WireGuard and OpenVPN)
-sT: This flag is used to perform a TCP connect scan1. This type of scan creates a full TCP connection with the host, completing the full TCP handshake2. It is considered more accurate than a SYN scan but is slower and generates more network traffic2. -Pn: This flag is used to disable host discovery1. When this option is used, nmap assumes the target hosts are online and will not attempt to ping them before scanning1. This can be useful if a host blocks ICMP ping requests or is otherwise unreachable by conventional discovery methods, but still has open ports.
Don't thank me, thank GPT-4 :-)
It works for me. I've used CyberHostVPN.
Same problem with ProtonVPN on. If ProtonVPN off - nmap works ok.
Same problem with SoftEther vpn client
I tried adding "-e unk1" and it did not work differently. This is a new error as of nmap 7.94, 7.93 worked. I'm using OpenVPN 2.6.8 (has not changed since using nmap 7.93).
Command line: nmap -sn -e unk1 192.168.24.* Complete error message: Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-07 12:33 Central Standard Time Only ethernet devices can be used for raw scans on Windows, and "unk1" is not an ethernet device. Use the --unprivileged option for this scan. QUITTING!
Adding --unprivileged resulted in unfinished scan.
Pertinent portions of "nmap -iflist" output: Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-07 12:43 Central Standard Time INTERFACES unk1 (unk1) 10.0.24.2/24 other up 1500 unk1 \Device\NPF{79FDD721-7A4D-4F62-8777-E875A9358906} unk1 \Device\NPF{79FDD721-7A4D-4F62-8777-E875A9358906}
ROUTES 192.168.24.0/24 unk1 25 10.0.24.1 224.0.0.0/4 unk1 281 fe80::4d59:7dfb:7b37:f3cd/128 unk1 281 fe80::/64 unk1 281 ff00::/8 unk1 281
It defines the interface to be used.
nmap -sn -e eth0 192.168.24.*
Either you can define an network interface using the -e flag: nmap -sn -e eth0
[-sT: This flag is used to perform a TCP connect scan1. This type of scan creates a full TCP connection with the host, completing the full TCP handshake2. It is considered more accurate than a SYN scan but is slower and generates more network traffic2. -Pn: This flag is used to disable host discovery1. When this option is used, nmap assumes the target hosts are online and will not attempt to ping them before scanning1.]
Describe the bug Executing nmap on fairly stock Windows 10 machine with tailscale VPN client installed results in nmap error about raw sockets.
To Reproduce
With tailscale 1.28.1 VPN client installed, execute nmap.
Expected behavior nmap should scan the specified IPv4 prefix without erroring out.
Version info (please complete the following information):
nmap --version
:C:\Users\jeffl>
C:\Users\jeffl>nmap --iflist Starting Nmap 7.94 ( https://nmap.org ) at 2023-09-21 20:05 Eastern Daylight Time ****INTERFACES**** DEV (SHORT) IP/MASK TYPE UP MTU MAC unk0 (unk0) fd7a:115c:a1e0:ab12:4843:cd96:6262:1678/128 other up 1280 unk0 (unk0) fe80::d8ff:5060:f230:9168/64 other up 1280 unk0 (unk0) 100.98.22.120/32 other up 1280 eth0 (eth0) 2600:4040:4024:5500::1c77/128 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) 2600:4040:4024:5500:5645:ac9e:6d1e:769c/64 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fd6c:3ece:8a8d:0:d3cf:8fdb:b890:8df7/64 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fdab::3676:8756:35a2:13e1/64 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fde7:2e0f:a545:85f1:78ea:5d06:7fa2:323/64 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) 2600:4040:4024:5500:6157:85a7:389b:4de7/128 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fd6c:3ece:8a8d:0:6157:85a7:389b:4de7/128 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fdab::6157:85a7:389b:4de7/128 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fde7:2e0f:a545:85f1:6157:85a7:389b:4de7/128 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) fe80::9e3a:7c9c:f511:e854/64 ethernet up 1500 6C:2B:59:EC:10:73 eth0 (eth0) 192.168.11.73/20 ethernet up 1500 6C:2B:59:EC:10:73 eth1 (eth1) fe80::ec43:37b5:f485:8bbc/64 ethernet up 1500 00:50:56:C0:00:01 eth1 (eth1) 192.168.139.1/24 ethernet up 1500 00:50:56:C0:00:01 eth2 (eth2) fe80::37c9:431d:d446:a895/64 ethernet up 1500 00:50:56:C0:00:08 eth2 (eth2) 192.168.190.1/24 ethernet up 1500 00:50:56:C0:00:08 lo0 (lo0) ::1/128 loopback up -1 lo0 (lo0) 127.0.0.1/8 loopback up -1 eth3 (eth3) fe80::bc00:b319:f23b:9e0f/64 ethernet up 1500 00:15:5D:BE:29:2B eth3 (eth3) 172.19.176.1/20 ethernet up 1500 00:15:5D:BE:29:2B eth4 (eth4) fe80::ed78:6b57:8769:2530/64 ethernet up 1500 00:15:5D:FE:8D:CE eth4 (eth4) 172.22.80.1/20 ethernet up 1500 00:15:5D:FE:8D:CE
DEV WINDEVICE unk0 \Device\NPF{37217669-42DA-4657-A55B-0D995D328250} unk0 \Device\NPF{37217669-42DA-4657-A55B-0D995D328250} unk0 \Device\NPF{37217669-42DA-4657-A55B-0D995D328250} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth0 \Device\NPF{270EA881-7CF4-476A-B6BE-121D9693E7C4} eth1 \Device\NPF{0428F217-800D-4DAB-B0E5-D5AEFB8D89EA} eth1 \Device\NPF{0428F217-800D-4DAB-B0E5-D5AEFB8D89EA} eth2 \Device\NPF{80900FA3-3EE3-406B-9CB1-9E7F623960EE} eth2 \Device\NPF{80900FA3-3EE3-406B-9CB1-9E7F623960EE} lo0 \Device\NPF_Loopback lo0 \Device\NPFLoopback eth3 \Device\NPF{231248FE-FB97-4B90-AD9E-10563FE7169A} eth3 \Device\NPF{231248FE-FB97-4B90-AD9E-10563FE7169A} eth4 \Device\NPF{B712D541-539D-4DF4-B746-68C19339215B} eth4 \Device\NPF_{B712D541-539D-4DF4-B746-68C19339215B}