From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 6 08:45:33 2011 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C43AB1065673 for ; Thu, 6 Oct 2011 08:45:33 +0000 (UTC) (envelope-from oleg@pcbtech.ru) Received: from contrabass.corbina.net (contrabass.post.ru [85.21.78.5]) by mx1.freebsd.org (Postfix) with ESMTP id 1EF3C8FC08 for ; Thu, 6 Oct 2011 08:45:32 +0000 (UTC) Received: from corbina.ru (violin.corbina.net [195.14.50.30]) by contrabass.corbina.net (Postfix) with ESMTP id 67480D0AD2 for ; Thu, 6 Oct 2011 12:29:57 +0400 (MSD) Received: from [10.200.63.205] (account indeez@post.ru HELO indeez.pcbtech.ru) by fe1-mc.corbina.ru (CommuniGate Pro SMTP 5.4.0) with ESMTPSA id 38626903 for freebsd-ipfw@FreeBSD.org; Thu, 06 Oct 2011 12:29:57 +0400 Received: from [192.168.0.33] (localhost [127.0.0.1]) by indeez.pcbtech.ru (8.14.4/8.14.4) with ESMTP id p968TsH9083024 for ; Thu, 6 Oct 2011 12:29:54 +0400 (MSD) (envelope-from oleg@pcbtech.ru) Message-ID: <4E8D6702.9070707@pcbtech.ru> Date: Thu, 06 Oct 2011 12:29:54 +0400 From: Oleg Strizhak User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: freebsd-ipfw@FreeBSD.org Content-Type: text/plain; charset=KOI8-R; format=flowed X-Virus-Scanned: clamav-milter 0.97.2 at indeez.pcbtech.ru X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by indeez.pcbtech.ru id p968TsH9083024 Cc: Subject: ipfw nat drops icmp packets from localhost X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Oct 2011 08:45:33 -0000 Dear All! Would you mind enlightening me a little bit on the following: when I ping or traceroute any external host (even default gateway) w/o=20 ipfw -- it's OK; when I ping -"- w/ ipfw -- it's OK when I traceroute -"- it FAILS =3D( all hop are three stars in a row when any LAN (192.168.0.=C8) host ping or traceroute any ext host (by ipf= w=20 nat) -- it's OK > # uname -a > FreeBSD proxy.yy.ru 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Mon Oct = 3 19:19:30 MSD 2011 aa@xx.yy.ru:/usr/obj/usr/src/sys/ZZZ amd64 > > # ipfw nat show config > ipfw nat 7 config if vr0 log same_ports reset redirect_port tcp 192.168= .0.97:3389 7899 redirect_port tcp 192.168.0.250:3389 8998 redirect_port t= cp 192.168.0.98:3389 7997 redirect_port tcp 192.168.0.201:3389 3333 redir= ect_port tcp 192.168.0.254:3389 5995 redirect_port tcp 192.168.0.99:3389 = 9998 redirect_port tcp 192.168.0.95:3389 8899 redirect_port tcp 192.168.0= .248:20-21 20-21 After an investigation I've found out a very strange situation - it=20 seems to me, that ipfw nat drops some (type 11?) icmp reply packets,=20 whose udp request packets it hasn't rewritten/seen before, e.g: > 05577 count log logamount 1000 icmp from any to any > 05600 nat 7 ip from any to me in { recv fxp0 or recv vr0 } > 05677 count log logamount 1000 icmp from any to any if I ping (let's suppose that my external ip is 1.2.3.4 and dst ip is=20 equal to 5.6.7.8, vr0 - external iface, fxp0 -- reserved external face,=20 not used when vr0 is up & running): > =EFct 6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:8.0 1.2.3.4 5.6.7= .8 out via vr0 > Oct 6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:8.0 1.2.3.4 5.6.7.8= out via vr0 > Oct 6 11:47:40 proxy kernel: ipfw: 5577 Count ICMP:0.0 5.6.7.8 1.2.3.4= in via vr0 > Oct 6 11:47:40 proxy kernel: ipfw: 5677 Count ICMP:0.0 5.6.7.8 1.2.3.4= in via vr0 if I traceroute: > Oct 6 11:01:53 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.= 4 in via vr0 > Oct 6 11:01:58 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.= 4 in via vr0 > Oct 6 11:02:03 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.= 4 in via vr0 at the same time, if LAN host (yes, LAN's behind ale0) traceroutes ext=20 host via nat 7: > Oct 6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 1.2.3.= 4 in via vr0 > Oct 6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.16= 8.0.97 in via vr0 > Oct 6 11:10:07 proxy kernel: ipfw: 5577 Count ICMP:11.0 5.6.7.8 192.16= 8.0.97 out via ale0 > Oct 6 11:10:07 proxy kernel: ipfw: 5677 Count ICMP:11.0 5.6.7.8 192.16= 8.0.97 out via ale0 So, I wonder whether someone else has seen the same case under the=20 similar circumstances? Isn't it a bug within ipfw nat module and is=20 there any work-around/patch for that? I've surely googled, but in vain=20 =3D( The only thing, that seems alike to my problem, is=20 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D129093, but the patch for 8=20 branch didn't cure anything =3D( WBR, Oleg Strizhak