FWIW, it appears the issue only happens in relation to the pppoe interface--meaning, nmap scans over wi and fxp work as expected.
Melameth, Daniel D. wrote: > Okan Demirmen wrote: > > On Mon 2006.02.06 at 20:31 +0100, Joachim Schipper wrote: > > > On Sun, Feb 05, 2006 at 10:03:57PM -0500, Melameth, Daniel D. > > > wrote: > > > > Joachim Schipper wrote: > > > > > On Fri, Feb 03, 2006 at 10:02:32PM -0500, Melameth, Daniel D. > > > > > wrote: > > > > > > An nmap scan gives me this: > > > > > > > > > > > > $ sudo nmap 208.139.x.x > > > > > > > > > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at > > > > > > 2006-02-03 19:45 MST Note: Host seems down. If it is really > > > > > > up, but blocking our ping probes, try -P0 Nmap finished: 1 > > > > > > IP address (0 hosts up) scanned in 2.109 seconds > > > > > > > > > > > > Which I follow up with a: > > > > > > > > > > > > $ ping -c 5 208.139.x.x > > > > > > PING 208.139.x.x (208.139.x.x): 56 data bytes > > > > > > 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=91.979 ms > > > > > > > > > > > > --- 208.139.x.x ping statistics --- > > > > > > 5 packets transmitted, 5 packets received, 0.0% packet loss > > > > > > round-trip min/avg/max/std-dev = 82.354/86.470/91.979/3.295 > > > > > > ms > > > > > > > > > > > > Running while the above is happening, tcpdumps yield: > > > > > > > > > > > > $ sudo tcpdump -qni pflog0 > > > > > > tcpdump: WARNING: pflog0: no IPv4 address assigned > > > > > > tcpdump: listening on pflog0, link-type PFLOG > > > > > > > > > > > > I'm not certain where to look next. > > > > > > > > > > Look into what the return packets actually contain. If, for > > > > > instance, the remote end is a OpenBSD firewall that has been > > > > > configured explicitly to drop nmap (using pf's passive OS > > > > > recognition feature, for instance), you'd see exactly what you > > > > > see now. (Discarding OpenBSD for a while, almost any decent > > > > > firewall can be configured to drop traffic that looks like it > > > > > came from nmap.) > > > > > > > > > > And the return packets are not too useful - is that first icmp > > > > > packet an echo reply or a destination-unreachable notice? And > > > > > the TCP packet - is it a SYN/ACK or RST packet? > > > > > > > > The remote end is an OpenBSD machine that has not been > > > > configured to drop nmap packets and allows incoming ssh and > > > > http connections. > > > > > > > > On second thought, I'd not certain why I made tcpdump > > > > quiet--habit perhaps. Here is the same test with more > > > > verbosity: > > > > > > > > > > > > $ sudo nmap 208.139.x.x > > > > > > > > Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at > > > > 2006-02-05 19:43 MST Note: Host seems down. If it is really up, > > > > but blocking our ping probes, try -P0 Nmap finished: 1 IP > > > > address (0 hosts up) scanned in 2.163 seconds > > > > > > > > $ ping -c 5 208.139.x.x > > > > PING 208.139.x.x (208.139.x.x): 56 data bytes > > > > 64 bytes from 208.139.x.x: icmp_seq=0 ttl=239 time=85.137 ms > > > > 64 bytes from 208.139.x.x: icmp_seq=1 ttl=239 time=83.103 ms > > > > 64 bytes from 208.139.x.x: icmp_seq=2 ttl=239 time=90.038 ms > > > > 64 bytes from 208.139.x.x: icmp_seq=3 ttl=239 time=86.490 ms > > > > 64 bytes from 208.139.x.x: icmp_seq=4 ttl=239 time=92.098 ms > > > > --- 208.139.x.x ping statistics --- > > > > 5 packets transmitted, 5 packets received, 0.0% packet loss > > > > round-trip min/avg/max/std-dev = 83.103/87.373/92.098/3.274 ms > > > > > > > > $ sudo tcpdump -ni pppoe0 host 208.139.x.x > > > > tcpdump: listening on pppoe0, link-type PPP_ETHER > > > > 19:43:01.507785 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:01.507980 209.180.x.x.60199 > 208.139.x.x.80: . ack > > > > 2409580574 win 1024 19:43:01.595748 208.139.x.x > 209.180.x.x: > > > > icmp: echo reply 19:43:01.600100 208.139.x.x.80 > > > > > 209.180.x.x.60199: R 2409580574:2409580574(0) win 0 (DF) > > > > 19:43:02.520065 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:02.520244 209.180.x.x.60200 > 208.139.x.x.80: . ack > > > > 2829011038 win 1024 19:43:02.609989 208.139.x.x > 209.180.x.x: > > > > icmp: echo reply 19:43:02.611334 208.139.x.x.80 > > > > > 209.180.x.x.60200: R 2829011038:2829011038(0) win 0 (DF) > > > > 19:43:37.650310 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:37.735247 208.139.x.x > 209.180.x.x: icmp: echo reply > > > > 19:43:38.660020 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:38.743035 208.139.x.x > 209.180.x.x: icmp: echo reply > > > > 19:43:39.669973 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:39.759944 208.139.x.x > 209.180.x.x: icmp: echo reply > > > > 19:43:40.679970 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:40.766399 208.139.x.x > 209.180.x.x: icmp: echo reply > > > > 19:43:41.689986 209.180.x.x > 208.139.x.x: icmp: echo request > > > > 19:43:41.781991 208.139.x.x > 209.180.x.x: icmp: echo reply > > > > > > > > $ sudo tcpdump -ni pflog0 > > > > tcpdump: WARNING: pflog0: no IPv4 address assigned > > > > tcpdump: listening on pflog0, link-type PFLOG > > > > > > > > > > > > So the return packets are definitely coming back, but nmap is > > > > not seeing them. (On the TCP end, it appears nmap is sending > > > > an ACK and the target is send a RST.) > > > > > > Looks strange. Unless I am mistaken, though, you check the output > > > of nmap against a trace of ping. Could you please post a tcpdump > > > for nmap? > > The full tcpdump of nmap is reflected in the first eight full lines > directly above. > > > > Also, check /etc/pf.conf for any rules marked block without being > > > marked log; and please post your routing table if it's > > > interesting. > > There is really only one block rule and it is set to log. As for the > route table, I didn't find it interesting, but someone else might: > > $ netstat -r > Routing tables > > Internet: > Destination Gateway Flags Refs Use Mtu > Interface > default 0.0.0.1 UGS 8 1138874 - > pppoe0 > 0.0.0.1 0.0.0.0 UH 1 0 - > pppoe0 > loopback localhost UGRS 0 0 33224 > lo0 > localhost localhost UH 1 651 33224 > lo0 > 192.168.255.220/30 link#6 UC 0 0 - > fxp0 > 192.168.255.224/27 link#5 UC 1 0 - > wi0 > 192.168.255.240 0:c:f1:5:ce:6b UHLc 1 601267 - > wi0 > BASE-ADDRESS.MCAST localhost URS 0 0 33224 > lo0 > > > i too would look at pf(4) - disable it, pass quick, no state, log, > > whatever; but look at your state table. also, you may have mentioned > > this before, but what arch is this on? > > I just disabled pf and the issue is reproducible. This is on i386.
