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
signature.asc
Description: PGP signature
