From owner-freebsd-pf@freebsd.org Fri Jun 29 11:09:54 2018 Return-Path: Delivered-To: freebsd-pf@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64E741037677 for ; Fri, 29 Jun 2018 11:09:54 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (plan-b.pwste.edu.pl [IPv6:2001:678:618::40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "plan-b.pwste.edu.pl", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D43A8865B9 for ; Fri, 29 Jun 2018 11:09:53 +0000 (UTC) (envelope-from zarychtam@plan-b.pwste.edu.pl) Received: from plan-b.pwste.edu.pl (zarychtam@localhost [127.0.0.1]) by plan-b.pwste.edu.pl (8.15.2/8.15.2) with ESMTPS id w5TB9oRd007940 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jun 2018 13:09:50 +0200 (CEST) (envelope-from zarychtam@plan-b.pwste.edu.pl) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=plan-b.pwste.edu.pl; s=plan-b-mailer; t=1530270590; bh=uqYpcPdEhjAIEsbdQdB2J5EVHz8/blRe4OmZs1Jy9eY=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=PZk6/YWJovJ7p2nbqnSrzLp1N6qYHbitodEL3avyXSGhxrzsp4D4Uc+rFL2k7t7ef fXblIAyXf49R0DmMSlrV7nFWiMOSl7O0QQbmJKi2UVNsFFQ/itE5lmgG1bMBDlJLKI s7/wXoOrk2VmwVh/E2oW6yb4EwUzdlNMGi6ameSfUF2D/6YaqOf9opqsZTmkao520D QorEk5P5H453l0GNH7Nm3mhRxL7MkM1Kw03vSQoQib568wqoNCMGUSZPgQDxrq1WvS QbxZE6K4jIh+cYBxZyoKSu1h7Y1DYiZ1Lsrtq4xnvOkkV+CpIfGwCP4w/AQfid8cno o2vOEpi3KuFBw== Received: (from zarychtam@localhost) by plan-b.pwste.edu.pl (8.15.2/8.15.2/Submit) id w5TB9ncF007939; Fri, 29 Jun 2018 13:09:49 +0200 (CEST) (envelope-from zarychtam) Date: Fri, 29 Jun 2018 13:09:49 +0200 From: Marek Zarychta To: Kristof Provost Cc: freebsd-pf@freebsd.org Subject: Re: pfr_update_stats: assertion failed. Message-ID: <20180629110949.GA7595@plan-b.pwste.edu.pl> 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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: <5D8E4DA7-3984-47DE-89E7-2B731525573C@sigsegv.be> User-Agent: Mutt/1.10.0 (2018-05-17) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 11:09:54 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20 > the op_pass value comes from (and perhaps also what it=E2=80=99s used for= =2E Why=20 > is PRF_OP_XPASS better than !PFR_OP_PASS? >=20 > It=E2=80=99s 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 (corvering the whole RFC1918 adress space) and a set of rules including:=20 (...) rule A:=20 rdr pass on {$int_if1, $int_if2, $int_if3} inet proto tcp to self port 80 -= > 127.0.0.1 port 58080 (...)=20 rule B: block in quick on {$int_if1, $int_if2, $int_if3} to (...) The rules are seemingly contrary to each other in case the table 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 !=3D 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, --=20 Marek Zarychta --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" -----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----- --XsQoSWH+UP9D9v3l--