From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 13:09:37 2003 Return-Path: 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 6E31737B401 for ; Fri, 18 Apr 2003 13:09:37 -0700 (PDT) Received: from web10410.mail.yahoo.com (web10410.mail.yahoo.com [216.136.128.123]) by mx1.FreeBSD.org (Postfix) with SMTP id D915443FB1 for ; Fri, 18 Apr 2003 13:09:36 -0700 (PDT) (envelope-from opolyakov@yahoo.com) Message-ID: <20030418200936.82331.qmail@web10410.mail.yahoo.com> Received: from [67.112.212.200] by web10410.mail.yahoo.com via HTTP; Fri, 18 Apr 2003 13:09:36 PDT Date: Fri, 18 Apr 2003 13:09:36 -0700 (PDT) From: Oleg Polyakov To: Jeremy Chadwick , freebsd-net@freebsd.org In-Reply-To: <20030418174956.GA71335@parodius.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2003 20:09:37 -0000 You may want to comment out line: // transfer-source 10.0.0.1; Transfers to 10.0.0.0 should choose address 10.0.0.1 automagically. Transfers elsewhere should use zone-relevant transfer-source option. --- Jeremy Chadwick wrote: > Greetings. I've spoken with numerous other administrators > about the phenomenon I'm about to post, and the only answer > I've gotten so far is "Your box is broken" (how quaint). I > have two web/nameservers, both which exhibit this behaviour. > There's much mystery involved in this problem, so this post > will be long and verbose. > > The problem: BIND-8 looks to be sending packets destined for > my RFC 1918 subnet (10.0.0.0/8) over my _WAN interface_. > Since I have overly anal firewall rules to block this sort-of > thing, what I see numerous times a day (at irregular intervals) > are _outgoing_ packets being blocked. > > First, let's start with the machine NIC/network topology. There > are two physical NICs in my nameservers: one public interface > and one private, using entirely separate switches to segregate > the traffic. The public interface NIC has multiple IPs assigned > to it (IP aliases). Here's ifconfig: > > fxp0: flags=8843 mtu 1500 > inet 64.71.184.170 netmask 0xffffffe0 broadcast 64.71.184.191 > inet 64.71.184.171 netmask 0xffffffff broadcast 64.71.184.171 > inet 64.71.184.172 netmask 0xffffffff broadcast 64.71.184.172 > inet 64.71.184.173 netmask 0xffffffff broadcast 64.71.184.173 > inet 64.71.184.175 netmask 0xffffffff broadcast 64.71.184.175 > inet 64.71.184.176 netmask 0xffffffff broadcast 64.71.184.176 > inet 64.71.184.177 netmask 0xffffffff broadcast 64.71.184.177 > inet 64.71.184.178 netmask 0xffffffff broadcast 64.71.184.178 > inet 64.71.184.179 netmask 0xffffffff broadcast 64.71.184.179 > ether 00:e0:81:02:3c:88 > media: Ethernet autoselect (100baseTX ) > status: active > fxp1: flags=8843 mtu 1500 > inet 10.0.0.1 netmask 0xff000000 broadcast 10.255.255.255 > ether 00:e0:81:02:3c:89 > media: Ethernet autoselect (100baseTX ) > status: active > lo0: flags=8049 mtu 16384 > inet 127.0.0.1 netmask 0xff000000 > > My routing table: > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 64.71.184.161 UGSc 63 109070 fxp0 > 10 link#2 UC 3 0 fxp1 > 10.0.0.2 00:e0:81:04:69:e2 UHLW 8 1263590 fxp1 1053 > 10.0.0.128 00:04:ea:9c:2d:c1 UHLW 0 14822 fxp1 966 > 10.0.0.129 00:c0:05:01:60:fe UHLW 0 263 fxp1 1023 > 64.71.184.160/27 link#1 UC 5 0 fxp0 > 64.71.184.161 00:03:6b:50:1a:21 UHLW 62 0 fxp0 978 > 64.71.184.162 00:90:27:e0:0f:70 UHLW 0 2 fxp0 1053 > 64.71.184.170 00:e0:81:02:3c:88 UHLW 0 25583 lo0 > 64.71.184.171/32 link#1 UC 0 0 fxp0 > 64.71.184.172/32 link#1 UC 0 0 fxp0 > 64.71.184.173/32 link#1 UC 0 0 fxp0 > 64.71.184.175/32 link#1 UC 0 0 fxp0 > 64.71.184.176/32 link#1 UC 0 0 fxp0 > 64.71.184.177/32 link#1 UC 0 0 fxp0 > 64.71.184.178 00:e0:81:02:3c:88 UHLW 0 19203 lo0 => > 64.71.184.178/32 link#1 UC 1 0 fxp0 > 64.71.184.179/32 link#1 UC 0 0 fxp0 > 64.71.184.189 00:e0:81:04:69:e1 UHLW 0 99 fxp0 > 64.71.184.190 link#1 UHLW 1 12 fxp0 > 127.0.0.1 127.0.0.1 UH 2 246142 lo0 > > My firewalling rules are set up as follows (please note rule 400, > and the packet counters on rule 1005): > > 00100 580884 73786974 allow ip from any to any via lo0 > 00200 0 0 deny ip from any to 127.0.0.0/8 > 00300 0 0 deny ip from 127.0.0.0/8 to any > 00400 2507920 940337032 allow ip from any to any via fxp1 > 01000 0 0 deny log ip from any to 10.0.0.0/8 in recv fxp0 > 01005 195 52392 deny log ip from 10.0.0.0/8 to any out xmit fxp0 > 01100 0 0 deny log ip from any to 172.16.0.0/12 in recv fxp0 > 01105 0 0 deny log ip from 172.16.0.0/12 to any out xmit > fxp0 > 01200 0 0 deny log ip from any to 192.168.0.0/16 in recv > fxp0 > 01205 0 0 deny log ip from 192.168.0.0/16 to any out xmit > fxp0 > > syslog security shows the following for the denied on rule 1005 > (this is just a snippet): > > Apr 18 08:53:45 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > Apr 18 09:35:13 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > Apr 18 10:01:21 pentarou /kernel: ipfw: 1005 Deny UDP 10.0.0.1:53 > 64.71.184.190:53 out via fxp0 > > syslog for named shows corresponding entries, verifying that BIND > does look to be sending things out on the wrong interface (the > entries below report Permission denied due to my firewalling > rules above): > > Apr 18 08:53:45 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > Apr 18 09:35:13 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > Apr 18 10:01:21 pentarou named[49497]: ns_req: sendto([64.71.184.190].53): > Permission denied > > What is happening should not even be technically possible, if I > understand things correctly. > > Applicable pieces of my BIND-8 configuration are as follows: > > options { > query-source address 64.71.184.171; > transfer-source 10.0.0.1; > > listen-on { > 127.0.0.1; > 10.0.0.1; > 64.71.184.171; > }; > }; > > Then, in zones I wish to slave via the WAN interface, I insert > the following into the zone block (example included): > > zone "malkavian.com" in { > type slave; > notify no; > file "../zones/zone.malkavian.com"; > allow-transfer { 216.66.32.72; }; > masters { 216.66.32.72; }; > transfer-source 64.71.184.171; > }; > > Non-WAN zones (which should be transferred over the private > interface) look to be as follows (I use TSIG just because): > > zone "deltaplayer.com" in { > type master; > file "../zones/zone.deltaplayer.com"; > allow-transfer { key pentarou-gabriel-LAN; }; > }; > > I'd also like to throw in the fact that I have tried BIND-9 > on this exact setup, adding "notify-source" entries where > appropriate, and I _still witnessed the same behaviour_ (and > on a much larger scale none the less!). > > Finally, here's the twist which makes absolutely no sense > to me what-so-ever: > > To try and find out what sort-of packets were being sent > across the WAN with a src address of 10.0.0.1, I ran tcpdump > as follows, and went to bed for about 8 hours: > > $ tcpdump -p -ifxp0 -l -n -s8192 -X "src net 10.0.0.0/8" > > During those 8 hours, ipfw reported numerous outgoing packets > being blocked (rule 1005) -- but tcpdump showed _absolutely > nothing_. > > I'd _REALLY_ love to get to the bottom of this, as there is > obviously a bug somewhere, and I have a feeling this kind-of > issue could easily become one of folks saying "BIND is buggy" > and the ISC folks saying "FreeBSD is broken." > > Advice/comments/questions would be greatly appreciated, as > I'm extremely frustrated with this entire situation, and not > sure where to turn. > > Thanks. > > -- > | Jeremy Chadwick jdc@parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. | > > _______________________________________________ > 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" __________________________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo http://search.yahoo.com