From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 25 05:12:49 2006 Return-Path: X-Original-To: freebsd-ipfw@freebsd.org Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 488A616A412; Wed, 25 Oct 2006 05:12:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mx18.yandex.ru (smtp2.yandex.ru [213.180.200.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 198A443D53; Wed, 25 Oct 2006 05:12:47 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.kirov.so-cdu.ru ([81.18.142.225]:22532 "EHLO [127.0.0.1]" smtp-auth: "bu7cher" TLS-CIPHER: "DHE-RSA-AES256-SHA keybits 256/256 version TLSv1/SSLv3" TLS-PEER-CN1: ) by mail.yandex.ru with ESMTP id S3377276AbWJYFMg (ORCPT + 1 other); Wed, 25 Oct 2006 09:12:36 +0400 X-Comment: RFC 2476 MSA function at smtp2.yandex.ru logged sender identity as: bu7cher Message-ID: <453EF241.4020706@yandex.ru> Date: Wed, 25 Oct 2006 09:12:33 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: Julian Elischer References: <453DF0A7.6030700@yandex.ru> <453E71F8.7020809@elischer.org> In-Reply-To: <453E71F8.7020809@elischer.org> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Oleg Bulyzhin , Luigi Rizzo Subject: Re: ipfw tracing 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, 25 Oct 2006 05:12:49 -0000 Julian Elischer wrote: >> What you think about that? >> > Can you show some sample usage and output? Sorry, i don't have patched ipfw on production servers and can show only syntetic example. Let us suppose that we have a lots of rules on the our gateway (allow, deny, skipto, pipe, divert, etc). And we have a task - permit an access from some host A to some host B. This can be easy by adding a permit rule into some place at the head of rules. But i got used to store some related rules in the blocks and don't want to have a random sequences of rules. The tracing is simple way to determine which a rules process our packets. We add a tagging rule in the head of rules and begin tracing. Example: # ipfw add 1 count tag 123 ip from any to 239.192.2.21 # sysctl net.inet.ip.fw.trace_tag=123 # tail -f /var/log/security Oct 25 09:08:07 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:07 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:07 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.221:1102 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 1 Count UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 1014 SkipTo 2050 UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 Oct 25 09:08:08 btr-nb kernel: ipfw: 65535 Deny UDP 172.21.81.222:1089 239.192.2.21:4545 in via nve0 I think this feature can be usable, but needed some limiting.. -- WBR, Andrey V. Elsukov