Date: Fri, 29 Jun 2018 13:09:49 +0200 From: Marek Zarychta <zarychtam@plan-b.pwste.edu.pl> To: Kristof Provost <kristof@sigsegv.be> Cc: freebsd-pf@freebsd.org Subject: Re: pfr_update_stats: assertion failed. Message-ID: <20180629110949.GA7595@plan-b.pwste.edu.pl> In-Reply-To: <5D8E4DA7-3984-47DE-89E7-2B731525573C@sigsegv.be> References: <20161016181713.GA95110@plan-b.pwste.edu.pl> <20180623152729.GA81271@plan-b.pwste.edu.pl> <20180623164616.GA82672@plan-b.pwste.edu.pl> <322F58D6-B7CA-4F78-A860-D43E4F07E402@sigsegv.be> <20180624190726.GA6807@plan-b.pwste.edu.pl> <5D8E4DA7-3984-47DE-89E7-2B731525573C@sigsegv.be>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
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
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
iQEzBAABCAAdFiEEMOqvKm6wKvS1/ZeCdZ/s//1SjSwFAls2E3oACgkQdZ/s//1S
jSwmXgf/RW7kM99fQlE3eB6PmTz9vb80G9choRSh8H2yAMFzmHl0PEGbDSNptaGV
8u0+Dxtz6qDXft6B6qHvtt8s0CaoJbySQZKb8KITB1qnMJnBUftvLfW6A92Ej0IE
xbeckq22Zxrtks5JgaL05qLmXEZXjW5wiFSS5ZCRZfc5l5Nj+u7p2Wc60No1n2Ti
xoSkeIgzBzRm6HcIQBU7+tRfXv+89h54n7f37jSiE4mBQzuQxrIMbLKmaaFRDltC
rNuOnGzQcceyMvIu/xOqe3OWU2NmjUfsXXCrcK/Uqu4cE5Yx47FcA8bQ8D2zn2ry
S1eqy934cTNyJzx1N08kzYNlomQRxQ==
=4Ih1
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180629110949.GA7595>