From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 10:50: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 F3C3837B401 for ; Fri, 18 Apr 2003 10:50:36 -0700 (PDT) Received: from mail.parodius.com (mail.parodius.com [64.71.184.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59A5643FAF for ; Fri, 18 Apr 2003 10:50:36 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: from pentarou.parodius.com (jdc@localhost [127.0.0.1]) by mail.parodius.com (8.12.9/8.12.9) with ESMTP id h3IHnujU072222 for ; Fri, 18 Apr 2003 10:49:56 -0700 (PDT) (envelope-from jdc@pentarou.parodius.com) Received: (from jdc@localhost) by pentarou.parodius.com (8.12.9/8.12.9/Submit) id h3IHnuxK072221 for freebsd-net@freebsd.org; Fri, 18 Apr 2003 10:49:56 -0700 (PDT) Date: Fri, 18 Apr 2003 10:49:56 -0700 From: Jeremy Chadwick To: freebsd-net@freebsd.org Message-ID: <20030418174956.GA71335@parodius.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: 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 17:50:37 -0000 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. |