From owner-freebsd-questions@freebsd.org Fri Mar 24 09:27:48 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 5FC2CCA1883 for ; Fri, 24 Mar 2017 09:27:48 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1931F1509 for ; Fri, 24 Mar 2017 09:27:48 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id p22so6309413qka.3 for ; Fri, 24 Mar 2017 02:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dr1rEAK0hxS8M1shjKNm6P+51DRj3wivsln0bsmM/kk=; b=FHXDDDu/wJys+pn0mQ/tIzUI4PxAPrWjZaJVTrgNDmj7P2iBrt7Rev+uCatSHBvm74 t4sg2ZmqPWIutt8tUQoQuWEYUn3NsBZ6sNDptCrJ7PRj+uX7JxsnQPfUUUKWwXidr+pE hOnMkkPGkD4lmTNhzCe9uf5vT6pLOp1VrNhedBUf/oDPW4ut1P9by9ZbFBuIJKNpF2ob uu+/s9qj66BNFIXo2csPl38zF2MAyQJB7MYImQLNcb8yqXoR3HuJQ+37mZqcmUxOuNxb Cm45/vSBNddvRIqSjdWAC7c1UjPYfzF+miihmhmIo7kSTmzt2puZ94ZLRbh/iNOU5FO8 H/tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dr1rEAK0hxS8M1shjKNm6P+51DRj3wivsln0bsmM/kk=; b=Z89dbTPeogUgHWcgtz5jwK9G4FZhh119rDjb2tExcc8sQr8MUDVIePluwfBVfjs5m3 /wCHzTdOA5UI4PDj9ykpZkwKB3JV5siX29mr8T/NYCpfV+ubbLvPN2QToQ0DTUWnW8T0 J/ykcpzUV3mI1XT3MvbpzpjK+VbVIumf06e/8NGfF8NZUFiCGhuFao+e+g6enfOjoD7P 1Q++g9HAfFUgMrbByBhDlt1rjQvkeINOlLkm0ELUYN46eKHqD2wc5Qxi/uX+HitheQmv RR1rdVOjH/wSkJp8B3KPNkBPw6UOrjOvgvW1/1fHyjzdEeiDM3frAwNMiSTPQYYctPke 7PjA== X-Gm-Message-State: AFeK/H3nLPYOblg+O8fXsBNqWB1GvWWhcF9FQf+MNaCl4IZrPkVwSIrDSboC5/Votnq5/hVLRsRNecAGwlCBnQ== X-Received: by 10.55.49.130 with SMTP id x124mr215866qkx.63.1490347667283; Fri, 24 Mar 2017 02:27:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.74.149 with HTTP; Fri, 24 Mar 2017 02:27:06 -0700 (PDT) In-Reply-To: <2ba51e04-6065-b21a-367f-1137ab22d2bc@qeng-ho.org> References: <2ba51e04-6065-b21a-367f-1137ab22d2bc@qeng-ho.org> From: Odhiambo Washington Date: Fri, 24 Mar 2017 12:27:06 +0300 Message-ID: Subject: Re: Restaarting PF and its effects on jails and vms To: Arthur Chance Cc: "James B. Byrne" , User Questions Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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:27:48 -0000 On 24 March 2017 at 12:22, Arthur Chance wrote: > 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. > Perfect! -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft."