On Thu, Mar 12, 2009 at 10:13:53AM +0100, Jeremie Le Hen wrote:
> % yoda# nmap -sS AAA.BBB.CCC.DDD
> % Starting Nmap 4.65 ( http://nmap.org ) at 2009-03-12 08:00 CET
> % sendto in send_ip_packet: sendto(4, packet, 44, 0, AAA.BBB.CCC.DDD, 16) =>
> No route to host
> % Offending packet: TCP WWW.XXX.YYY.ZZZ:57973 > AAA.BBB.CCC.ZZZ:80 S ttl=39
> id=39289 iplen=11264 seq=3869808471 win=4096 <mss 1460>
>
> However, I can make nmap run flawlessly when I remove the "keep state"
> statement:
>
> % pass out quick all
>
> Do you have an idea about the problem? Note that pf on NetBSD 4.0.1
> doesn't implicitely enable "flags S/SA" as in later version of OpenBSD.
The following scenario would produce what you observe:
1) nmap sends a first TCP SYN to AAA.BBB.CCC.DDD with a random
initial sequence number th_seq1
2) pf allows the packet out and creates a state entry (check with
pfctl -vvss)
3) the external host is down or doesn't respond to the TCP SYN at all
4) nmap times out waiting for a response, retries sending the probe
(see nmap --max-retries)
5) nmap crafts a second TCP SYN to AAA.BBB.CCC.DDD, but unwisely
chooses another initial sequence number th_seq2 != th_seq1
6) the packet matches the state entry in pf, but the sequence number
is completely off, hence pf blocks the packet
7) when a local socket's outgoing packet is blocked by pf, the
syscall gets errno "No route to host"
Try running nmap with -vv, maybe it shows what it's trying to do.
Also enable verbose logging (pfctl -x misc) and check /var/log/messages
for "BAD state" entries, which come with sequence number mismatches.
If this is indeed what's happening, nmap is misbehaving, and pf is
correct in blocking the invalid retransmission.
With nmap -sT it usually works, because the TCP/IP stack of the OS
doesn't make mistakes like this :)
Daniel
