From owner-freebsd-pf@freebsd.org Mon Dec 23 11:00:37 2019 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 C74811EC84C for ; Mon, 23 Dec 2019 11:00:37 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47hGbn0KNlz4W1y for ; Mon, 23 Dec 2019 11:00:36 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id C755228EE6 for ; Mon, 23 Dec 2019 12:00:35 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id u5ykIBIJy7Km for ; Mon, 23 Dec 2019 12:00:35 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 147C427D09 for ; Mon, 23 Dec 2019 12:00:35 +0100 (CET) Received: from bsdlo.incore (bsdlo.incore [192.168.0.84]) by mail.local.incore (Postfix) with ESMTP id 1138A100 for ; Mon, 23 Dec 2019 12:00:35 +0100 (CET) Message-ID: <5E009E52.2040305@incore.de> Date: Mon, 23 Dec 2019 12:00:34 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: PF frag entries limit reached on a server with hw.ncpu: 24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47hGbn0KNlz4W1y X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of longwitz@incore.de designates 195.145.1.138 as permitted sender) smtp.mailfrom=longwitz@incore.de X-Spamd-Result: default: False [-4.51 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[138.1.145.195.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.21)[ip: (-8.61), ipnet: 195.145.0.0/16(-2.97), asn: 3320(0.55), country: DE(-0.02)]; DMARC_NA(0.00)[incore.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:195.145.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Mon, 23 Dec 2019 11:00:37 -0000 On one of my servers a saw some messages dssinet kernel: [zone: pf frag entries] PF frag entries limit reached The output of the command vmstat -z | grep "pf frag entries" was pf frag entries: 40, 5000, 0, 5000, 18760, 0, 0 So there are 5000 free items, none is in use and the limit of 5000 is reached. This situation is possible, when all the free 5000 items are hold in the caches of e.g cpu 0,1..20 and now a thread running on cpu 21 wants to allocate an item of the zone pf_frent_z. The alloc fails because of the limit and the zone allocater from time to time logs the error message "limit reached". After putting the line set limit frags 10000 in pf.conf the problem was gone, now I have 5700 free items and this value did not change for some weeks. For a server with 24 cpu the default PFFRAG_FRENT_HIWAT = 5000 was too small. Maybe this default value should be adjusted. Andreas From owner-freebsd-pf@freebsd.org Mon Dec 23 16:43:23 2019 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 239961CBAE1 for ; Mon, 23 Dec 2019 16:43:23 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47hQCG1Fyvz3Lnm for ; Mon, 23 Dec 2019 16:43:21 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id 9BD0F28E10 for ; Mon, 23 Dec 2019 17:43:20 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id yia5HrIb5ed1 for ; Mon, 23 Dec 2019 17:43:19 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id 77F7D28E0A for ; Mon, 23 Dec 2019 17:43:19 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id 58EA3102 for ; Mon, 23 Dec 2019 17:43:19 +0100 (CET) Message-ID: <5E00EEA7.1070205@incore.de> Date: Mon, 23 Dec 2019 17:43:19 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: Flow of broadcast/multicast packets in pf when a bridge is present Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47hQCG1Fyvz3Lnm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of longwitz@incore.de designates 195.145.1.138 as permitted sender) smtp.mailfrom=longwitz@incore.de X-Spamd-Result: default: False [-4.58 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[138.1.145.195.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.28)[ip: (-8.73), ipnet: 195.145.0.0/16(-3.22), asn: 3320(0.55), country: DE(-0.02)]; DMARC_NA(0.00)[incore.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:195.145.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Mon, 23 Dec 2019 16:43:23 -0000 On a server with a bridge running FreeBSD 12.1-STABLE r354175 I try to understand the flow of broadcast/multicast packets in pf. The bridge interface is defined with ifconfig_bridge0="inet 192.168.0.125/24 addm em0 addm em1 up, further I use net.link.bridge.inherit_mac=1, the other net.link.bridge sysctls are default. For an incoming broadcast packet on em0 I would expect that pf_test() is called with dir=PF_IN two times: for if=em0 and for if=bridge0. Indeed this happens: ether_input --> bridge_input --> bridge_forward --> bridge_pfil and bridge_pfil calls pfil_run_hooks first for em0 and second for bridge0. This is not done with the original packet but a clone (mbuf mc) created by bridge_input before bridge_forward is called. Next bridge_input does reinject another copy of the original packet truncated to length max_protohdr to the bridge: /* * Reinject the mbuf as arriving on the bridge so we have a * chance at claiming multicast packets. We can not loop back * here from ether_input as a bridge is never a member of a * bridge. */ KASSERT(bifp->if_bridge == NULL, ("loop created in bridge_input")); mc2 = m_dup(m, M_NOWAIT); if (mc2 != NULL) { /* Keep the layer3 header aligned */ int i = min(mc2->m_pkthdr.len, max_protohdr); mc2 = m_copyup(mc2, i, ETHER_ALIGN); } if (mc2 != NULL) { mc2->m_pkthdr.rcvif = bifp; (*bifp->if_input)(bifp, mc2); } This coding was committed in rev 150099, 150551 and 153622. pf_test() sees and counts this shortened packet for if=bridge0 and I really do not understand the reason why this reinject is done. At last pf_test() is called once more (for if=em0) when bridge_input finishes with /* Return the original packet for local processing. */ return (m); This time pf_test() sees the original packet on if=em0, but I do not see a way in the pf rules to distinguish this packet from the packet pf has seen first. Andreas From owner-freebsd-pf@freebsd.org Thu Dec 26 00:14:01 2019 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 41A3C1E8A9C for ; Thu, 26 Dec 2019 00:14:01 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 47jr6H5tq5z4Nq5 for ; Thu, 26 Dec 2019 00:13:59 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-vk1-xa35.google.com with SMTP id c129so5829052vkh.7 for ; Wed, 25 Dec 2019 16:13:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3uVd7JyGyml8nXH8NPajT0PeGN6fNYUaI4QBeHRVyNE=; b=aSft1SeH5oPbkZ8piQ0KuXgggPxVf4Roh5wANu/9BIadckReY9rBLzlLgIF3/u6zTW Yc8FesrlrkzrvRLau9Smm593A+MWv8z+92Gvue8jH4n5vJvpAvlJumT4OrUHpoxD3a0u 6EKDyIsBWxEbOMNIceWMybid3AUTHhCxjJAdkUDE7/+3PjzIPU1hQz4XXN0MzVEkGE2I UoBJpM1ppiH22Ygeaexo0pgV/IS4R2zJGe4FBI4MQdB/rQuPG7eLUYyyzyM08PqUP4pu U6WiLCQq/2HU8+TfyVae8nsHI8HQgf/4q44h4OHIMRe6nnpm6hLL/4z6NbYrTpRJTAt0 GDFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3uVd7JyGyml8nXH8NPajT0PeGN6fNYUaI4QBeHRVyNE=; b=HB2okRj6779utpsAZcfNSQ2z2qpdgMoxD9qeXQmLc55E2oTCIa/OZeT/37GcmIc+Ki WcxAptNxIIwo0QidoDwUvsljqNdbvSgju7o2D43ocXqSdN1djR/foZ36zqAZhAHIDdf6 dVlI0SQ7ilV3nb+zD5fMmIRh8fIDpKyyq+Dtqa21Xnh1+vxDXu8FVUuZ90IbQl/lemDF PE/SmvJ3wirkeH71vn5SLd51opyt/ZGMnPdtHiIWwzAp+fyOjSM8OBwHGUSSYqZqjUWA Af+/H0Gdha162FD/tdOmGzKEIBCqZk6uDmo643z8806bwPOwIYFDZV6yCpArZ/2YiqOK YDqA== X-Gm-Message-State: APjAAAXHC8vov6VytgcHgaY45TVuRLk4ECDKqVhWMCTdHyM3em/asXIw 18zd6JElZKHQ5/vKdUrYPzkTcBAEP9QidUxpgkLyVYUm X-Google-Smtp-Source: APXvYqwGZqq8YV2UdFFTl1w4CEW2RuHai4ZiFCfqjrI7MNdM4aGygAEVA8EBZFvxSMhy7ebLXWNdYwo94sN48QaL+Sw= X-Received: by 2002:a1f:6743:: with SMTP id m3mr25456525vki.16.1577319238460; Wed, 25 Dec 2019 16:13:58 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 26 Dec 2019 03:13:47 +0300 Message-ID: Subject: Blocking SYN with data To: freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 47jr6H5tq5z4Nq5 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=aSft1SeH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::a35 as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.69), ipnet: 2607:f8b0::/32(-2.16), asn: 15169(-1.88), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[5.3.a.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 26 Dec 2019 00:14:01 -0000 Hi, I want to block SYN with data packets. I read the pf.conf manual, but couldn't find a clear way to do this. Is it possible to match packets greater then N bytes using pf on FreeBSD 12.1 stable? Does synproxy state or modulate state perform this operation? Thanks From owner-freebsd-pf@freebsd.org Thu Dec 26 00:20:26 2019 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 525DB1E8C3C for ; Thu, 26 Dec 2019 00:20:26 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 47jrFj3lwmz4Nxr for ; Thu, 26 Dec 2019 00:20:25 +0000 (UTC) (envelope-from ozkan.kirik@gmail.com) Received: by mail-ua1-x92a.google.com with SMTP id y23so7700894ual.2 for ; Wed, 25 Dec 2019 16:20:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Swf3Lbgu8/2m3h1lOEXKpRVKCCowwFY8zLxpvQiYg5E=; b=QM785sCFnvexi+zNcb1NLAO9D7VsnL/FRgkf5++8wkAQ54Oy1F2S9znpfjZvCnPA0M xt2Z6BQ0OhWVWSfBkbTgaR9NbI3cYDHDTx0InQcy8/+NaF+wmRPsXB3Dq95pwOUHbof6 TSnBtOOgCMtn+CFNtyNsSx8AdWQoen7Q3Vo+xeTyKF8PveRrOdGGDVtFHO5W0/JXmsPJ LAUze6Xx5T2DxO+0/9OqIKB5kVO+muPWL+m21jBqZzgbogYOBYXZ2vWLHxzWNfAiv+uJ CdXG6cYB9hyUjyzy9GRx02n08eJDBQaQ6+MvfMnDDc6ElUNI5obk0El/Rc33x/GSxCUC jAiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Swf3Lbgu8/2m3h1lOEXKpRVKCCowwFY8zLxpvQiYg5E=; b=lWxgl13zoOVsxLRXml0zesX281ZOVdFISImFrbm8eCkI1vH10w0IT2QVYHU9mDu38m FyOrHDAkRZWFy8YNk+JHToiLnlwxe8V8spdHynvzbZAWJS3BznQQTQ00HgMMsuobvKtO U8Ktf+vnvvDaATCRLVwe3a91uybb3QEqAHRocvX6gyyip2eHIXeREZXmP2N9OdNG6tTs TmGSUXCYO3cJeGsrPPGslK0reEaS5nsIFZ1CfdUY/Lz9LiPPPJjRt2iuOAI/bGOrnJZv xz0fvI2wmxksvWYkHKZ1tD3WjMshNy6e0F4DquxYRKLuB9/4DVKia+B0uUnT9SB8D2cH MvXw== X-Gm-Message-State: APjAAAWa88Q8EwDF2zGVPAIebPy1P7Jd1DyhYta4dw2SQmpRoBuRkd6c xuwug1jLvW1HufEl1vA6drFn/pStCYKHaI3zr7JhtNdu X-Google-Smtp-Source: APXvYqwlgnfxfCQ+k4MshooVoLgtXmqqAeaYBMZ0VorqB54msHnBMbwJG8SeiPEZ5Z37kvDpV2tBnzxZdCDZboclKyM= X-Received: by 2002:ab0:2a1a:: with SMTP id o26mr25888093uar.62.1577319624202; Wed, 25 Dec 2019 16:20:24 -0800 (PST) MIME-Version: 1.0 From: =?UTF-8?B?w5Z6a2FuIEtJUklL?= Date: Thu, 26 Dec 2019 03:20:13 +0300 Message-ID: Subject: Rule last match timestamp To: freebsd-pf@freebsd.org X-Rspamd-Queue-Id: 47jrFj3lwmz4Nxr X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=QM785sCF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of ozkankirik@gmail.com designates 2607:f8b0:4864:20::92a as permitted sender) smtp.mailfrom=ozkankirik@gmail.com X-Spamd-Result: default: False [-3.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; IP_SCORE_FREEMAIL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE(0.00)[ip: (-9.78), ipnet: 2607:f8b0::/32(-2.16), asn: 15169(-1.88), country: US(-0.05)]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[a.2.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Thu, 26 Dec 2019 00:20:26 -0000 Hi, I need last match timestamps for each rule. ipfw has an option for this. But pfctl -v -sr command doesnt show last match timestamp. Is there way to gather this information in pf? Thanks From owner-freebsd-pf@freebsd.org Fri Dec 27 17:32:24 2019 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 E58BB1C9DAF for ; Fri, 27 Dec 2019 17:32:24 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from mercury.codepro.be (mercury.codepro.be [217.70.188.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "monitoring.codepro.be", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kv5z5SPRz4LPM for ; Fri, 27 Dec 2019 17:32:23 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) by mercury.codepro.be (Postfix) with ESMTPS id B131B90487 for ; Fri, 27 Dec 2019 17:31:28 +0000 (UTC) Received: from [172.31.118.163] (unknown [91.126.134.20]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 69526EED7 for ; Fri, 27 Dec 2019 18:32:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1577467940; bh=0PyknNADINYnolC/FgfDxQNLKlXDz32lJdAVrsPY5fU=; h=From:To:Subject:Date:In-Reply-To:References; b=Apvv2H76aAgNzBSjD0rZCWop0Rw6bjhjs87zxf3x6NKm4p50AvirWuxtaif2Rx+PY Az28ApzRhiPpFT8J1IuLTNsp+5GPSjDvLt7R53nY/7oZyCGzihswcDbyzU4Aq5o4Ii 7cjtnZkP+LefX+e//Q6Ks1QTRjY8GWsL04jQOn+U= From: "Kristof Provost" To: freebsd-pf@freebsd.org Subject: Re: PF frag entries limit reached on a server with hw.ncpu: 24 Date: Fri, 27 Dec 2019 18:32:19 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <257AC5A9-5384-4843-ABFF-528A711B2121@sigsegv.be> In-Reply-To: <5E009E52.2040305@incore.de> References: <5E009E52.2040305@incore.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47kv5z5SPRz4LPM X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=Apvv2H76; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be designates 217.70.188.19 as permitted sender) smtp.mailfrom=SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-3.77 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.188.19]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_IN_DNSWL_MED(-0.20)[19.188.70.217.list.dnswl.org : 127.0.9.2]; DKIM_TRACE(0.00)[sigsegv.be:+]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-0.37)[ipnet: 217.70.188.0/22(0.45), asn: 203476(-2.29), country: FR(0.00)]; ASN(0.00)[asn:203476, ipnet:217.70.188.0/22, country:FR]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Dec 2019 17:32:25 -0000 On 23 Dec 2019, at 12:00, Andreas Longwitz wrote: > On one of my servers a saw some messages > > dssinet kernel: > [zone: pf frag entries] PF frag entries limit reached > > The output of the command > vmstat -z | grep "pf frag entries" > was > pf frag entries: 40, 5000, 0, 5000, 18760, 0, 0 > > So there are 5000 free items, none is in use and the limit of 5000 is > reached. This situation is possible, when all the free 5000 items are > hold in the caches of e.g cpu 0,1..20 and now a thread running on cpu > 21 > wants to allocate an item of the zone pf_frent_z. The alloc fails > because of the limit and the zone allocater from time to time logs the > error message "limit reached". > > After putting the line > set limit frags 10000 > in pf.conf the problem was gone, now I have 5700 free items and this > value did not change for some weeks. > > For a server with 24 cpu the default PFFRAG_FRENT_HIWAT = 5000 was too > small. Maybe this default value should be adjusted. > I’m happy to tweak defaults, but I’m not sure there’s a good way to figure out what a sane value is. Possibly we’d want a heuristic based on the RAM size, but that too is not ideal: a firewall device will reasonably want to dedicate more of its memory to pf than a file server. I’d prefer to have a holistic view of what defaults make sense for these limits before we start changing them. Best regards, Kristof From owner-freebsd-pf@freebsd.org Fri Dec 27 17:43:01 2019 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 0929F1CA63F for ; Fri, 27 Dec 2019 17:43:01 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from mercury.codepro.be (mercury.codepro.be [217.70.188.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits)) (Client CN "monitoring.codepro.be", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kvLD584Sz4MM0 for ; Fri, 27 Dec 2019 17:43:00 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) by mercury.codepro.be (Postfix) with ESMTPS id 07B0990487; Fri, 27 Dec 2019 17:42:07 +0000 (UTC) Received: from [172.31.118.163] (unknown [91.126.134.20]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id A7EACEF1C; Fri, 27 Dec 2019 18:42:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1577468578; bh=VPWkyrAApfvvajsBpcHWlna+uopC22bOBlwhk93MXk4=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=D9nHzAnjHvpRavmyI0/x86pUOh9BPze0EwL2nLUzeuqX4NgdH9O6x6g1r/5C4J0jB 2CtGA2piMy97ArF6Oovt6Tfc5W6J3HlXlImnEC9V3lgVVl6cJ8W12+Z8ZFyFqmnL1q uAClXAUyqEaLnpiWaz8rXMRonzigZz1Hlxtq/5E0= From: "Kristof Provost" To: "=?utf-8?q?=C3=96zkan?= KIRIK" Cc: freebsd-pf@freebsd.org Subject: Re: Blocking SYN with data Date: Fri, 27 Dec 2019 18:42:57 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <5DA4A228-98D3-4F96-978F-D36BEEA8617B@sigsegv.be> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47kvLD584Sz4MM0 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=D9nHzAnj; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be designates 217.70.188.19 as permitted sender) smtp.mailfrom=SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-5.37 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:217.70.188.19]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[sigsegv.be:+]; RCVD_IN_DNSWL_MED(-0.20)[19.188.70.217.list.dnswl.org : 127.0.9.2]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.97)[ip: (-7.42), ipnet: 217.70.188.0/22(-0.16), asn: 203476(-2.29), country: FR(0.00)]; ASN(0.00)[asn:203476, ipnet:217.70.188.0/22, country:FR]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Dec 2019 17:43:01 -0000 On 26 Dec 2019, at 1:13, Özkan KIRIK wrote: > Hi, > > I want to block SYN with data packets. > I read the pf.conf manual, but couldn't find a clear way to do this. > > Is it possible to match packets greater then N bytes using pf on > FreeBSD > 12.1 stable? There isn’t a way to express this in pf right now. > Does synproxy state or modulate state perform this operation? > I’ve had a quick look at the code, and I’m somewhat surprised to find that pf doesn’t stop this by default. There may be good reasons for this, or perhaps it’s not considered to be a problem (i.e. it doesn’t happen often, and host stacks discard it anyway). I’ve not gone through the sync-proxy code flow, but I’d expect that to prevent this from happening. Why are you concerned about it? Best regards, Kristof From owner-freebsd-pf@freebsd.org Fri Dec 27 17:45:29 2019 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 C40D91CA6CA for ; Fri, 27 Dec 2019 17:45:29 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:41:216:3eff:fe31:eda8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "monitoring.codepro.be", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kvP509xxz4MRQ for ; Fri, 27 Dec 2019 17:45:28 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) by mercury.codepro.be (Postfix) with ESMTPS id E69E390487; Fri, 27 Dec 2019 17:44:33 +0000 (UTC) Received: from [172.31.118.163] (unknown [91.126.134.20]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 47FB6EF4F; Fri, 27 Dec 2019 18:45:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1577468725; bh=8snbBZ6okJsShvePqIshcwaS8ReL9W6gjQR4vlNrK6E=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=sps/H8xh+fXY6fImYopFqTCGydVMtM045JdM0syPduk/Tp9yDUQMA6qZt0n8LSJcn +cgwzsv6mudC34fFUdy5liU+NiKStkMKySii2TZCNPO29p+LutejM5j3tXOwQO9Je8 MU95lC7OjelwEdq00ajoMHaobGgeYJcApza2+YJ8= From: "Kristof Provost" To: "=?utf-8?q?=C3=96zkan?= KIRIK" Cc: freebsd-pf@freebsd.org Subject: Re: Rule last match timestamp Date: Fri, 27 Dec 2019 18:45:23 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: <2C151498-F878-40A3-8A7C-C9C7D36CDBFF@sigsegv.be> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47kvP509xxz4MRQ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=sps/H8xh; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be designates 2001:4b98:dc0:41:216:3eff:fe31:eda8 as permitted sender) smtp.mailfrom=SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-5.18 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc0:41:216:3eff:fe31:eda8:c]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[sigsegv.be:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; RCVD_IN_DNSWL_MED(-0.20)[8.a.d.e.1.3.e.f.f.f.e.3.6.1.2.0.1.4.0.0.0.c.d.0.8.9.b.4.1.0.0.2.list.dnswl.org : 127.0.9.2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-1.78)[ip: (-5.11), ipnet: 2001:4b98::/32(-2.56), asn: 29169(-1.23), country: FR(0.00)]; ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Dec 2019 17:45:29 -0000 On 26 Dec 2019, at 1:20, Özkan KIRIK wrote: > Hi, > > I need last match timestamps for each rule. ipfw has an option for this. > But pfctl -v -sr command doesnt show last match timestamp. > Is there way to gather this information in pf? > Pf does not track this. What are you trying to accomplish? Best regards, Kristof From owner-freebsd-pf@freebsd.org Fri Dec 27 20:49:51 2019 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 4E5191CEDD2 for ; Fri, 27 Dec 2019 20:49:51 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d7::103:2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47kzTp2xQ8z4Xx1 for ; Fri, 27 Dec 2019 20:49:50 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from francos-mbp.fritz.box (ip9234d229.dynamic.kabel-deutschland.de [146.52.210.41]) by host64.shmhost.net (Postfix) with ESMTPSA id 47kzTd5tDPzJ6CS; Fri, 27 Dec 2019 21:49:41 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: Rule last match timestamp From: Franco Fichtner In-Reply-To: <2C151498-F878-40A3-8A7C-C9C7D36CDBFF@sigsegv.be> Date: Fri, 27 Dec 2019 21:49:41 +0100 Cc: =?utf-8?Q?=C3=96zkan_KIRIK?= , freebsd-pf@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <8547AD1F-2D76-449E-90DE-DC0D699D9631@lastsummer.de> References: <2C151498-F878-40A3-8A7C-C9C7D36CDBFF@sigsegv.be> To: Kristof Provost X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Virus-Scanned: clamav-milter 0.101.4 at host64.shmhost.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 47kzTp2xQ8z4Xx1 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of franco@lastsummer.de has no SPF policy when checking 2a01:4f8:a0:51d7::103:2) smtp.mailfrom=franco@lastsummer.de X-Spamd-Result: default: False [-1.56 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lastsummer.de]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RECEIVED_SPAMHAUS_PBL(0.00)[41.210.52.146.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-0.97)[ip: (-0.87), ipnet: 2a01:4f8::/29(-2.43), asn: 24940(-1.55), country: DE(-0.02)]; NEURAL_HAM_MEDIUM(-0.99)[-0.991,0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; FREEMAIL_CC(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Dec 2019 20:49:51 -0000 Hi, > On 27. Dec 2019, at 6:45 PM, Kristof Provost wrote: > > What are you trying to accomplish? Some people believe that "last match" is a great metric to audit rules for intrusion detection and all sorts ruleset optimisation and refinement. In OPNsense the question has popped up a few times to support it, but without doing it in pf(4) directly it makes little sense as you'd have to crawl pflog output and even then you can't crawl non-log rules this way... Cheers, Franco From owner-freebsd-pf@freebsd.org Fri Dec 27 21:07:42 2019 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 2ED571CF3A4 for ; Fri, 27 Dec 2019 21:07:42 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:41:216:3eff:fe31:eda8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "monitoring.codepro.be", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47kztP0RRFz4YgY for ; Fri, 27 Dec 2019 21:07:40 +0000 (UTC) (envelope-from SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) by mercury.codepro.be (Postfix) with ESMTPS id A328390487; Fri, 27 Dec 2019 21:06:45 +0000 (UTC) Received: from [172.31.118.163] (unknown [91.126.134.20]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 71129F1DA; Fri, 27 Dec 2019 22:07:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1577480857; bh=Ctc4GZ+Y9L9pmwStplG3+bm2dqXjsm/+ohCpAccayOY=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=VL1rtV/XeW7FNveqfJXYubm1nPMToYUtagqGBz7E/M4kIxcTNUhN3+HXqCZmO1Zay rLIOXK7URTfkPbKk+Jqy+DRcFvHSJ4+vBU+WJ4Nn9npOHApiF07suLG1nPmkX2b+Gi /9z3IaS6YKBk2OY5g0f/RB9vRMtAZxVa46YtnIAg= From: "Kristof Provost" To: "Franco Fichtner" Cc: "=?utf-8?q?=C3=96zkan?= KIRIK" , freebsd-pf@freebsd.org Subject: Re: Rule last match timestamp Date: Fri, 27 Dec 2019 22:07:36 +0100 X-Mailer: MailMate (1.13.1r5671) Message-ID: In-Reply-To: <8547AD1F-2D76-449E-90DE-DC0D699D9631@lastsummer.de> References: <2C151498-F878-40A3-8A7C-C9C7D36CDBFF@sigsegv.be> <8547AD1F-2D76-449E-90DE-DC0D699D9631@lastsummer.de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 47kztP0RRFz4YgY X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=VL1rtV/X; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be designates 2001:4b98:dc0:41:216:3eff:fe31:eda8 as permitted sender) smtp.mailfrom=SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-5.52 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc0:41:216:3eff:fe31:eda8]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[8.a.d.e.1.3.e.f.f.f.e.3.6.1.2.0.1.4.0.0.0.c.d.0.8.9.b.4.1.0.0.2.list.dnswl.org : 127.0.9.2]; DKIM_TRACE(0.00)[sigsegv.be:+]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.12)[ip: (-6.23), ipnet: 2001:4b98::/32(-3.11), asn: 29169(-1.23), country: FR(0.00)]; ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=Ntx9=2R=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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, 27 Dec 2019 21:07:42 -0000 On 27 Dec 2019, at 21:49, Franco Fichtner wrote: > Hi, > >> On 27. Dec 2019, at 6:45 PM, Kristof Provost >> wrote: >> >> What are you trying to accomplish? > > Some people believe that "last match" is a great metric to audit rules > for > intrusion detection and all sorts ruleset optimisation and refinement. > > In OPNsense the question has popped up a few times to support it, but > without > doing it in pf(4) directly it makes little sense as you'd have to > crawl pflog > output and even then you can't crawl non-log rules this way... > Would SDT probe points be useful for this? I have a background todo item to add those where they’d be meaningful. They have the advantage of not really having a cost when they’re not active, of being really easy to add, and of not imposing ABI changes. Best regards, Kristof From owner-freebsd-pf@freebsd.org Sat Dec 28 11:52:46 2019 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 ABBC61E5E54 for ; Sat, 28 Dec 2019 11:52:46 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from dss.incore.de (dss.incore.de [195.145.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47lMWd1lXSz4HyC for ; Sat, 28 Dec 2019 11:52:44 +0000 (UTC) (envelope-from longwitz@incore.de) Received: from inetmail.dmz (inetmail.dmz [10.3.0.3]) by dss.incore.de (Postfix) with ESMTP id B818B276C0 for ; Sat, 28 Dec 2019 12:52:42 +0100 (CET) X-Virus-Scanned: amavisd-new at incore.de Received: from dss.incore.de ([10.3.0.3]) by inetmail.dmz (inetmail.dmz [10.3.0.3]) (amavisd-new, port 10024) with LMTP id h8NxcOajk-u5 for ; Sat, 28 Dec 2019 12:52:41 +0100 (CET) Received: from mail.local.incore (fwintern.dmz [10.0.0.253]) by dss.incore.de (Postfix) with ESMTP id E274D276BA for ; Sat, 28 Dec 2019 12:52:41 +0100 (CET) Received: from bsdmhs.longwitz (unknown [192.168.99.6]) by mail.local.incore (Postfix) with ESMTP id CC58D15F for ; Sat, 28 Dec 2019 12:52:41 +0100 (CET) Message-ID: <5E074209.2070801@incore.de> Date: Sat, 28 Dec 2019 12:52:41 +0100 From: Andreas Longwitz User-Agent: Thunderbird 2.0.0.19 (X11/20090113) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Subject: Re: Flow of broadcast/multicast packets in pf when a bridge is present References: <5E00EEA7.1070205@incore.de> In-Reply-To: <5E00EEA7.1070205@incore.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47lMWd1lXSz4HyC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of longwitz@incore.de designates 195.145.1.138 as permitted sender) smtp.mailfrom=longwitz@incore.de X-Spamd-Result: default: False [-4.64 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_FIVE(0.00)[5]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-pf@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_TLS_LAST(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[138.1.145.195.list.dnswl.org : 127.0.10.0]; IP_SCORE(-2.34)[ip: (-8.82), ipnet: 195.145.0.0/16(-3.42), asn: 3320(0.54), country: DE(-0.02)]; DMARC_NA(0.00)[incore.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3320, ipnet:195.145.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 28 Dec 2019 11:52:46 -0000 In the meantime I have understand I was wrong about the code snippet > mc2 = m_dup(m, M_NOWAIT); > if (mc2 != NULL) { > /* Keep the layer3 header aligned */ > int i = min(mc2->m_pkthdr.len, max_protohdr); > mc2 = m_copyup(mc2, i, ETHER_ALIGN); > } > if (mc2 != NULL) { > mc2->m_pkthdr.rcvif = bifp; > (*bifp->if_input)(bifp, mc2); > } My mistake concerned the function call m_copyup(): The mbuf chain is copied correct and not shortened, I was confused because of the field m_len in mc2. So reinjecting the packet in the bridge is ok. Another aspect is what is done next with the broadcast/multicast packet handled by this code: > /* Return the original packet for local processing. */ > return (m); Therefore local processing on the member interface is done for broadcast/multicast packets without checking the pfil_local_phys variable. That was confusing me because these packets are counting twice in the pf rules. I think this is needless and pfil_local_phys should respect all packets not only unicast. After introducing the patch --- if_bridge.c.iorig 2019-05-14 09:43:33.000000000 +0200 +++ if_bridge.c 2019-12-28 11:54:52.000000000 +0100 @@ -2386,6 +2386,10 @@ (*bifp->if_input)(bifp, mc2); } + if (!pfil_local_phys ) { + m_freem(m); + return (NULL); + } /* Return the original packet for local processing. */ return (m); } everything works fine and all the counters in pf have values as expected (I use state-policy if-bound). Andreas From owner-freebsd-pf@freebsd.org Sat Dec 28 13:59:15 2019 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 2B1AE1E90F8 for ; Sat, 28 Dec 2019 13:59:15 +0000 (UTC) (envelope-from SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be) Received: from mercury.codepro.be (mercury.codepro.be [IPv6:2001:4b98:dc0:41:216:3eff:fe31:eda8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "monitoring.codepro.be", Issuer "Let's Encrypt Authority X3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47lQKZ155qz4Ntk for ; Sat, 28 Dec 2019 13:59:13 +0000 (UTC) (envelope-from SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) by mercury.codepro.be (Postfix) with ESMTPS id F40079048C; Sat, 28 Dec 2019 13:58:17 +0000 (UTC) Received: from [100.117.154.237] (unknown [188.189.26.237]) (Authenticated sender: kp) by venus.codepro.be (Postfix) with ESMTPSA id 49F6AFB4F; Sat, 28 Dec 2019 14:59:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sigsegv.be; s=mail; t=1577541550; bh=RXdKa4OvIqphgQ79Oz0xE9tC4sYKrAvnDSdqYsFiGy0=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=MqjqgKcKQkkwoeSmehD9pRJoRgGWIaLabRKj8NHnSe+4urNR7+pCvBBagb9ylVO+M Q4w9w66TKOvBo9fXZRQ4sLkKQyPGWJo11pvwhNRIpfM1Rk5l7QX9OjzsW4e9bbzecM nTlZhvOo643RZS6pHGxnXc+UIjs9wjl9Ah47a1Jg= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Kristof Provost Mime-Version: 1.0 (1.0) Subject: Re: Flow of broadcast/multicast packets in pf when a bridge is present Date: Sat, 28 Dec 2019 14:59:08 +0100 Message-Id: References: <5E074209.2070801@incore.de> Cc: freebsd-pf@freebsd.org In-Reply-To: <5E074209.2070801@incore.de> To: Andreas Longwitz X-Mailer: iPhone Mail (17C54) X-Rspamd-Queue-Id: 47lQKZ155qz4Ntk X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=sigsegv.be header.s=mail header.b=MqjqgKcK; dmarc=pass (policy=none) header.from=sigsegv.be; spf=pass (mx1.freebsd.org: domain of SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be designates 2001:4b98:dc0:41:216:3eff:fe31:eda8 as permitted sender) smtp.mailfrom=SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be X-Spamd-Result: default: False [-5.25 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[sigsegv.be:s=mail]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:4b98:dc0:41:216:3eff:fe31:eda8]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[8.a.d.e.1.3.e.f.f.f.e.3.6.1.2.0.1.4.0.0.0.c.d.0.8.9.b.4.1.0.0.2.list.dnswl.org : 127.0.9.2]; DKIM_TRACE(0.00)[sigsegv.be:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[sigsegv.be,none]; FORGED_SENDER(0.30)[kristof@sigsegv.be,SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.35)[ip: (-7.01), ipnet: 2001:4b98::/32(-3.50), asn: 29169(-1.24), country: FR(0.00)]; ASN(0.00)[asn:29169, ipnet:2001:4b98::/32, country:FR]; FROM_NEQ_ENVFROM(0.00)[kristof@sigsegv.be,SRS0=QYpd=2S=sigsegv.be=kristof@codepro.be]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.29 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: Sat, 28 Dec 2019 13:59:15 -0000 > On 28 Dec 2019, at 12:52, Andreas Longwitz wrote: >=20 > =EF=BB=BFIn the meantime I have understand I was wrong about the code snip= pet >=20 >> mc2 =3D m_dup(m, M_NOWAIT); >> if (mc2 !=3D NULL) { >> /* Keep the layer3 header aligned */ >> int i =3D min(mc2->m_pkthdr.len, max_protohdr); >> mc2 =3D m_copyup(mc2, i, ETHER_ALIGN); >> } >> if (mc2 !=3D NULL) { >> mc2->m_pkthdr.rcvif =3D bifp; >> (*bifp->if_input)(bifp, mc2); >> } >=20 > My mistake concerned the function call m_copyup(): The mbuf chain is > copied correct and not shortened, I was confused because of the field > m_len in mc2. So reinjecting the packet in the bridge is ok. >=20 > Another aspect is what is done next with the broadcast/multicast packet > handled by this code: >=20 >> /* Return the original packet for local processing. */ >> return (m); >=20 > Therefore local processing on the member interface is done for > broadcast/multicast packets without checking the pfil_local_phys > variable. That was confusing me because these packets are counting twice > in the pf rules. I think this is needless and pfil_local_phys should > respect all packets not only unicast. >=20 > After introducing the patch >=20 > --- if_bridge.c.iorig 2019-05-14 09:43:33.000000000 +0200 > +++ if_bridge.c 2019-12-28 11:54:52.000000000 +0100 > @@ -2386,6 +2386,10 @@ > (*bifp->if_input)(bifp, mc2); > } >=20 > + if (!pfil_local_phys ) { > + m_freem(m); > + return (NULL); > + } > /* Return the original packet for local processing. */ > return (m); > } >=20 > everything works fine and all the counters in pf have values as expected >=20 Can you put that in Phabricator and cc me and kevans@? (I seem to remember h= im touching related code a few months ago). Thanks, Kristof=