Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 20 Aug 2013 13:41:31 -0500
From:      Dan Lists <lists.dan@gmail.com>
To:        Gary Aitken <vagabond@blackfoot.net>
Cc:        FreeBSD Mailing List <freebsd-questions@freebsd.org>
Subject:   Re: ipfw confusion
Message-ID:  <CAPW8bZ3msjKb4S6j_zw%2BxQzBNORLkM3LLcV_2RVvTfd0-v_wgQ@mail.gmail.com>
In-Reply-To: <52128B95.30006@blackfoot.net>
References:  <5211B5E1.6040000@blackfoot.net> <CAC4WUHpPD_Ga6LGWQYU9zPn80ZG84zh93ddOr6aVMcNCbeN47w@mail.gmail.com> <52128B95.30006@blackfoot.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <vagabond@blackfoot.net> 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 <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"
> >>
> >
> >
> >
>
> _______________________________________________
> 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"
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPW8bZ3msjKb4S6j_zw%2BxQzBNORLkM3LLcV_2RVvTfd0-v_wgQ>