From owner-freebsd-net@FreeBSD.ORG  Fri Apr 18 14:54:01 2003
Return-Path: <owner-freebsd-net@FreeBSD.ORG>
Delivered-To: freebsd-net@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 74A4037B401
	for <freebsd-net@freebsd.org>; Fri, 18 Apr 2003 14:54:01 -0700 (PDT)
Received: from ints.mail.pike.ru (ints.mail.pike.ru [195.9.45.194])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 122F443FAF
	for <freebsd-net@freebsd.org>; Fri, 18 Apr 2003 14:54:00 -0700 (PDT)
	(envelope-from babolo@cicuta.babolo.ru)
Received: (qmail 70136 invoked from network); 18 Apr 2003 22:11:36 -0000
Received: from babolo.ru (HELO cicuta.babolo.ru) (194.58.226.160)
  by ints.mail.pike.ru with SMTP; 18 Apr 2003 22:11:36 -0000
Received: (nullmailer pid 668 invoked by uid 136);
	Fri, 18 Apr 2003 21:56:56 -0000
X-ELM-OSV: (Our standard violations) hdr-charset=KOI8-R; no-hdr-encoding=1
In-Reply-To: <20030418201645.GA77986@parodius.com>
To: Jeremy Chadwick <freebsd@jdc.parodius.com>
Date: Sat, 19 Apr 2003 01:56:56 +0400 (MSD)
From: "."@babolo.ru
X-Mailer: ELM [version 2.4ME+ PL99b (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Message-Id: <1050703016.604363.667.nullmailer@cicuta.babolo.ru>
cc: freebsd-net@freebsd.org
Subject: Re: BIND-8/9 interface bug? Or is it FreeBSD?
X-BeenThere: freebsd-net@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Networking and TCP/IP with FreeBSD <freebsd-net.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-net>
List-Post: <mailto:freebsd-net@freebsd.org>
List-Help: <mailto:freebsd-net-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-net>,
	<mailto:freebsd-net-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Apr 2003 21:54:01 -0000

> 
>         By the way, something I didn't cover: 64.71.184.190 is our
>         secondary nameserver's WAN IP.  It's private is 10.0.0.2.
That can be the key - if secondary server
request your private master using public IP

>         I'm still wondering why tcpdump isn't catching the I/O...
Your ipfw rules forbid packets
before interface you are looking for.
Just ipfw forward them to another interface to catch them.