Date: Sun, 18 Aug 2013 23:36:38 -0700 From: Jason Cox <cscoman@gmail.com> To: Gary Aitken <vagabond@blackfoot.net> Cc: FreeBSD Mailing List <freebsd-questions@freebsd.org> Subject: Re: ipfw confusion Message-ID: <CAC4WUHpPD_Ga6LGWQYU9zPn80ZG84zh93ddOr6aVMcNCbeN47w@mail.gmail.com> In-Reply-To: <5211B5E1.6040000@blackfoot.net> References: <5211B5E1.6040000@blackfoot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. On Sun, Aug 18, 2013 at 11:06 PM, Gary Aitken <vagabond@blackfoot.net>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" > -- Jason Cox
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAC4WUHpPD_Ga6LGWQYU9zPn80ZG84zh93ddOr6aVMcNCbeN47w>