On 2015-10-27, Michael S. Keller <keller.michae...@gmail.com> wrote:
> On 10/27/15 3:42 AM, Stuart Henderson wrote:
>> On 2015-10-26, Giancarlo Razzolini <grazzol...@gmail.com> wrote:
>>> I suggest you move your match rules to the beginning of the ruleset and
>>> use log on them. So you can watch your pflog interface and see the
>>> packets being triggered. Also, you can (should) always use tags. Not
>>> only they make your ruleset "debugable", but any stray packet should hit
>>> a block rule (possibly logging it). I suspect your first three rules
>>> aren't matching because you're using the external interface. Try using
>>> the internal on them.
>>
>> Also: have the first "action" rule block everything ("block log" probably).
>> Then you can be sure that all packets match one of your rules (and don't get
>> accepted by the implicit default 'pass flags any no state' rule).
>>
>
> These are the rules that appear potentially to affect outgoing packets
> on the internal interface:
>
> match inet from any to 192.168.1.62
> block drop out on gem0 all
> pass out on gem0 inet from any to 192.168.1.0/24 flags S/SA
>
> Only traffic that initiates directly from the OpenBSD firewall triggers
> these rules. Neither web page loads (which traverse the NAT) nor SSH
> session replies increase the trigger counts on any of these three rules.
>
> -Michael
>
>
I mean literally
block log
then put your other rules after it. It is too much hassle to work out
if there are rules to cover every packet that might pass through the
system, putting 'block log' up-front makes it clear so that every
packet will have to match one of the rules in your ruleset, rather
than matching the invisible implicit default rule.
"match inet from any to 192.168.1.62" doesn't do anything. "match" is
a modifier for other rules ("log", "tag", "queue" are common things to
use in a match rule), but your match line doesn't make any changes.
