ipfw confusion

[Gary Aitken]

On 08/20/13 12:41, Dan Lists wrote:
> 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.

Thanks for the suggestion.
I was seeing refusals from named and mistakenly interpreting them 
as ipfw issues.

> On Mon, Aug 19, 2013 at 4:18 PM, Gary Aitken <vagabond at 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 at 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?