Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Feb 2019 12:49:47 -0500
From:      "James B. Byrne" <byrnejb@harte-lyne.ca>
To:        freebsd-questions@freebsd.org
Subject:   Re: pf filter settings
Message-ID:  <84e067c2d768e3fa7e1d090ab9c33418.squirrel@webmail.harte-lyne.ca>
In-Reply-To: <mailman.112.1549540802.65464.freebsd-questions@freebsd.org>
References:  <mailman.112.1549540802.65464.freebsd-questions@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help


On Wed, February 6, 2019 10:50, Matthew Seaman wrote:
> On 06/02/2019 14:48, James B. Byrne via freebsd-questions wrote:
>> What is going on?  Why is the rule 'block drop    in  log   all'
>> have effect and the rule
>>
>> pass              log   quick on $int_if \
>>                    from  { self $int_if:network } \
>>                    to    { self $int_if:network }
>>
>> does not, despite the quick option and the fact that it occurs
>> first.
>
> Because pf always applies the *last* matching rule.  It's the opposite
> way round to ipfw(8).

The 'quick' option is suppose to pre-empt the default behaviour.

>
> In general, you want to order your pf ruleset from the most general to
> the most specific.  You can short-circuit searching the whole ruleset
> by using the 'quick' modifier -- use this on early and more general
> rules to weed out the obviously wrong traffic.

Which did not have the expected effect in this case.

>
> Also, read the docco on:
>
> set skip on { $int_if }
>
> which should achieve what you you want (assuming that you're only
> logging traffic on that i/f as a debugging thing.)
>

I did that as a workaround whilst investigating the source of the
difficulty.  Which appears to turn on the difference between
implementations of the network stack on Linux and FreeBSD and my
general ignorance about things network beyond the superficial.

I have not acquired enough knowledge to explain what is going on but
the treatment of packets arriving from differing subnets on the same
interface seems to be the critical element.  Because the packets
appear to arrive from differing networks than the destination they
considered they are treated differently than those appearing from and
going to the same network even when both arrive and depart on the same
interface.  Which they have to because there is only one internal i/f
to use.

This differs from the default behaviour of CentOS that I am most
familiar with.  I am still trying understand what that difference is
exactly.



-- 
***          e-Mail is NOT a SECURE channel          ***
        Do NOT transmit sensitive data via e-Mail
 Do NOT open attachments nor follow links sent by e-Mail

James B. Byrne                mailto:ByrneJB@Harte-Lyne.ca
Harte & Lyne Limited          http://www.harte-lyne.ca
9 Brockley Drive              vox: +1 905 561 1241
Hamilton, Ontario             fax: +1 905 561 0757
Canada  L8E 3C3




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?84e067c2d768e3fa7e1d090ab9c33418.squirrel>