From owner-freebsd-questions@FreeBSD.ORG Tue Aug 20 18:41:33 2013 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 265BDF14 for ; Tue, 20 Aug 2013 18:41:33 +0000 (UTC) (envelope-from lists.dan@gmail.com) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DAA1D23A4 for ; Tue, 20 Aug 2013 18:41:32 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id f14so540594qak.9 for ; Tue, 20 Aug 2013 11:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sW04y/yFk55OSA7WOGp7uJovq5EkYPF+10XQovHeHtQ=; b=ExUtkS4MK2w76SmPCIIHNdbF8yoy9kg9+02X2/57/5fbhhZP0DZljTh+h54JoIBBUW tKBpGcrYriStVQ+b/1/C4lQuPUuDV6Xi774gdNf+YbrtQc+nXzoapzHSXS/xXvDvf2p0 v9iA+9jMvXMdddab17x1xDgOFHk/SvKtljJYMiB8U5nUkzvA1wHoSYqgm2ONLSecIH+7 PTUJuWfpidqrzcXBI5vuC53lNWkVFAB/dWSiBe5Cai0KstWrA1owFvcs3mvITMGftog2 KUSbJAx/ZJ6/ueN3w4XMtE6N1FEtJJGV5T807gUpf0YyJA7mRn/q7NkiyMzZAxvfmPEO I4wQ== MIME-Version: 1.0 X-Received: by 10.224.35.196 with SMTP id q4mr3331105qad.106.1377024091958; Tue, 20 Aug 2013 11:41:31 -0700 (PDT) Received: by 10.224.218.134 with HTTP; Tue, 20 Aug 2013 11:41:31 -0700 (PDT) In-Reply-To: <52128B95.30006@blackfoot.net> References: <5211B5E1.6040000@blackfoot.net> <52128B95.30006@blackfoot.net> Date: Tue, 20 Aug 2013 13:41:31 -0500 Message-ID: Subject: Re: ipfw confusion From: Dan Lists To: Gary Aitken Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Mailing List X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Aug 2013 18:41:33 -0000 You might turn on logging and post the logs of what is being blocked. Sometimes things are being blocked by rules you do not expect. On Mon, Aug 19, 2013 at 4:18 PM, Gary Aitken wrote: > On 08/19/13 00:36, Jason Cox wrote: > > Are you sure that your DNS requests are over TCP? DNS primarily uses UDP > to > > serve requests. TCP is used when the response data size exceeds 512 bytes > > (I think), or for tasks such as zone transfers. I know a few resolver > > implementations use TCP for all queries, but most I have used not. You > > might want to add rules to allow UDP as well. > > There are identical rules included for udp: > > 21149 allow udp from any to 12.32.44.142 dst-port 53 in via tun0 keep-state > 21169 allow udp from any to 12.32.36.65 dst-port 53 in via tun0 keep-state > > One of the requests which is being refused is a zone transfer request from > a secondary which is a tcp request. Others are probably udp. > > > On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken >wrote: > > > >> I'm having some weird ipfw behavior, or it seems weird to me, and am > >> looking > >> for an explaination and then a way out. > >> > >> ipfw list > >> ... > >> 21109 allow tcp from any to 12.32.44.142 dst-port 53 in via tun0 setup > >> keep-state > >> 21129 allow tcp from any to 12.32.36.65 dst-port 53 in via tun0 setup > >> keep-state > >> ... > >> 65534 deny log logamount 5 ip from any to any > >> > >> tail -f messages > >> Aug 18 23:33:06 nightmare named[914]: client 188.231.152.46#63877: error > >> sending response: permission denied > >> > >> 12.32.36.65 is the addr of the internal interface (xl0) on the firewall > >> and is the public dns server. > >> 12.32.44.142 is the addr of the external interface (tun0) which is > bridged > >> on a > >> dsl line. > >> > >> It appears that a dns request was allowed in, but the response was not > >> allowed > >> back out. It seems to me the above rules 21109 and 21129 should have > >> allowed > >> the request in and the response back out. > >> > >> It's possible a request could come in on 12.32.44.142, > >> which is why 21109 is present; > >> although I know I am getting failures to reply to refresh requests > >> from a secondary addressed to 12.32.36.65 > >> > >> What am I missing? > >> > >> Is there a problem if the incoming rule is for tun0, > >> which gets passed to named > >> since 12.32.44.142 is on the physical machine running named, > >> but named pumps its response out on 12.32.36.65, > >> relying on routing to get it to the right place, > >> and that fails to match the state tracking mechanism > >> which started with 12.32.44.142? > >> _______________________________________________ > >> freebsd-questions@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-questions > >> To unsubscribe, send any mail to " > >> freebsd-questions-unsubscribe@freebsd.org" > >> > > > > > > > > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to " > freebsd-questions-unsubscribe@freebsd.org" >