From owner-freebsd-questions@freebsd.org Fri Mar 24 09:22:04 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E85D6CA1585 for ; Fri, 24 Mar 2017 09:22:04 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from bede.home.qeng-ho.org (bede.qeng-ho.org [217.155.128.241]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "fileserver.home.qeng-ho.org", Issuer "fileserver.home.qeng-ho.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 691871222 for ; Fri, 24 Mar 2017 09:22:03 +0000 (UTC) (envelope-from freebsd@qeng-ho.org) Received: from arthur.home.qeng-ho.org (arthur.home.qeng-ho.org [172.23.1.2]) by bede.home.qeng-ho.org (8.15.2/8.15.2) with ESMTP id v2O9M0j3060369; Fri, 24 Mar 2017 09:22:01 GMT (envelope-from freebsd@qeng-ho.org) Subject: Re: Restaarting PF and its effects on jails and vms To: Odhiambo Washington References: Cc: "James B. Byrne" , User Questions From: Arthur Chance Message-ID: <2ba51e04-6065-b21a-367f-1137ab22d2bc@qeng-ho.org> Date: Fri, 24 Mar 2017 09:22:00 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Mar 2017 09:22:05 -0000 On 24/03/2017 09:16, Odhiambo Washington wrote: > On 24 March 2017 at 11:20, Arthur Chance wrote: > >> On 23/03/2017 18:29, James B. Byrne via freebsd-questions wrote: >>> I am revising the pf configuration for the FreeBSD-10.3 host of a >>> number of FreeBSD-11.0 BHyve instances. When I restart PF on the host >>> then traffic to a number of guests gets blocked even though the >>> ruleset says it should not be. >>> >>> Since the incoming ports for the blocked traffic appear to be from the >>> upper dynamic range I infer that this traffic is related to >>> connections established before PF was restarted and are now 'orphaned' >>> in consequence. In other words, had the initial connection between >>> client anf service been made while PF was already running the traffic >>> being blocked following a restart would have been let through as being >>> part of an established connection. >>> >>> What is the recommended way of dealing with this issue when restarting >>> PF, if there is one? >> >> Don't restart pf, reload it. "service pf reload" goes to great lengths >> not to interfere with existing connections whereas "service pf restart" >> blows away everything before restarting. >> >> This is fresh in my mind because I made exactly the same mistake last >> week before remembering to reload. :-) >> > > A quick one, before I get to RTFM, is there an equivalent 'reload' option > for pfctl (9.3-STABLE)? > It's all pfctl. By using service(8) I was referring to the rc.d script for pf, but that sits over pfctl. The reload part is (on 10.3) pf_reload() { echo "Reloading pf rules." $pf_program -n -f "$pf_rules" || return 1 # Flush everything but existing state entries that way when # rules are read in, it doesn't break established connections. $pf_program -Fnat -Fqueue -Frules -FSources -Finfo -FTables -Fosfp > /dev/null 2>&1 $pf_program -f "$pf_rules" $pf_flags } Apologies if my mailer breaks the long line. -- By June 1949, people had begun to realize that it was not so easy to get a program right as had at one time appeared. It was on one of my journeys between the EDSAC room and the punching equipment that the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs. -- Maurice Wilkes