From owner-freebsd-bugs@freebsd.org Wed Jul 25 21:59:49 2018 Return-Path: Delivered-To: freebsd-bugs@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 E6FD310552D6 for ; Wed, 25 Jul 2018 21:59:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6D54B8FF40 for ; Wed, 25 Jul 2018 21:59:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 2F2B410552D4; Wed, 25 Jul 2018 21:59:48 +0000 (UTC) Delivered-To: bugs@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 1DE4910552D3 for ; Wed, 25 Jul 2018 21:59:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3AE98FF3B for ; Wed, 25 Jul 2018 21:59:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 079AC27E18 for ; Wed, 25 Jul 2018 21:59:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w6PLxkvn026008 for ; Wed, 25 Jul 2018 21:59:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w6PLxkWf026007 for bugs@FreeBSD.org; Wed, 25 Jul 2018 21:59:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 229241] pfctl -f /etc/pf.conf blocks loopback interface Date: Wed, 25 Jul 2018 21:59:47 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.2-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dd@goboomtown.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2018 21:59:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D229241 Daniel Duerr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dd@goboomtown.com --- Comment #10 from Daniel Duerr --- Hi all, We are noticing very similar behavior on 11.2-RELEASE after recently upgrad= ing from 11.1-RELEASE-p11. Our pf.conf rule set is the same as it was on 11.1.= =20 Like the original poster here, we had been using "set skip on { lo }" (e.g.= the interface group). Changing to "set skip on { lo0 }" doesn't really seem to change the behavior. Also, we only have one lo0 loopback interface -- no additional ones. We also are not using jails. On boot, everything works as expected. After some time, pf starts blocking traffic on lo0. From there, reloading the rules has mixed effects -- somet= imes it restores lo0 and sometimes it does not. The only consistent way we seem= to be able to control the behavior once it starts is using `pfctl -d` and `pfc= tl -e`. In other words, if the problem is happening, disabling pf will restore traffic on lo0 immediately. If we then re-enable pf, it will block traffic again on lo0 immediately. Daniel --=20 You are receiving this mail because: You are the assignee for the bug.=