pfr_update_stats: assertion failed.

[Marek Zarychta]

On Sun, Jun 24, 2018 at 09:28:19PM +0200, Kristof Provost wrote:
> The only thing I can suggest is to look at the code and work out where 
> the op_pass value comes from (and perhaps also what it’s used for. Why 
> is PRF_OP_XPASS better than !PFR_OP_PASS?
> 
> It’s still present (though perhaps not logged) in OpenBSD too.

I have made some changes to PF code to be even more verbose here and
finally realized where the problem was.

There were three internal interfaces on the host: int_if1, int_if2 and
if_if3 - interfaces addressed in different subnets of RFC1918 space, a
table: table  <reserved> (corvering the whole RFC1918 adress space) and
a set of rules including: 
(...)
rule A: 
rdr pass on {$int_if1, $int_if2, $int_if3} inet proto tcp to self port 80 -> 127.0.0.1 port 58080
(...) 
rule B:
block in quick on {$int_if1, $int_if2, $int_if3} to <reserved>
(...)

The rules are seemingly contrary to each other in case the table
<reserved> contains addresses of all internal interfaces. The rule A was
usually covered when the packet designed for int_if1 was received on
int_if1 and there were some rules, not shown here, which allowed to pass
in such a traffic. But sometimes it was also triggered when the packet
designed for int_if1 was received on int_if2 or int_if3 and only, in
this case, (op_pass != PFR_OP_PASS) was fulfilled.

I wonder why this has never happened for PF used in FreeBSD 8 branch?
Maybe the change in pf.conf which has been made after upgrade altered
the syntax of pf.conf in a significant way, far more than I expected.

So let me apologise for the noise here. Please keep the code unchanged
and thank you for the help.

Best regards,
-- 
Marek Zarychta
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-pf/attachments/20180629/166867af/attachment.sig>