Metasploit Framework

The "incorrect" sender IP address, 77.83.70.51, is by design. Will confer with the reporter if the responses are getting back to him regardless (they certainly should).

Sent to the reporter:

> arp who-has 192.168.20.2 tell 77.83.70.51
> arp who-has 192.168.20.3 tell 77.83.70.51
> arp who-has 192.168.20.4 tell 77.83.70.51

This is normal. Will explain in a bit.

> I'm scanning 192.168.20.0/24 network and machine with metasploit does not
> have any external ip-address or connection to the internet.
> IP-address 77.83.70.51 does not belongs to my IPS.
> I'm reciving such errors in the msfconsole:
> [-] Error: #<Class:0xb54d7410> execution expired

This is normal but probably not desired; need to track down exactly what's expiring and why it's throwing the ugly error. Generally it should be harmless -- this means that you didn't get an arp reply within the timeout. 

The big question is: are you able to scan anything in 192.168.20.0/24? Is there a host in there you know will respond to ARP? (tcpdump while pinging will confirm, even if you get no ping response).

As for 77.83.70.51 -- This is what Metasploit is setting as the source IP address of the ARP packet, and this is settable as the ARP_SECRET advanced option. The source IP address needn't be correct to actually receive ARP replies, since the MAC address /is/ set correctly. (your tcpdump should confirm this).

I've attached an example pcap showing the expected behavior of the syn portscanner. The network being scanned is 192.168.1.100/30 (4 hosts), which includes a printer at .100, me at .101, and nothing at .102 and .103.

Packet 1,2: ARP request and reply.
Packet 3,4 : SYN to .100 port 81, and a RST.
Packet 5: SYN to .101 -- no ARP because I'm .101, so I already know my MAC address.
Packet 6-7: Unanswered ARP requests to .102 and .103 (normal because they're not there).

Hope this helps, and do let me know if you're running into a problem that's not described here.

Talked to hdm/jduck, and it turns out the source IP /is/ significant on enough networks that it should be legit in order to catch the replies. Will fix.

Applied in changeset r8832.

Still a bit of a problem. Looks like this comes up only on switched networks that don't actually have a gateway -- in that case, you won't hear the replies to your probes because you have a bad mac address. That's the working theory, anyway; waiting to hear back from the reporter to confirm.

Commits in the interim seems to have solved this problem for the reporter -- he can no longer reproduce the problem on his virtualized network. Closing.

This was fixed two months ago , just never closed correctly.