Masscan doesn't see open port

[nedark]

I tried running multiple times and the majority of times it doesn't see open port, however I see SYN ACK in tcpdump.

I am testing with open SOCKS5 proxy found on the net. 176.113.115.36:60030

root@hu1g:~# masscan 176.113.115.36 --banners -p60030 --source-port 61000 --excludefile exclude.conf  --max-rate 300000
exclude.conf: excluding 136 ranges from file
Starting masscan 1.3.0 (http://bit.ly/14GZzcT) at 2022-01-02 12:36:25 GMT
Initiating SYN Stealth Scan
Scanning 1 hosts [1 port/host]

root@hu1g:~# tcpdump host 176.113.115.36 -X
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:36:25.793359 IP hu1g.*.*.61000 > 176.113.115.36.60030: Flags [S], seq 314122418, win 1024, length 0
        0x0000:  4500 0028 b9e8 0000 ff06 8781 b970 9d5f  E..(.........p._
        0x0010:  b071 7324 ee48 ea7e 12b9 20b2 0000 0000  .qs$.H.~........
        0x0020:  5002 0400 254a 0000                      P...%J..
12:36:25.828107 IP 176.113.115.36.60030 > hu1g.*.*.61000: Flags [.], ack 1794527696, win 65392, length 0
        0x0000:  4500 0028 606e 4000 7b06 24fc b071 7324  E..(`n@.{.$..qs$
        0x0010:  b970 9d5f ea7e ee48 4b76 0b8b 6af6 51d0  .p._.~.HKv..j.Q.
        0x0020:  5010 ff70 496e 0000                      P..pIn..

Previously I run iptables -A INPUT -p tcp --dport 61000 -j DROP

Why doesn't masscan see open port if the machine received ACK?

[dingusgh]

masscan sent a syn packet [S] with a SEQ=314122418 the syn-ack [S.] that you should have gotten back would have been ACK = SEQ+1 = 314122419 but you can see that your ACK is 1794527696 and not only that, yours is a plain ack packet [.] so, that packet you are seeing, its a response to some other previous communication thats not related to your masscan scan

[ragzilla]

I'm able to reproduce this against (I believe) a Windows 2008 host. I believe it is due to the SynAttackProtect feature when no TCP options block containing MSS is present in the initial SYN. When an options block containing MSS is present, the typical seq/ack behavior is observed.

Working host:
09:53:02.584750 IP 192.168.3.166.61000 > 192.168.3.12.636: Flags [S], seq 1116364961, win 1024, length 0
09:53:02.585042 IP 192.168.3.12.636 > 192.168.3.166.61000: Flags [S.], seq 987283861, ack 1116364962, win 1608, length 0

Non-working host:
09:53:02.584832 IP 192.168.3.166.61000 > 192.168.3.24.636: Flags [S], seq 2239021966, win 1024, length 0
09:53:02.585200 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2400568845, ack 2403073702, win 8192, options [mss 1460], length 0
09:53:05.596100 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2400568845, ack 2403073702, win 8192, options [mss 1460], length 0
09:53:11.597331 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2400568845, ack 2403073702, win 8192, options [mss 1460], length 0

Telnet:
09:54:10.147676 IP 192.168.3.166.43016 > 192.168.3.24.636: Flags [S], seq 3507402022, win 64240, options [mss 1460,sackOK,TS val 1864632288 ecr 0,nop,wscale 7], length 0
09:54:10.147924 IP 192.168.3.24.636 > 192.168.3.166.43016: Flags [S.], seq 296942448, ack 3507402023, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 367253681 ecr 1864632288], length 0

NMAP:
09:57:43.530751 IP 192.168.3.166.42779 > 192.168.3.24.636: Flags [S], seq 1883965837, win 1024, options [mss 1460], length 0
09:57:43.531018 IP 192.168.3.24.636 > 192.168.3.166.42779: Flags [S.], seq 1136514218, ack 1883965838, win 8192, options [mss 1460], length 0

Possibly also related, #472, #450, and plenty others I'm sure.

--edit-- In my particular instance, the patch from #646 doesn't seem to help. The server is still tinkering with seq:

10:30:07.147511 IP 192.168.3.166.61000 > 192.168.3.12.636: Flags [S], seq 4174550751, win 1024, options [mss 1460], length 0
10:30:07.147888 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2988582542, ack 794236902, win 8192, options [mss 1460], length 0
10:30:10.151574 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2988582542, ack 794236902, win 8192, options [mss 1460], length 0
10:30:16.156548 IP 192.168.3.24.636 > 192.168.3.166.61000: Flags [S.], seq 2988582542, ack 794236902, win 8192, options [mss 1460], length 0

--further edit-- This behavior in the local subnet that I'm seeing may be due to masscan always sending packets to the gateway, which in my instance is a security appliance that is tinkering with the seq. The hosts which I'm seeing good responses for in the local subnet are pinning the return traffic to the MAC the traffic was received from so the gateway sees both directions.