strange nmap issue

[bbzz]

Two computers belong to same wireless LAN (192.168.1.100 && 192.168.1.106). Also they are directly connected with ethernet cable (10.0.0.2 && 10.0.0.1).

Firewalls are disabled.

There is open ssh port 8022 on host 192.168.1.106/10.0.0.1.
I can connect to both IPs. However, when I scan for open port on 10.0.0.1 it shows as filtered:

# nmap -sS -n -Pn -p8022 10.0.0.1

Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2011-12-04 02:54 CET
Nmap scan report for 10.0.0.1
Host is up.
PORT     STATE    SERVICE
8022/tcp filtered oa-system

The weird part is that nmap receives SYN/ACK and kernel sends back RST, and yet it cannot identify it as open:

IP 10.0.0.2.42951 > 10.0.0.1.8022: Flags [S], seq 2777807954, win 1024, options [mss 1460], length 0
IP 10.0.0.1.8022 > 10.0.0.2.42951: Flags [S.], seq 1255990125, ack 2777807955, win 65535, options [mss 1460], length 0
IP 10.0.0.2.42951 > 10.0.0.1.8022: Flags [R], seq 2777807955, win 0, length 0
IP 10.0.0.2.42952 > 10.0.0.1.8022: Flags [S], seq 2777742419, win 1024, options [mss 1460], length 0
IP 10.0.0.1.8022 > 10.0.0.2.42952: Flags [S.], seq 3709838176, ack 2777742420, win 65535, options [mss 1460], length 0
IP 10.0.0.2.42952 > 10.0.0.1.8022: Flags [R], seq 2777742420, win 0, length 0

However, if I instead use wireless LAN it correctly show it as open:

# nmap -sS -n -Pn -p8022 192.168.1.106

Starting Nmap 5.61TEST2 ( http://nmap.org ) at 2011-12-04 02:58 CET
Nmap scan report for 192.168.1.106
Host is up (0.00072s latency).
PORT     STATE SERVICE
8022/tcp open  oa-system

Nmap done: 1 IP address (1 host up) scanned in 1.04 seconds

Does anyone have an idea why this is happening?

 

[anomie]

Very odd indeed. Since you're seeing SYN + SYN/ACK, you know the -sS (half open) scan is succeeding. I don't have that exact nmap version to test with. Perhaps try with a non TEST* branch?

You are using a crossover Ethernet cable, right?

 

[bbzz]

Card use autodetection (mdi or mdiX or w/e) so it doesn't matter (or it shouldn't) - the communication across the link is fine, I am constantly connected to sshd on 10.0.0.1 from 10.0.0.2. It's just the scanning that doesn't seem to work. Meaning the issue is with nmap.

So i did another test using vbox with Windows client installed (disabled Windows firewall). I used host-only option for virtual connection between vboxnet0 and virtual Windows Ethernet port - and the outcome is same. I can see [S.] flags going back to nmap but it sees port 445 as filtered, which I know is open.
When I add a virtual link on Windows, and scan that link it correctly sees all ports as open!

The conclusion - there seems to be issue with point-to-point communication, even though it's Ethernet and not really p-2-p link. But it seems nmap can't process this right when neighbors are directly connected.
It's really weird because I hadn't see this earlier and nothing is really changes as far as my configuration goes.

BWT, this is installation from ports; I don't know when was it updated last time.

 

[anomie]

... I am constantly connected to sshd on 10.0.0.1 from 10.0.0.2. It's just the scanning that doesn't seem to work. Meaning the issue is with nmap.

I agree, based on what information you've shared anyway. Try other scan types (e.g. -sT) and see if you get similarly odd results. Whatever the case may be, the way I'd approach it is 1) upgrade your port and test again; 2) if you can duplicate the behavior with the latest port, consider a bug report to the maintainer (who may kick it upstream to Fyodor and the gang).

 

[bbzz]

-sT works, I forgot to mention, sorry. Which makes sense since I'm establishing full connection with ssh anyway. It is this -sS that isn't begin processed right.
Maybe you can test it as well, so we make sure I'm not hallucinating or doing something silly before I report?
It is the latest version from ports.

 

[anomie]

Well, I installed it from ports:

# nmap | head
Nmap 5.61TEST2 ( http://nmap.org )
...

But my -sS testing didn't yield problems. On the other hand, I don't have any direct-attached Ethernet hosts I can test with.

It appears you've done your due diligence by isolating the conditions under which the behavior occurs. You can even demonstrate (via tcpdump(1)) that the TCP conversation goes as expected, but that nmap doesn't interpret it as expected.