From owner-freebsd-pf@freebsd.org Tue Jan 5 19:35:37 2021 Return-Path: Delivered-To: freebsd-pf@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 39F6C4C733A for ; Tue, 5 Jan 2021 19:35:37 +0000 (UTC) (envelope-from ddobrev85@gmail.com) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D9N547585z3Byt; Tue, 5 Jan 2021 19:35:36 +0000 (UTC) (envelope-from ddobrev85@gmail.com) Received: by mail-vs1-xe2c.google.com with SMTP id h6so546151vsr.6; Tue, 05 Jan 2021 11:35:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=W71FdmKuN1nTBePnnkkhH9gFXcVjx3DnzBLCswaUynQ=; b=XhHRHlmTmVNTxCpGIFWmlEHtMmch4n23qchXepjl7AjrZgHykD3jxGa2oP5vFxKiKU Y3GNF5yaiq52ne6nsBylqLu0SMphHN/NERTXnPk6OWNyPEXH9Wg5dOoM2YhZPTS67nKG ssq6ZYkIFDc4A1+ZYlAhwjXydCHR9kWpwmDvNQknf2SPqZU9q6Ixg5wglJCRXWuFvS5b w4Thj0B4wVheIexQvr0oLVX6jCXUmh90cJSMNM63Dui81Hx4SpEsKetvNSJdhTTCuPhq ao/SnnaLebKePKVGKdAPZai9Wp9hvMmyWihqPCQqHljU/O7tWG4l9hUdW2TGwpHSBWqj XWVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W71FdmKuN1nTBePnnkkhH9gFXcVjx3DnzBLCswaUynQ=; b=FYv2nmOWLsDGLlOu+l/J29q/0TWd3AQadAsNjsl+6x6Ml4MX8WFVCfo04XhTdGdLxg GYfFFX+MN/PQGVzWOfxtz8mtypTYvs3d1Xh63TnevUlvRpAHMkyAg5bf0AxhmmwDrxI2 iYP/CTZIMc8XtbFECSD9gJXnYLaWkAEmKhNcBsUPcSmlTjPCiMbLz85fvOY/T5GwvWO3 AWzqEYgXbgHJwzeX1XUb6kMZbOoGBhnySroCSPDgqfIeETpnLlFCFVLs5yInDx2e6wdP MkKTNmN0VLJ8V0mQ6Fpymjq2LDKLIDtWJkN1O8nWpOVSsYnn8TDWXmjszbYk/UUJzujF kGtw== X-Gm-Message-State: AOAM532v6GtXAmcMMDOYY06VUTdETiyq/20MvKh04jI1ilcCGynTS6jx zG2UftfZihWVR0HnScTCkSstjWnKIHokPIDjDYTzCMHD4vPppg== X-Google-Smtp-Source: ABdhPJyP0hIzbIYlJOTpD+9kKDdbeAs7LUXufnQys910pmOaEeLPbWrfHhqeSNFBiqcZckzHp0TWEoICsqblnIAfzyA= X-Received: by 2002:a67:507:: with SMTP id 7mr801081vsf.42.1609875335803; Tue, 05 Jan 2021 11:35:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Dobri Dobrev Date: Tue, 5 Jan 2021 21:35:22 +0200 Message-ID: Subject: Re: PF not keeping counters in a counters-defined table To: Kristof Provost Cc: freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 4D9N547585z3Byt X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.34 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: Tue, 05 Jan 2021 19:35:37 -0000 You are correct, Kristof. If I place the table in the rdr rule - it starts keeping counters, however, what is the point of having the ability to place a table in a rdr-anchor rule in the first place, if it won't be able to keep counters? I'm doing the following scenario: table counters table persist rdr-anchor "ASDFGH" on igb0 proto tcp from to any port 123 no-rdr on igb0 from any to port 123 rdr-anchor "ASDFGH" on igb0 proto tcp from any to any port 123 load anchor ASDFGH from "/etc/ASDFGH-anchor" # contents of /etc/ASDFGH-anchor: # (tested separately) # rdr on igb0 proto tcp from any to 192.168.0.1 port 123 -> 192.168.0.1 port 124 # no counters # rdr on igb0 proto tcp from to 192.168.0.1 port 123 -> 192.168.0.1 port 124 # counters working So, in this case - how do I keep counters in the without breaking the current "workflow"? If IP 192.168.0.1 is not in and I have on all rdr rules @ the anchor - I won't ever be able to reach 123->192.168.0.1:124 Is there a way? On Tue, Jan 5, 2021 at 8:58 PM Kristof Provost wrote: > On 5 Jan 2021, at 14:42, Dobri Dobrev wrote: > > # > > > -------------------------------------------------------------------------= ----------------------- > > # /etc/pf.conf: > > set timeout tcp.first 45 > > set timeout tcp.opening 45 > > set timeout tcp.closing 15 > > set timeout tcp.finwait 15 > > set timeout tcp.closed 10 > > set timeout interval 10 > > set timeout tcp.established 3600 > > set timeout src.track 10 > > > > set limit table-entries 500000 > > set limit states 2000000 > > set limit src-nodes 2000000 > > set require-order no > > set block-policy drop > > set ruleset-optimization basic > > > > set skip on lo0 > > > > table counters > > rdr-anchor "ASDFGH" on igb0 proto tcp from to any port 123 > > > > load anchor ASDFGH from "/etc/ASDFGH-anchor" > > > > # contents of /etc/ASDFGH-anchor: > > # rdr on igb0 proto tcp from any to 192.168.0.1 port 123 -> > > 192.168.0.1 > > port 124 > > # > Use pflog to confirm, but I=E2=80=99m pretty sure your issue is that you= =E2=80=99re > hitting the rdr rule in the anchor, which doesn=E2=80=99t contain the tab= le > with the counters rather than the anchor rule. > Counts are only done on the final matching rule, not on all of the rules > looked at along the way. > > Regards, > Kristof >