Syn-Ack packets intermittently not received inside wsl distro #12185

c4nc · 2024-10-21T10:03:48Z

Windows Version

Microsoft Windows [Version 10.0.26100.2033]

WSL Version

2.3.24.0

Are you using WSL 1 or WSL 2?

WSL 2
WSL 1

Kernel Version

5.15.153.1

Distro Version

Kali Linux Release: 2024.3

Other Software

Nmap version 7.94SVN
Masscan version 1.3.2
libpcap version 1.10.4 (with TPACKET_V3)

Repro Steps

I'm facing a weird behavior while scanning for open ports on both local network or remote hosts.
Test have been made with both Nmap and Masscan (latest versions)

TCP connect scan correctly works showing the open ports while Syn Scan(s) doesn't give consistent results.
Debugging the issue looks like that the WSL distro doesn't receive (randomly) the reply (syn-ack) packets.

Step to reproduce the behavior:

Install Kali linux wsl from Microsoft store
Install nmap / masscan
Configure WSL in mirrored mode (as follow)

[wsl2]
networkingMode=mirrored
dnsTunneling=true

For debug > disabled Hyper-v Firewall

On the (kali) linux wsl2 vm:

ifconfig
eth4: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.105  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::a4ec:b33:c4fc:e9fe  prefixlen 64  scopeid 0x20<link>
        ether 58:11:22:d8:20:bc  txqueuelen 1000  (Ethernet)
        RX packets 51  bytes 3136 (3.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 138  bytes 7760 (7.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 28  bytes 2576 (2.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 28  bytes 2576 (2.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

loopback0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 00:15:5d:c7:22:a8  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Update the system
- apt update && apt upgrade)
Install required software
- apt install nmap masscan libpcap-dev
Run the scan

sudo nmap -v -Pn -n -v -dd -p443 -e eth4 --packet-trace 192.168.1.1

or

sudo masscan -v -p443 192.168.1.1

Expected Behavior

Nmap or masscan consistently showing port 443 (in this test) open (syn-ack packet received)

sudo nmap -v -Pn -n -v -dd -p443 -e eth4 --packet-trace 192.168.1.1
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-21 11:03 CEST
Fetchfile found /usr/bin/../share/nmap/nmap-services
Fetchfile found /usr/bin/../share/nmap/nmap-protocols
Fetchfile found /usr/bin/../share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating ARP Ping Scan at 11:03
Scanning 192.168.1.1 [1 port]
Packet capture filter (device eth4): arp and arp[18:4] = 0x581122D8 and arp[22:2] = 0x20BC
SENT (0.0968s) ARP who-has 192.168.1.1 tell 192.168.1.105
RCVD (0.0974s) ARP reply 192.168.1.1 is-at 64:62:66:22:5D:84
ultrascan_host_probe_update called for machine 192.168.1.1 state UNKNOWN -> HOST_UP (trynum 0 time: 653)
Fetchfile found /usr/bin/../share/nmap/nmap-mac-prefixes
Changing ping technique for 192.168.1.1 to ARP
Changing global ping host to 192.168.1.1.
Completed ARP Ping Scan at 11:03, 0.10s elapsed (1 total hosts)
Overall sending rates: 10.44 packets / s, 438.28 bytes / s.
Initiating SYN Stealth Scan at 11:03
192.168.1.1 pingprobe type ARP is inappropriate for this scan type; resetting.
Scanning 192.168.1.1 [1 port]
Packet capture filter (device eth4): dst host 192.168.1.105 and (icmp or icmp6 or ((tcp) and (src host 192.168.1.1)))
SENT (0.2370s) TCP [192.168.1.105:46108 > 192.168.1.1:443 S seq=3697453865 win=1024 csum=0xD307 <mss 1460>] IP [ttl=57 id=19648 proto=6 csum=0xb151 iplen=44 ]
RCVD (0.2376s) TCP [192.168.1.1:443 > 192.168.1.105:46108 SA seq=2302336361 win=65228 csum=0x7185 <mss 1460>] IP [ttl=64 id=0 proto=6 csum=0xb711 iplen=44 ]
Discovered open port 443/tcp on 192.168.1.1
Changing ping technique for 192.168.1.1 to tcp to port 443; flags: S
Changing global ping host to 192.168.1.1.
Completed SYN Stealth Scan at 11:03, 0.04s elapsed (1 total ports)
Overall sending rates: 22.89 packets / s, 1007.28 bytes / s.
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.00062s latency).
Scanned at 2024-10-21 11:03:36 CEST for 0s

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack ttl 64
MAC Address: 64:62:66:22:5D:84 (Protectli)
Final times for host: srtt: 622 rttvar: 3765  to: 100000
Read from /usr/bin/../share/nmap: nmap-mac-prefixes nmap-protocols nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 0.31 seconds
           Raw packets sent: 2 (72B) | Rcvd: 2 (72B)

TCPDUMP

sudo tcpdump -n -vv -tttt -i eth4 host 192.168.1.1
tcpdump: listening on eth4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2024-10-21 11:58:04.265072 IP (tos 0x0, ttl 45, id 49583, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.105.46020 > 192.168.1.1.443: Flags [S], cksum 0x0985 (correct), seq 2684531044, win 1024, options [mss 1460], length 0
2024-10-21 11:58:04.265880 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 44)
    192.168.1.1.443 > 192.168.1.105.46020: Flags [S.], cksum 0x78de (correct), seq 3449538604, ack 2684531045, win 65228, options [mss 1460], length 0
2024-10-21 11:58:04.265905 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    192.168.1.105.46020 > 192.168.1.1.443: Flags [R], cksum 0x253e (correct), seq 2684531045, win 0, length 0

Actual Behavior

Trying to scan the target multiple times the result is inconsistent/random, most of the times (~8/10) syn-ack packet aren't received inside the linux vm. Only in rare cases the syn-ack packet reach the vm and so port are listed as "open" instead of filtered.

SYN Stealth Scan (Syn packet scan)

sudo nmap -v -Pn -n -v -dd -p443 -e eth4 --packet-trace 192.168.1.1
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-21 11:03 CEST
Fetchfile found /usr/bin/../share/nmap/nmap-services
Fetchfile found /usr/bin/../share/nmap/nmap-protocols
Fetchfile found /usr/bin/../share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
  hostgroups: min 1, max 100000
  rtt-timeouts: init 1000, min 100, max 10000
  max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
  parallelism: min 0, max 0
  max-retries: 10, host-timeout: 0
  min-rate: 0, max-rate: 0
---------------------------------------------
Initiating ARP Ping Scan at 11:03
Scanning 192.168.1.1 [1 port]
Packet capture filter (device eth4): arp and arp[18:4] = 0x581122D8 and arp[22:2] = 0x20BC
SENT (0.0447s) ARP who-has 192.168.1.1 tell 192.168.1.105
RCVD (0.0453s) ARP reply 192.168.1.1 is-at 64:62:66:22:5D:84
ultrascan_host_probe_update called for machine 192.168.1.1 state UNKNOWN -> HOST_UP (trynum 0 time: 641)
Fetchfile found /usr/bin/../share/nmap/nmap-mac-prefixes
Changing ping technique for 192.168.1.1 to ARP
Changing global ping host to 192.168.1.1.
Completed ARP Ping Scan at 11:03, 0.04s elapsed (1 total hosts)
Overall sending rates: 24.15 packets / s, 1014.17 bytes / s.
Initiating SYN Stealth Scan at 11:03
192.168.1.1 pingprobe type ARP is inappropriate for this scan type; resetting.
Scanning 192.168.1.1 [1 port]
Packet capture filter (device eth4): dst host 192.168.1.105 and (icmp or icmp6 or ((tcp) and (src host 192.168.1.1)))
SENT (0.2131s) TCP [192.168.1.105:40952 > 192.168.1.1:443 S seq=2790614357 win=1024 csum=0x630D <mss 1460>] IP [ttl=45 id=35308 proto=6 csum=0x8025 iplen=44 ]
SENT (0.3134s) TCP [192.168.1.105:40954 > 192.168.1.1:443 S seq=2790745431 win=1024 csum=0x6307 <mss 1460>] IP [ttl=46 id=17314 proto=6 csum=0xc56f iplen=44 ]
Completed SYN Stealth Scan at 11:03, 0.28s elapsed (1 total ports)
Overall sending rates: 7.25 packets / s, 318.81 bytes / s.
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.00060s latency).
Scanned at 2024-10-21 11:03:45 CEST for 1s

PORT    STATE    SERVICE REASON
443/tcp filtered https   no-response
MAC Address: 64:62:66:22:5D:84 (Protectli)
Final times for host: srtt: 601 rttvar: 5000  to: 100000

Read from /usr/bin/../share/nmap: nmap-mac-prefixes nmap-protocols nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 0.49 seconds
           Raw packets sent: 3 (116B) | Rcvd: 1 (28B)

TCPDUMP

sudo tcpdump -n -vv -tttt -i eth4 host 192.168.1.1
tcpdump: listening on eth4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2024-10-21 12:02:20.504904 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.105, length 28
2024-10-21 12:02:20.505642 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.1 is-at 64:62:66:22:5d:84, length 46
2024-10-21 12:02:20.631761 IP (tos 0x0, ttl 43, id 46880, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.105.42640 > 192.168.1.1.443: Flags [S], cksum 0xab2b (correct), seq 2338533777, win 1024, options [mss 1460], length 0
2024-10-21 12:02:20.731879 IP (tos 0x0, ttl 47, id 27366, offset 0, flags [none], proto TCP (6), length 44)
    192.168.1.105.42642 > 192.168.1.1.443: Flags [S], cksum 0xab29 (correct), seq 2338402707, win 1024, options [mss 1460], length 0

TCP Connect Scan

sudo nmap -v -Pn -n -v -dd -p443 -e eth4 -sT --packet-trace 192.168.1.1
Host discovery disabled (-Pn). All addresses will be marked 'up' and scan times may be slower.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-10-21 11:53 CEST
Fetchfile found /usr/bin/../share/nmap/nmap-services
Fetchfile found /usr/bin/../share/nmap/nmap-protocols
Fetchfile found /usr/bin/../share/nmap/nmap.xsl
The max # of sockets we are using is: 0
--------------- Timing report ---------------
 hostgroups: min 1, max 100000
 rtt-timeouts: init 1000, min 100, max 10000
 max-scan-delay: TCP 1000, UDP 1000, SCTP 1000
 parallelism: min 0, max 0
 max-retries: 10, host-timeout: 0
 min-rate: 0, max-rate: 0
---------------------------------------------
Initiating Connect Scan at 11:53
Scanning 192.168.1.1 [1 port]
CONN (0.0122s) TCP localhost > 192.168.1.1:443 => Operation now in progress
CONN (0.0130s) TCP localhost > 192.168.1.1:443 => Connected
Discovered open port 443/tcp on 192.168.1.1
Changing ping technique for 192.168.1.1 to connect to port 443
Changing global ping host to 192.168.1.1.
Completed Connect Scan at 11:53, 0.00s elapsed (1 total ports)
Overall sending rates: 1095.29 packets / s.
Nmap scan report for 192.168.1.1
Host is up, received user-set (0.00085s latency).
Scanned at 2024-10-21 11:53:30 CEST for 0s

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
Final times for host: srtt: 855 rttvar: 5000  to: 100000

Read from /usr/bin/../share/nmap: nmap-protocols nmap-services.
Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

Diagnostic Logs

sudo tcpdump -n -tttt -i eth4 host 192.168.1.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth4, link-type EN10MB (Ethernet), snapshot length 262144 bytes
2024-10-21 11:39:22.201594 ARP, Request who-has 192.168.1.1 tell 192.168.1.105, length 28
2024-10-21 11:39:22.202075 ARP, Reply 192.168.1.1 is-at 64:62:66:22:5d:84, length 46
2024-10-21 11:39:22.336186 IP 192.168.1.105.42565 > 192.168.1.1.443: Flags [S], seq 4001476102, win 1024, options [mss 1460], length 0
2024-10-21 11:39:22.436263 IP 192.168.1.105.42567 > 192.168.1.1.443: Flags [S], seq 4001607172, win 1024, options [mss 1460], length 0

The text was updated successfully, but these errors were encountered:

github-actions · 2024-10-21T10:04:33Z

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions here

Once completed please upload the output files to this Github issue.

Click here for more info on logging
If you choose to email these logs instead of attaching to the bug, please send them to [email protected] with the number of the github issue in the subject, and in the message a link to your comment in the github issue and reply with '/emailed-logs'.

View similar issues

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it!

Open similar issues:

Network packet discrepancy/drop between Windows Host and WSL2 (#10989), similarity score: 0.74
TCP connections stall/reset in Docker containers & network namespaces connected to bridge interface when using mirrored networking mode (#11819), similarity score: 0.70

Closed similar issues:

Network bug in WSL2: TCP connections dropped (not MTU or TCP-keepalive related) (#8797), similarity score: 0.70

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

github-actions · 2024-10-21T10:06:32Z

Diagnostic information

Found '/question', adding tag 'question'

c4nc · 2024-10-21T10:09:12Z

WSL logs
WslLogs-2024-10-21_12-07-32.zip

github-actions · 2024-10-21T10:10:30Z

Diagnostic information

.wslconfig found
Detected appx version: 2.3.24.0

github-actions bot added the needs-author-feedback label Oct 21, 2024

microsoft-github-policy-service bot removed the needs-author-feedback label Oct 21, 2024

github-actions bot added the question label Oct 21, 2024

c4nc mentioned this issue Oct 21, 2024

a potential bug with nmap in WSL(Windows Subsystem on Linux) version nmap/nmap#2950

Open

c4nc closed this as completed Oct 21, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Syn-Ack packets intermittently not received inside wsl distro #12185

Syn-Ack packets intermittently not received inside wsl distro #12185

c4nc commented Oct 21, 2024

github-actions bot commented Oct 21, 2024

github-actions bot commented Oct 21, 2024

c4nc commented Oct 21, 2024

github-actions bot commented Oct 21, 2024

Syn-Ack packets intermittently not received inside wsl distro #12185

Syn-Ack packets intermittently not received inside wsl distro #12185

Comments

c4nc commented Oct 21, 2024

Windows Version

WSL Version

Are you using WSL 1 or WSL 2?

Kernel Version

Distro Version

Other Software

Repro Steps

Expected Behavior

Actual Behavior

Diagnostic Logs

github-actions bot commented Oct 21, 2024

Logs are required for review from WSL team

View similar issues

Open similar issues:

Closed similar issues:

github-actions bot commented Oct 21, 2024

c4nc commented Oct 21, 2024

github-actions bot commented Oct 21, 2024