From owner-freebsd-ipfw@FreeBSD.ORG Mon Sep 12 11:07:05 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 603AA106567B for ; Mon, 12 Sep 2011 11:07:05 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 44E988FC16 for ; Mon, 12 Sep 2011 11:07:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p8CB75rl005471 for ; Mon, 12 Sep 2011 11:07:05 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p8CB743A005469 for freebsd-ipfw@FreeBSD.org; Mon, 12 Sep 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 12 Sep 2011 11:07:04 GMT Message-Id: <201109121107.p8CB743A005469@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-ipfw@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-ipfw@FreeBSD.org 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: Mon, 12 Sep 2011 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/158066 ipfw [ipfw] ipfw + netgraph + multicast = multicast packets o kern/157796 ipfw [ipfw] IPFW in-kernel NAT nat loopback / Default Route o kern/157689 ipfw [ipfw] ipfw nat config does not accept nonexistent int o kern/156770 ipfw [ipfw] [dummynet] [patch]: performance improvement and f kern/155927 ipfw [ipfw] ipfw stops to check packets for compliance with o bin/153252 ipfw [ipfw][patch] ipfw lockdown system in subsequent call o kern/153161 ipfw IPFIREWALL does not allow specify rules with ICMP code o kern/152113 ipfw [ipfw] page fault on 8.1-RELEASE caused by certain amo o kern/148827 ipfw [ipfw] divert broken with in-kernel ipfw o kern/148689 ipfw [ipfw] antispoof wrongly triggers on link local IPv6 a o kern/148430 ipfw [ipfw] IPFW schedule delete broken. o kern/148091 ipfw [ipfw] ipfw ipv6 handling broken. f kern/144269 ipfw [ipfw] problem with ipfw tables o kern/143973 ipfw [ipfw] [panic] ipfw forward option causes kernel reboo o kern/143621 ipfw [ipfw] [dummynet] [patch] dummynet and vnet use result f kern/143474 ipfw [ipfw] ipfw table contains the same address o kern/137346 ipfw [ipfw] ipfw nat redirect_proto is broken o kern/137232 ipfw [ipfw] parser troubles o kern/135476 ipfw [ipfw] IPFW table breaks after adding a large number o f kern/129036 ipfw [ipfw] 'ipfw fwd' does not change outgoing interface n p kern/128260 ipfw [ipfw] [patch] ipfw_divert damages IPv6 packets o kern/127230 ipfw [ipfw] [patch] Feature request to add UID and/or GID l f kern/127209 ipfw [ipfw] IPFW table become corrupted after many changes o kern/122963 ipfw [ipfw] tcpdump does not show packets redirected by 'ip s kern/121807 ipfw [request] TCP and UDP port_table in ipfw o kern/121122 ipfw [ipfw] [patch] add support to ToS IP PRECEDENCE fields o kern/116009 ipfw [ipfw] [patch] Ignore errors when loading ruleset from o bin/104921 ipfw [patch] ipfw(8) sometimes treats ipv6 input as ipv4 (a o kern/104682 ipfw [ipfw] [patch] Some minor language consistency fixes a o kern/103454 ipfw [ipfw] [patch] [request] add a facility to modify DF b o kern/103328 ipfw [ipfw] [request] sugestions about ipfw table o kern/102471 ipfw [ipfw] [patch] add tos and dscp support o kern/97951 ipfw [ipfw] [patch] ipfw does not tie interface details to o kern/95084 ipfw [ipfw] [regression] [patch] IPFW2 ignores "recv/xmit/v f kern/91847 ipfw [ipfw] ipfw with vlanX as the device o kern/86957 ipfw [ipfw] [patch] ipfw mac logging o bin/83046 ipfw [ipfw] ipfw2 error: "setup" is allowed for icmp, but s o kern/82724 ipfw [ipfw] [patch] [request] Add setnexthop and defaultrou o bin/78785 ipfw [patch] ipfw(8) verbosity locks machine if /etc/rc.fir o kern/60719 ipfw [ipfw] Headerless fragments generate cryptic error mes s kern/55984 ipfw [ipfw] [patch] time based firewalling support for ipfw o kern/48172 ipfw [ipfw] [patch] ipfw does not log size and flags o kern/46159 ipfw [ipfw] [patch] [request] ipfw dynamic rules lifetime f a kern/26534 ipfw [ipfw] Add an option to ipfw to log gid/uid of who cau 44 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 13 05:42:37 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 65BC7106566B for ; Tue, 13 Sep 2011 05:42:37 +0000 (UTC) (envelope-from admin@tigris.org) Received: from sc157-tigr.sjc.collab.net (sc157.sjc.collab.net [204.16.104.226]) by mx1.freebsd.org (Postfix) with ESMTP id 586CC8FC13 for ; Tue, 13 Sep 2011 05:42:37 +0000 (UTC) Received: from sc157-tigr.sjc.collab.net (localhost [127.0.0.1]) by sc157-tigr.sjc.collab.net (Postfix) with ESMTP id 2AA935400CF for ; Mon, 12 Sep 2011 22:25:17 -0700 (PDT) Date: Mon, 12 Sep 2011 22:25:17 -0700 (PDT) From: admin@subversion.tigris.org To: freebsd-ipfw@freebsd.org Message-ID: <1315891517156@subversion.tigris.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Notice about your recent message to dev-help@subversion.tigris.org 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: Tue, 13 Sep 2011 05:42:37 -0000 We are sorry, but this discussion does not exist. Your recent message to (Returned mail: see transcript for details) was rejected. From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 14 08:44:16 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 DAAD71065673 for ; Wed, 14 Sep 2011 08:44:16 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vw0-f50.google.com (mail-vw0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 92EEF8FC22 for ; Wed, 14 Sep 2011 08:44:16 +0000 (UTC) Received: by vws14 with SMTP id 14so2124971vws.37 for ; Wed, 14 Sep 2011 01:44:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=h8e5Qn5AyQKBmVlQstfHVZHEOjc+CaNOvap35rxZjRQ=; b=wBwmq8skHYoceceXgJSl6XKFwZ7OqG3GP/K5gsHAsWtQ9jqaWyDNMOKtZXjTiamukm u/DCz3e+d6yHC91kpqSejP589hXFgMZBRmu/Tz9nSmaylbBE4vi4TBR7rVjWyljR0h3Z JGwBmvCcDmu/y3u3zwpInxxpoTRSkcxZpgdw0= MIME-Version: 1.0 Received: by 10.52.23.84 with SMTP id k20mr600404vdf.83.1315989387826; Wed, 14 Sep 2011 01:36:27 -0700 (PDT) Received: by 10.220.195.75 with HTTP; Wed, 14 Sep 2011 01:36:27 -0700 (PDT) In-Reply-To: <4E7066CE.3070702@gmail.com> References: <4E7066CE.3070702@gmail.com> Date: Wed, 14 Sep 2011 12:36:27 +0400 Message-ID: From: Vladimir Budnev To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Re: IPFW hidden/broken rule? (Free 7.2) 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: Wed, 14 Sep 2011 08:44:16 -0000 Typo: mustbe: We'v noticed that no packets from specific ip(10.10.122.23/32 ) From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 14 08:54:34 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 7F2251065673; Wed, 14 Sep 2011 08:54:34 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (unknown [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id C536F8FC12; Wed, 14 Sep 2011 08:54:33 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id p8E8sUL3016120; Wed, 14 Sep 2011 15:54:30 +0700 (NOVST) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E706BC1.9030203@rdtc.ru> Date: Wed, 14 Sep 2011 15:54:25 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Vladimir Budnev References: <4E7066CE.3070702@gmail.com> In-Reply-To: <4E7066CE.3070702@gmail.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: IPFW hidden/broken rule? (Free 7.2) 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: Wed, 14 Sep 2011 08:54:34 -0000 14.09.2011 15:33, Vladimir Budnev ÐÉÛÅÔ: > So i think there are at least to questions: > > 1. Have anyone ever met such situation? Or may be something close to > this one with 'hidden' ipfw rules? Have you tried "ipfw -d -e show"? Eugene Grosbein From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 14 09:04:15 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 4095C1065673 for ; Wed, 14 Sep 2011 09:04:15 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id BE01B8FC1B for ; Wed, 14 Sep 2011 09:04:14 +0000 (UTC) Received: by mail-bw0-f54.google.com with SMTP id zs8so1622937bkb.13 for ; Wed, 14 Sep 2011 02:04:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=6uD6q9JNCIu0sRW6Y+pm1Xqw/hqz+CswnfhqWQWopxo=; b=k3r1BqZ8d1FtR52nTmy3hia6st0tQgGoQkhoTD9fh6J6hPoR7bh/VX1EI9b9ydK1CK /rgem0PXxNdnhM4amp913P50exNS8vjgyYlwsfiwj2f3cE9+mSc902QNSZUEp10Lp13U 6/B90YVZSjoKXutbTX2HloHqm1bMkR2zYbmUA= Received: by 10.204.9.205 with SMTP id m13mr1017060bkm.212.1315989202252; Wed, 14 Sep 2011 01:33:22 -0700 (PDT) Received: from [192.168.66.106] ([80.253.27.98]) by mx.google.com with ESMTPS id z9sm3110999bkn.7.2011.09.14.01.33.20 (version=SSLv3 cipher=OTHER); Wed, 14 Sep 2011 01:33:21 -0700 (PDT) Message-ID: <4E7066CE.3070702@gmail.com> Date: Wed, 14 Sep 2011 12:33:18 +0400 From: Vladimir Budnev User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru_RU; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12 MIME-Version: 1.0 To: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: IPFW hidden/broken rule? (Free 7.2) 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: Wed, 14 Sep 2011 09:04:15 -0000 Hello list I am not sure which list this question must go to, so I am sending to -net and -ipfw lists. We have faced some strange problem with ipfw behavior, which we can't understand ourselves. An it really hurts:( We are running 7.2-RELEASE. I'll try to describe the problem as we observe it and our steps to figure out what is happening. An questions will be at the end. In short there is a situation which looks like some old rule keep on playing but we cant see this in ipfw outputs. I'd say 'hidden' rule So we have ipfw using tables for pipes, and we have e.g. following ipfw output.The pipes configuration does mean nothing, it will be clear at the end of mail, where key moment will be described. [Out1] <...> 04701 pipe tablearg ip from table(2) to any in via em0 04801 pipe tablearg ip from any to table(3) out via em0 04901 allow ip from table(4) to any in via em0 05001 allow ip from any to table(4) out via em0 05101 fwd tcp from table(5) to any dst-port 80,443,8828 in via em0 <...> We'v noticed that no packets from specific ip(10.121.241.23) reache 5101 rule with fwd to example.server. This ip is in table 5: # ipfw table 5 list 10.10.122.23/32 0 10.10.122.167/32 0 We’ve parsed all tables and no matches. OK, we started placing debug rules to realize which rule accepts packets. And we found out following.If we place the following debug rule(we used the same fwd rule) such way(added 4602 rule): [Out2] <...> 04602 113 75 fwd tcp from table(5) to any dst-port 80,443,8828 in via em0 <-- OK her 04701 107971113 85095893815 pipe tablearg ip from table(2) to any in via em0 04801 102517924 83276945675 pipe tablearg ip from any to table(3) out via em0 04901 4413338 991348968 allow ip from table(4) to any in via em0 05001 7146323 8293221022 allow ip from any to table(4) out via em0 05101 0 0 fwd tcp from table(5) to any dst-port 80,443,8828 in via em0 <...> Then packets match the rule.But if we delete 4602 and place debug rule at 4702: [Out3] <...> 04701 108458823 85372134891 pipe tablearg ip from table(2) to any in via em0 04702 0 0 fwd tcp from table(5) to any dst-port 80,443,8828 in via em0 <-- NOT WORKING 04801 - - pipe tablearg ip from any to table(3) out via em0 04901 - - allow ip from table(4) to any in via em0 05001 - - allow ip from any to table(4) out via em0 05101 0 0 fwd tcp from table(5) to any dst-port 80,443,8828 in via em0 <...> So placing rule after 4701 gives zero counters, that means that our ip packets match 4701 rule :) But we DO NOT HAVE target ip in table 2. It resides only in table 5 as shown before.But it must be noticed that such rule WAS in table 2 before.But then was removed from table 2 and added to table 6. Records in table 2 looks like that: # ipfw table 2 list 10.10.122.20/32 9 10.10.122.21/32 4 10.10.122.25/32 9 10.10.122.28/32 6 10.10.122.30/32 6 We also thought that mb we added missconfigured rule e.g. 10.10.122.0/24 rule in table 2 but no. Here goes the KEY moment! OK crawling through the logs, different tests etc we decide to clear table 2. At first step, we’ve deleted all records manually, with: ipfw table 2 delete and NO effect at the time table was clear.So there were no records in table 2, but rule 4701 was still catching packets from the target ip. Second, we did flush with ipfw table 2 flush And voila, everything went fine from that moment! Miracle flush? So the problem seems like the rule resides deep in the kernel heart, but we can NOT see this rule with ipfw output. So i think there are at least to questions: 1. Have anyone ever met such situation? Or may be something close to this one with 'hidden' ipfw rules? 2. Is there a way how to get more info about rules and firewall matching decisions? Mb some sysctl tuning or something else? Cause its the first time we met such situation and don’t even imagine how to diagnose such 'hidden' rule:( From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 14 10:48:58 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 9E02B1065678; Wed, 14 Sep 2011 10:48:58 +0000 (UTC) (envelope-from vladimir.budnev@gmail.com) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4957E8FC14; Wed, 14 Sep 2011 10:48:58 +0000 (UTC) Received: by vws5 with SMTP id 5so19159vws.17 for ; Wed, 14 Sep 2011 03:48:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Gd4C46LezxYf6lZVisMu2EjdFDRF0eqknOky66XmBvs=; b=tTY30dk1568iUR1k9AyOMlVG516th0UEiddBO0j+o1KJ8tVbL8AoTBjn4/w5j8BFuj MKJIv3FZmDa3pPDgEGvcBLOen/h5TTlCSQsjGiqsIWL/zt66wyZMw3I+nrcr8/muHd5W mnif3k7qAAxHtHBVJpaQT93Ck0iR8UgZzS2DM= MIME-Version: 1.0 Received: by 10.220.151.201 with SMTP id d9mr297672vcw.129.1315997337577; Wed, 14 Sep 2011 03:48:57 -0700 (PDT) Received: by 10.220.195.75 with HTTP; Wed, 14 Sep 2011 03:48:57 -0700 (PDT) In-Reply-To: <4E706BC1.9030203@rdtc.ru> References: <4E7066CE.3070702@gmail.com> <4E706BC1.9030203@rdtc.ru> Date: Wed, 14 Sep 2011 14:48:57 +0400 Message-ID: From: Vladimir Budnev To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: IPFW hidden/broken rule? (Free 7.2) 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: Wed, 14 Sep 2011 10:48:58 -0000 > > 14.09.2011 15:33, Vladimir Budnev =D0=C9=DB=C5=D4: > > > So i think there are at least to questions: > > > > 1. Have anyone ever met such situation? Or may be something close to > > this one with 'hidden' ipfw rules? > > Have you tried "ipfw -d -e show"? > > Nope we didnt check those tables. But to be honest iI don't think there may be connection tracking issue because it is allow ip to any rule: 04701 pipe tablearg ip from table(2) to any in via em0 And I'v wrote that we can catch packets with rule, by placing it before rul= e 04701.Packets are captured by 04701 even with empty(not flushed) table 2. From owner-freebsd-ipfw@FreeBSD.ORG Wed Sep 14 21:10:45 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 E32AB106566C for ; Wed, 14 Sep 2011 21:10:45 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id ADBF98FC21 for ; Wed, 14 Sep 2011 21:10:45 +0000 (UTC) Received: from julian-mac.elischer.org (home-nat.elischer.org [67.100.89.137]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id p8EKo8Lb032790 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Sep 2011 13:50:15 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <4E7113A3.80605@freebsd.org> Date: Wed, 14 Sep 2011 13:50:43 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.22) Gecko/20110902 Thunderbird/3.1.14 MIME-Version: 1.0 To: Vladimir Budnev References: <4E7066CE.3070702@gmail.com> In-Reply-To: <4E7066CE.3070702@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-ipfw@freebsd.org Subject: Re: IPFW hidden/broken rule? (Free 7.2) 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: Wed, 14 Sep 2011 21:10:46 -0000 On 9/14/11 1:33 AM, Vladimir Budnev wrote: > Hello list > > I am not sure which list this question must go to, so I am sending > to -net and -ipfw lists. > > We have faced some strange problem with ipfw behavior, which we > can't understand ourselves. An it really hurts:( > > We are running 7.2-RELEASE. > > I'll try to describe the problem as we observe it and our steps to > figure out what is happening. An questions will be at the end. > > In short there is a situation which looks like some old rule keep on > playing but we cant see this in ipfw outputs. I'd say 'hidden' rule > > So we have ipfw using tables for pipes, and we have e.g. following > ipfw output.The pipes configuration does mean nothing, it will be > clear at the end of mail, where key moment will be described. > > [Out1] > <...> > 04701 pipe tablearg ip from table(2) to any in via em0 > 04801 pipe tablearg ip from any to table(3) out via em0 > 04901 allow ip from table(4) to any in via em0 > 05001 allow ip from any to table(4) out via em0 > 05101 fwd tcp from table(5) to any dst-port > 80,443,8828 in via em0 > <...> > > > We'v noticed that no packets from specific ip(10.121.241.23) reache > 5101 rule with fwd to example.server. > > This ip is in table 5: > # ipfw table 5 list > 10.10.122.23/32 0 > 10.10.122.167/32 0 > > We’ve parsed all tables and no matches. > OK, we started placing debug rules to realize which rule accepts > packets. > > And we found out following.If we place the following debug rule(we > used the same fwd rule) such way(added 4602 rule): > [Out2] > <...> > 04602 113 75 fwd tcp from table(5) to any dst-port > 80,443,8828 in via em0 <-- OK her > 04701 107971113 85095893815 pipe tablearg ip from table(2) to any in > via em0 > 04801 102517924 83276945675 pipe tablearg ip from any to table(3) > out via em0 > 04901 4413338 991348968 allow ip from table(4) to any in via em0 > 05001 7146323 8293221022 allow ip from any to table(4) out via em0 > 05101 0 0 fwd tcp from table(5) to any dst-port > 80,443,8828 in via em0 > <...> > > Then packets match the rule.But if we delete 4602 and place debug > rule at 4702: > > [Out3] > <...> > 04701 108458823 85372134891 pipe tablearg ip from table(2) to any in > via em0 > 04702 0 0 fwd tcp from table(5) to any dst-port > 80,443,8828 in via em0 <-- NOT WORKING > 04801 - - pipe tablearg ip from any to table(3) out via em0 > 04901 - - allow ip from table(4) to any in via em0 > 05001 - - allow ip from any to table(4) out via em0 > 05101 0 0 fwd tcp from table(5) to any dst-port > 80,443,8828 in via em0 > <...> > > So placing rule after 4701 gives zero counters, that means that our > ip packets match 4701 rule :) > > But we DO NOT HAVE target ip in table 2. It resides only in table 5 > as shown before.But it must be noticed that such rule WAS in table 2 > before.But then was removed from table 2 and added to table 6. > > Records in table 2 looks like that: > # ipfw table 2 list > 10.10.122.20/32 9 > 10.10.122.21/32 4 > 10.10.122.25/32 9 > 10.10.122.28/32 6 > 10.10.122.30/32 6 > > We also thought that mb we added missconfigured rule e.g. > 10.10.122.0/24 rule in table 2 but no. > > > > Here goes the KEY moment! > OK crawling through the logs, different tests etc we decide to clear > table 2. > At first step, we’ve deleted all records manually, with: > ipfw table 2 delete > > and NO effect at the time table was clear.So there were no records > in table 2, but rule 4701 was still catching packets from the target > ip. > > Second, we did flush with > ipfw table 2 flush > And voila, everything went fine from that moment! Miracle flush? > > So the problem seems like the rule resides deep in the kernel heart, > but we can NOT see this rule with ipfw output. > > > So i think there are at least to questions: > > 1. Have anyone ever met such situation? Or may be something close to > this one with 'hidden' ipfw rules? I have never seen it.. > 2. Is there a way how to get more info about rules and firewall > matching decisions? Mb some sysctl tuning or something else? Cause > its the first time we met such situation and don’t even imagine how > to diagnose such 'hidden' rule:( turn on logging and add 'log' to each rule. (we probably should have an option to turn on logging by default but I don't know of such). > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > >