From owner-freebsd-pf@freebsd.org Sun Apr 30 21:00:54 2017 Return-Path: Delivered-To: freebsd-pf@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 82360D57EFA for ; Sun, 30 Apr 2017 21:00:54 +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 mx1.freebsd.org (Postfix) with ESMTPS id 5B0089AA for ; Sun, 30 Apr 2017 21:00:54 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v3UL01TA070104 for ; Sun, 30 Apr 2017 21:00:54 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201704302100.v3UL01TA070104@kenobi.freebsd.org> From: bugzilla-noreply@FreeBSD.org To: freebsd-pf@FreeBSD.org Subject: Problem reports for freebsd-pf@FreeBSD.org that need special attention Date: Sun, 30 Apr 2017 21:00:54 +0000 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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: Sun, 30 Apr 2017 21:00:54 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- Open | 203735 | Transparent interception of ipv6 with squid and p 1 problems total for which you should take action. From owner-freebsd-pf@freebsd.org Mon May 1 15:05:26 2017 Return-Path: Delivered-To: freebsd-pf@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 BC67CD5902B for ; Mon, 1 May 2017 15:05:26 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from mail.farrokhi.net (mail.farrokhi.net [79.127.49.115]) (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 2A296BCC for ; Mon, 1 May 2017 15:05:26 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from [172.16.148.1] (unknown [79.127.49.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freebsd@farrokhi.net) by mail.farrokhi.net (Postfix) with ESMTPSA id ECA853C330 for ; Mon, 1 May 2017 19:29:23 +0430 (IRDT) From: "Babak Farrokhi" To: freebsd-pf@freebsd.org Subject: Similar entries in source tracking table Date: Mon, 01 May 2017 19:29:23 +0430 Message-ID: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_71D1AC8A-74FB-494B-BC5B-B806959575E4_="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5371) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 01 May 2017 15:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_71D1AC8A-74FB-494B-BC5B-B806959575E4_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, I was running an experiment with pf in which I encountered an unusual cas= e. In a nat setup, is this okay to have multiple similar entries in source t= racking table? # pfctl -sS 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) There are actually three similar binding stuck in source tracking table. vmstat output also confirms separate memory allocation for three entries = in source tracking table: # vmstat -z | egrep 'ITEM|^pf' ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP pf mtags: 48, 0, 0, 0, 0, 0, 0 pf states: 296, 8000005, 0, 1313, 2279, 0, 0= pf state keys: 88, 0, 0, 2655, 4558, 0, 0 pf source nodes: 136, 1500025, 3, 142, 7, 0, 0= pf table entries: 160, 800000, 4, 121, 47, 0, 0 pf table counters: 64, 0, 0, 0, 0, 0, 0 pf frags: 112, 0, 0, 0, 0, 0, 0 pf frag entries: 40, 100000, 0, 0, 0, 0, 0 pf state scrubs: 40, 0, 0, 0, 0, 0, 0 I can reproduce this behavior by reloading pf.conf and running traffic th= rough the box and get a new entry added to source tracking table. Here is the nat rule: # pfctl -vsn nat on em0 inet from to any -> round-robin = sticky-address [ Evaluations: 368 Packets: 50 Bytes: 2084 States: = 0 ] [ Inserted: uid 0 pid 6418 State Creations: 28 ] and timers: # pfctl -st tcp.first 10s tcp.opening 10s tcp.established 4200s tcp.closing 10s tcp.finwait 15s tcp.closed 10s tcp.tsdiff 30s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 30s adaptive.start 0 states adaptive.end 0 states src.track 3600s Any ideas if this behavior is expected? =E2=80=94 Babak --=_MailMate_71D1AC8A-74FB-494B-BC5B-B806959575E4_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJ8BAEBCABmBQJZB01LXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMDgxNUY4ODYxQkYyREVBRjI2MUU5QzE2 QjI2N0FEODVENjMyRTlBAAoJEGsmethdYy6ah3gP/jdFSYg87Eq5uwmPvt58ddCc bp6zAJ9X7xGxRlPZW8EgHvJzefvDXhDcrTBiAMlOKVvuIfIu6zzX4ZKRiyXYtcKF /URoQQEp2BXRiUM+9Ogu74a/aEsVctxIKsnG47d/IHyFRaUOdZ5Phqh5ae5MiERE 2Ozto+34wfL75xdsquwNxJHadx3+QXEQKIVp20YbWXh3ajQbO1DikVRBo64bODE8 RkkmeiIiOw7uCOcttg1K/t+crIeA0zV0OaqqJe1R8IRaRO8hjeUY4Sjq19mqeJOF JAfNl18tXrq/0Q7yf7OAOMgeiws50Q+YjvdWoe/Vxw1Kf3T1lccYP6H+io2n3S7M Ao9k3Gsu363RPuKpD7/eWe75K3WExtgrIrxMfhIpX9rFyV24wlpGzbSna9/2A1tP 7vKC0J3aLcx0LR0SJWN+cfivikmytU6eRbcWDBTDZiCneGtA1odAn99IcyCTUNLJ n9rB7Ka8mn2vAc0rv44W/vxYiSc28lx8TQ6LTWL71C6Yf0QmMO2SER1n9B2uoefn bwTiP3bTEwWCgkFbsJ5rbP9KlNsOH4cYK3z4G47i7gm+bKiIIWLpSoEITOEubPpS kSzMf7EWTXpxJ94AQSNUuQ6Fr68TM9P16tgeIDbAG8i60vpfSTtvcZxiJ9GGF+Fs WCPu79fuZFU5uz2TGf1C =rfcR -----END PGP SIGNATURE----- --=_MailMate_71D1AC8A-74FB-494B-BC5B-B806959575E4_=-- From owner-freebsd-pf@freebsd.org Tue May 2 06:17:07 2017 Return-Path: Delivered-To: freebsd-pf@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 A5F76D5A302 for ; Tue, 2 May 2017 06:17:07 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (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 66EE61722 for ; Tue, 2 May 2017 06:17:06 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1d5R2U-000Ech-SS for freebsd-pf@freebsd.org; Tue, 02 May 2017 09:11:58 +0300 Subject: Re: Similar entries in source tracking table To: freebsd-pf@freebsd.org References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> From: Max Message-ID: <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> Date: Tue, 2 May 2017 09:11:58 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 06:17:07 -0000 Hello, Can you show "pfctl -vsS" output? And what version of FreeBSD are you running? 01.05.2017 17:59, Babak Farrokhi пишет: > Hello, > > I was running an experiment with pf in which I encountered an unusual case. > > In a nat setup, is this okay to have multiple similar entries in source tracking table? > > # pfctl -sS > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > > There are actually three similar binding stuck in source tracking table. > vmstat output also confirms separate memory allocation for three entries in > source tracking table: > > # vmstat -z | egrep 'ITEM|^pf' > ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP > pf mtags: 48, 0, 0, 0, 0, 0, 0 > pf states: 296, 8000005, 0, 1313, 2279, 0, 0 > pf state keys: 88, 0, 0, 2655, 4558, 0, 0 > pf source nodes: 136, 1500025, 3, 142, 7, 0, 0 > pf table entries: 160, 800000, 4, 121, 47, 0, 0 > pf table counters: 64, 0, 0, 0, 0, 0, 0 > pf frags: 112, 0, 0, 0, 0, 0, 0 > pf frag entries: 40, 100000, 0, 0, 0, 0, 0 > pf state scrubs: 40, 0, 0, 0, 0, 0, 0 > > > I can reproduce this behavior by reloading pf.conf and running traffic through > the box and get a new entry added to source tracking table. > > Here is the nat rule: > > # pfctl -vsn > nat on em0 inet from to any -> round-robin sticky-address > [ Evaluations: 368 Packets: 50 Bytes: 2084 States: 0 ] > [ Inserted: uid 0 pid 6418 State Creations: 28 ] > > and timers: > > # pfctl -st > tcp.first 10s > tcp.opening 10s > tcp.established 4200s > tcp.closing 10s > tcp.finwait 15s > tcp.closed 10s > tcp.tsdiff 30s > udp.first 60s > udp.single 30s > udp.multiple 60s > icmp.first 20s > icmp.error 10s > other.first 60s > other.single 30s > other.multiple 60s > frag 30s > interval 30s > adaptive.start 0 states > adaptive.end 0 states > src.track 3600s > > Any ideas if this behavior is expected? > > — > Babak From owner-freebsd-pf@freebsd.org Tue May 2 07:01:50 2017 Return-Path: Delivered-To: freebsd-pf@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 D3D82D5AE18 for ; Tue, 2 May 2017 07:01:50 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from mail.farrokhi.net (mail.farrokhi.net [79.127.49.115]) (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 53063699 for ; Tue, 2 May 2017 07:01:49 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from [172.16.148.1] (unknown [79.127.49.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freebsd@farrokhi.net) by mail.farrokhi.net (Postfix) with ESMTPSA id 5688F3C4BD; Tue, 2 May 2017 11:31:46 +0430 (IRDT) From: "Babak Farrokhi" To: Max Cc: freebsd-pf@freebsd.org Subject: Re: Similar entries in source tracking table Date: Tue, 02 May 2017 11:31:45 +0430 Message-ID: In-Reply-To: <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5371) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 07:01:50 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, Here it is: # pfctl -vvsS No ALTQ support in kernel ALTQ related functions disabled 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0 # pfctl -vvss No ALTQ support in kernel ALTQ related functions disabled I am running 11-STABLE r317643. Please note that this is only reproducibl= e when you reload your pf configuration and tables. =E2=80=94 Babak On 2 May 2017, at 10:41, Max wrote: > Hello, > Can you show "pfctl -vsS" output? And what version of FreeBSD are you r= unning? > > > 01.05.2017 17:59, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Hello, >> >> I was running an experiment with pf in which I encountered an unusual = case. >> >> In a nat setup, is this okay to have multiple similar entries in sourc= e tracking table? >> >> # pfctl -sS >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> >> There are actually three similar binding stuck in source tracking tabl= e. >> vmstat output also confirms separate memory allocation for three entri= es in >> source tracking table: >> >> # vmstat -z | egrep 'ITEM|^pf' >> ITEM SIZE LIMIT USED FREE REQ FAIL SLE= EP >> pf mtags: 48, 0, 0, 0, 0, 0, = 0 >> pf states: 296, 8000005, 0, 1313, 2279, 0, = 0 >> pf state keys: 88, 0, 0, 2655, 4558, 0, = 0 >> pf source nodes: 136, 1500025, 3, 142, 7, 0, = 0 >> pf table entries: 160, 800000, 4, 121, 47, 0, = 0 >> pf table counters: 64, 0, 0, 0, 0, 0, = 0 >> pf frags: 112, 0, 0, 0, 0, 0, = 0 >> pf frag entries: 40, 100000, 0, 0, 0, 0, = 0 >> pf state scrubs: 40, 0, 0, 0, 0, 0, = 0 >> >> >> I can reproduce this behavior by reloading pf.conf and running traffic= through >> the box and get a new entry added to source tracking table. >> >> Here is the nat rule: >> >> # pfctl -vsn >> nat on em0 inet from to any -> round-rob= in sticky-address >> [ Evaluations: 368 Packets: 50 Bytes: 2084 Stat= es: 0 ] >> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >> >> and timers: >> >> # pfctl -st >> tcp.first 10s >> tcp.opening 10s >> tcp.established 4200s >> tcp.closing 10s >> tcp.finwait 15s >> tcp.closed 10s >> tcp.tsdiff 30s >> udp.first 60s >> udp.single 30s >> udp.multiple 60s >> icmp.first 20s >> icmp.error 10s >> other.first 60s >> other.single 30s >> other.multiple 60s >> frag 30s >> interval 30s >> adaptive.start 0 states >> adaptive.end 0 states >> src.track 3600s >> >> Any ideas if this behavior is expected? >> >> =E2=80=94 >> Babak > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" --=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJ8BAEBCABmBQJZCC7ZXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMDgxNUY4ODYxQkYyREVBRjI2MUU5QzE2 QjI2N0FEODVENjMyRTlBAAoJEGsmethdYy6aw1QP/RkVIASAvKKmaUp+n5rPNs7l DXhi6PPp0IGrUb5bjwselgUucze/bt7S4yRgQIx2kgJs15Ao4M/3Bx63HveqZQRF ESf9AlwRsbh6DTp5fda33i4S4opXSisZdXf+5rhFBegfl85Mg8HoHP0XqghBIHsF A28F0ucEUBxvN+xNZQ/3XFE7HFQh16xjfvDtBF+gW8l6ECLLjKwB5uyrLLQqZYVk F7mERMbuoFDXaZSMEtxXTWPzNwJzTRgxsHd7xW42fVR6DIxosaWkSg9q4TaQIXI8 671tbjqKyAvZJNnDE+Jkh3+Bji3f2U6hZ4LzbRRJL572LVBv/lhuCAVo0+oUwqzO kwM2lRvbJmjHMUwqv2Plgx7vMFXcUASSOHeKHsWTf4yUlm4Sh3OSauXtLHLxW26R LHFAkQxmoRJbQcKUzOdtlFta9+/u2VfhVvZ+QYqH7OTIOZ3shbrXdlZHO4SgmaTJ lLzINMH8okCy1Sov3Nr9tvHF6M9vuypnkA1pH9Tl/buYtSN/dcy4rXK8MJ/uSIV8 6+g8SpaKtY2PB1Oa3oY5JusBE7VD2/PXNnNU8MsDADPWk2TqFSyp0seGUYJYUFW1 QxLGFQvmXmGu0zmnJqC2JMfTpJ/rDiKSA5FuJW6oJ9QXo9vTRxGasp8I5CKVCMRL 0O55hakSHrYrnF/jwkoW =bhE3 -----END PGP SIGNATURE----- --=_MailMate_4A2F611F-5A71-48C1-8F50-292E56BB64C4_=-- From owner-freebsd-pf@freebsd.org Tue May 2 11:56:18 2017 Return-Path: Delivered-To: freebsd-pf@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 15A7AD59B09 for ; Tue, 2 May 2017 11:56:18 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (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 CB54FBAE; Tue, 2 May 2017 11:56:15 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1d5WPZ-0005uu-Jf; Tue, 02 May 2017 14:56:09 +0300 Subject: Re: Similar entries in source tracking table To: Babak Farrokhi Cc: freebsd-pf@freebsd.org References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> From: Max Message-ID: <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru> Date: Tue, 2 May 2017 14:56:09 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 11:56:18 -0000 Could you set "src.track" to zero and check if the issue persists? 02.05.2017 10:01, Babak Farrokhi пишет: > Hello, > > Here it is: > > # pfctl -vvsS > No ALTQ support in kernel > ALTQ related functions disabled > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0 > > # pfctl -vvss > No ALTQ support in kernel > ALTQ related functions disabled > > I am running 11-STABLE r317643. Please note that this is only reproducible when you reload your pf configuration and tables. > > — > Babak > > > On 2 May 2017, at 10:41, Max wrote: > >> Hello, >> Can you show "pfctl -vsS" output? And what version of FreeBSD are you running? >> >> >> 01.05.2017 17:59, Babak Farrokhi пишет: >>> Hello, >>> >>> I was running an experiment with pf in which I encountered an unusual case. >>> >>> In a nat setup, is this okay to have multiple similar entries in source tracking table? >>> >>> # pfctl -sS >>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>> >>> There are actually three similar binding stuck in source tracking table. >>> vmstat output also confirms separate memory allocation for three entries in >>> source tracking table: >>> >>> # vmstat -z | egrep 'ITEM|^pf' >>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >>> pf mtags: 48, 0, 0, 0, 0, 0, 0 >>> pf states: 296, 8000005, 0, 1313, 2279, 0, 0 >>> pf state keys: 88, 0, 0, 2655, 4558, 0, 0 >>> pf source nodes: 136, 1500025, 3, 142, 7, 0, 0 >>> pf table entries: 160, 800000, 4, 121, 47, 0, 0 >>> pf table counters: 64, 0, 0, 0, 0, 0, 0 >>> pf frags: 112, 0, 0, 0, 0, 0, 0 >>> pf frag entries: 40, 100000, 0, 0, 0, 0, 0 >>> pf state scrubs: 40, 0, 0, 0, 0, 0, 0 >>> >>> >>> I can reproduce this behavior by reloading pf.conf and running traffic through >>> the box and get a new entry added to source tracking table. >>> >>> Here is the nat rule: >>> >>> # pfctl -vsn >>> nat on em0 inet from to any -> round-robin sticky-address >>> [ Evaluations: 368 Packets: 50 Bytes: 2084 States: 0 ] >>> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >>> >>> and timers: >>> >>> # pfctl -st >>> tcp.first 10s >>> tcp.opening 10s >>> tcp.established 4200s >>> tcp.closing 10s >>> tcp.finwait 15s >>> tcp.closed 10s >>> tcp.tsdiff 30s >>> udp.first 60s >>> udp.single 30s >>> udp.multiple 60s >>> icmp.first 20s >>> icmp.error 10s >>> other.first 60s >>> other.single 30s >>> other.multiple 60s >>> frag 30s >>> interval 30s >>> adaptive.start 0 states >>> adaptive.end 0 states >>> src.track 3600s >>> >>> Any ideas if this behavior is expected? >>> >>> — >>> Babak >> _______________________________________________ >> freebsd-pf@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-pf >> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@freebsd.org Tue May 2 12:51:50 2017 Return-Path: Delivered-To: freebsd-pf@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 0832FD5A723 for ; Tue, 2 May 2017 12:51:50 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from mail.farrokhi.net (mail.farrokhi.net [79.127.49.115]) (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 5DC63817 for ; Tue, 2 May 2017 12:51:49 +0000 (UTC) (envelope-from farrokhi@FreeBSD.org) Received: from [172.16.148.1] (unknown [79.127.49.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: freebsd@farrokhi.net) by mail.farrokhi.net (Postfix) with ESMTPSA id D78F636222; Tue, 2 May 2017 17:21:45 +0430 (IRDT) From: "Babak Farrokhi" To: Max Cc: freebsd-pf@freebsd.org Subject: Re: Similar entries in source tracking table Date: Tue, 02 May 2017 17:21:44 +0430 Message-ID: <015E448C-4021-490D-A83E-1D1DB02110CB@FreeBSD.org> In-Reply-To: <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru> References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Mailer: MailMate (1.9.6r5371) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 12:51:50 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, After setting src.track to 0 I could reproduce the situation, but this ti= me both entries disappeared after a short while (as per =E2=80=9Cinterval=E2= =80=9D timer setting). =E2=80=94 Babak On 2 May 2017, at 16:26, Max wrote: > Could you set "src.track" to zero and check if the issue persists? > > > 02.05.2017 10:01, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> Hello, >> >> Here it is: >> >> # pfctl -vvsS >> No ALTQ support in kernel >> ALTQ related functions disabled >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 >> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s = ) >> age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0= >> >> # pfctl -vvss >> No ALTQ support in kernel >> ALTQ related functions disabled >> >> I am running 11-STABLE r317643. Please note that this is only reproduc= ible when you reload your pf configuration and tables. >> >> =E2=80=94 >> Babak >> >> >> On 2 May 2017, at 10:41, Max wrote: >> >>> Hello, >>> Can you show "pfctl -vsS" output? And what version of FreeBSD are you= running? >>> >>> >>> 01.05.2017 17:59, Babak Farrokhi =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>>> Hello, >>>> >>>> I was running an experiment with pf in which I encountered an unusua= l case. >>>> >>>> In a nat setup, is this okay to have multiple similar entries in sou= rce tracking table? >>>> >>>> # pfctl -sS >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0= s ) >>>> >>>> There are actually three similar binding stuck in source tracking ta= ble. >>>> vmstat output also confirms separate memory allocation for three ent= ries in >>>> source tracking table: >>>> >>>> # vmstat -z | egrep 'ITEM|^pf' >>>> ITEM SIZE LIMIT USED FREE REQ FAIL S= LEEP >>>> pf mtags: 48, 0, 0, 0, 0, 0,= 0 >>>> pf states: 296, 8000005, 0, 1313, 2279, 0= , 0 >>>> pf state keys: 88, 0, 0, 2655, 4558, 0,= 0 >>>> pf source nodes: 136, 1500025, 3, 142, 7, 0= , 0 >>>> pf table entries: 160, 800000, 4, 121, 47, 0,= 0 >>>> pf table counters: 64, 0, 0, 0, 0, 0,= 0 >>>> pf frags: 112, 0, 0, 0, 0, 0,= 0 >>>> pf frag entries: 40, 100000, 0, 0, 0, 0,= 0 >>>> pf state scrubs: 40, 0, 0, 0, 0, 0,= 0 >>>> >>>> >>>> I can reproduce this behavior by reloading pf.conf and running traff= ic through >>>> the box and get a new entry added to source tracking table. >>>> >>>> Here is the nat rule: >>>> >>>> # pfctl -vsn >>>> nat on em0 inet from to any -> round-r= obin sticky-address >>>> [ Evaluations: 368 Packets: 50 Bytes: 2084 S= tates: 0 ] >>>> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >>>> >>>> and timers: >>>> >>>> # pfctl -st >>>> tcp.first 10s >>>> tcp.opening 10s >>>> tcp.established 4200s >>>> tcp.closing 10s >>>> tcp.finwait 15s >>>> tcp.closed 10s >>>> tcp.tsdiff 30s >>>> udp.first 60s >>>> udp.single 30s >>>> udp.multiple 60s >>>> icmp.first 20s >>>> icmp.error 10s >>>> other.first 60s >>>> other.single 30s >>>> other.multiple 60s >>>> frag 30s >>>> interval 30s >>>> adaptive.start 0 states >>>> adaptive.end 0 states >>>> src.track 3600s >>>> >>>> Any ideas if this behavior is expected? >>>> >>>> =E2=80=94 >>>> Babak >>> _______________________________________________ >>> freebsd-pf@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf >>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"= --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQJ8BAEBCABmBQJZCIDgXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGMDgxNUY4ODYxQkYyREVBRjI2MUU5QzE2 QjI2N0FEODVENjMyRTlBAAoJEGsmethdYy6aRl8P/0+kooiVb/ScbZEA8eUbp/lM 1sDdqu0siKoIMQtF0JpITPnmcWEJvFZyJwDKsxEwGc9pWsIDjSO4xPR4zNMBbw3s /mDpLCuXV/pSztGpVgnuiGhWHaf93WVjtkvJNReRLvjoqTEt6piC5LLQnjxT1Wk0 vFgvpySpfBEz9dAu7OX86o+8itwOcD7/tGhcqUhyw9YuDFZy0FfvSxeWcoi9XEEc 5Sv0tXfjneTE2m8JEol7kQ++sezGf83yK41zuSXxxUhffPagR4WO0Q+tROhr1gBj ItmC+5eKln5gikLJBit2lq4ZrddCgUvptzJISBiJYHcfmqtrWDpqqLIsLIqJVfql aeKDoi0Sy2EgJlcsKrPnQ1BKq6eEl2vayhAkPk3z46yTDBSIKqQbnGHGP8I7LlYG Ab4tx/+/QNndTFzaXa3JeimXXHQNfHTWyjEP3/JOucMlS4P7LSzesS/ivE08UnOf khXdfx6NpyLAA6BW0lBTvBY4YuJFvKwUNafFs614jTnR6jnYnBVYi3t6QfZEZISO Y8CDZsdWaeGnhwAmG59qd5tPIOVxPeWp0aud3N3rZoc16jP1FdZfbo6UAl6zD9O/ QCdITOh1qfjDRoejn9X1krPwa5cCvJELQI6IKQ0JTcEojZhXYbDLCkp04pRFVhIP JDAyAXDEN/BlSuuOLXOy =3U3h -----END PGP SIGNATURE----- --=_MailMate_F1DACEB0-4942-44FF-ADBA-6D77B00540F5_=-- From owner-freebsd-pf@freebsd.org Tue May 2 15:56:20 2017 Return-Path: Delivered-To: freebsd-pf@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 3B785D5AF36 for ; Tue, 2 May 2017 15:56:20 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from mx.als.nnov.ru (mx.als.nnov.ru [95.79.102.161]) (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 F105F1562; Tue, 2 May 2017 15:56:18 +0000 (UTC) (envelope-from maximos@als.nnov.ru) Received: from [10.4.1.100] by mx.als.nnov.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1d5a9u-000GRw-LL; Tue, 02 May 2017 18:56:14 +0300 Subject: Re: Similar entries in source tracking table To: Babak Farrokhi Cc: freebsd-pf@freebsd.org References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> <45a09f51-7b96-f7c1-e53b-9421fd1befbd@als.nnov.ru> <96849677-28a6-1c7c-ccbb-2642aacd1813@als.nnov.ru> <015E448C-4021-490D-A83E-1D1DB02110CB@FreeBSD.org> From: Max Message-ID: <7577c6b9-479a-6c58-89b3-9eef5ce5e9d2@als.nnov.ru> Date: Tue, 2 May 2017 18:56:14 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.0.1 MIME-Version: 1.0 In-Reply-To: <015E448C-4021-490D-A83E-1D1DB02110CB@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 15:56:20 -0000 It's OK to have more than one source record in this case. I guess they belong to different instances of your ruleset. And expired entries are removed. However, it might be a problem if they have a big timeout. 02.05.2017 15:51, Babak Farrokhi пишет: > Hello, > > After setting src.track to 0 I could reproduce the situation, but this time > both entries disappeared after a short while (as per “interval” timer setting). > > — > Babak > > On 2 May 2017, at 16:26, Max wrote: > >> Could you set "src.track" to zero and check if the issue persists? >> >> >> 02.05.2017 10:01, Babak Farrokhi пишет: >>> Hello, >>> >>> Here it is: >>> >>> # pfctl -vvsS >>> No ALTQ support in kernel >>> ALTQ related functions disabled >>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>> age 00:00:53, expires in 00:59:52, 6 pkts, 504 bytes, nat rule 0 >>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>> age 00:01:21, expires in 00:59:20, 16 pkts, 1344 bytes, nat rule 0 >>> >>> # pfctl -vvss >>> No ALTQ support in kernel >>> ALTQ related functions disabled >>> >>> I am running 11-STABLE r317643. Please note that this is only reproducible when you reload your pf configuration and tables. >>> >>> — >>> Babak >>> >>> >>> On 2 May 2017, at 10:41, Max wrote: >>> >>>> Hello, >>>> Can you show "pfctl -vsS" output? And what version of FreeBSD are you running? >>>> >>>> >>>> 01.05.2017 17:59, Babak Farrokhi пишет: >>>>> Hello, >>>>> >>>>> I was running an experiment with pf in which I encountered an unusual case. >>>>> >>>>> In a nat setup, is this okay to have multiple similar entries in source tracking table? >>>>> >>>>> # pfctl -sS >>>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>>> 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) >>>>> >>>>> There are actually three similar binding stuck in source tracking table. >>>>> vmstat output also confirms separate memory allocation for three entries in >>>>> source tracking table: >>>>> >>>>> # vmstat -z | egrep 'ITEM|^pf' >>>>> ITEM SIZE LIMIT USED FREE REQ FAIL SLEEP >>>>> pf mtags: 48, 0, 0, 0, 0, 0, 0 >>>>> pf states: 296, 8000005, 0, 1313, 2279, 0, 0 >>>>> pf state keys: 88, 0, 0, 2655, 4558, 0, 0 >>>>> pf source nodes: 136, 1500025, 3, 142, 7, 0, 0 >>>>> pf table entries: 160, 800000, 4, 121, 47, 0, 0 >>>>> pf table counters: 64, 0, 0, 0, 0, 0, 0 >>>>> pf frags: 112, 0, 0, 0, 0, 0, 0 >>>>> pf frag entries: 40, 100000, 0, 0, 0, 0, 0 >>>>> pf state scrubs: 40, 0, 0, 0, 0, 0, 0 >>>>> >>>>> >>>>> I can reproduce this behavior by reloading pf.conf and running traffic through >>>>> the box and get a new entry added to source tracking table. >>>>> >>>>> Here is the nat rule: >>>>> >>>>> # pfctl -vsn >>>>> nat on em0 inet from to any -> round-robin sticky-address >>>>> [ Evaluations: 368 Packets: 50 Bytes: 2084 States: 0 ] >>>>> [ Inserted: uid 0 pid 6418 State Creations: 28 ] >>>>> >>>>> and timers: >>>>> >>>>> # pfctl -st >>>>> tcp.first 10s >>>>> tcp.opening 10s >>>>> tcp.established 4200s >>>>> tcp.closing 10s >>>>> tcp.finwait 15s >>>>> tcp.closed 10s >>>>> tcp.tsdiff 30s >>>>> udp.first 60s >>>>> udp.single 30s >>>>> udp.multiple 60s >>>>> icmp.first 20s >>>>> icmp.error 10s >>>>> other.first 60s >>>>> other.single 30s >>>>> other.multiple 60s >>>>> frag 30s >>>>> interval 30s >>>>> adaptive.start 0 states >>>>> adaptive.end 0 states >>>>> src.track 3600s >>>>> >>>>> Any ideas if this behavior is expected? >>>>> >>>>> — >>>>> Babak >>>> _______________________________________________ >>>> freebsd-pf@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-pf >>>> To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@freebsd.org Tue May 2 23:06:15 2017 Return-Path: Delivered-To: freebsd-pf@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 B6D7DD5BA61 for ; Tue, 2 May 2017 23:06:15 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 480DB69 for ; Tue, 2 May 2017 23:06:15 +0000 (UTC) (envelope-from vegeta@tuxpowered.net) Received: by mail-wr0-x22c.google.com with SMTP id z52so93199313wrc.2 for ; Tue, 02 May 2017 16:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuxpowered-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:organization:user-agent :in-reply-to:references:mime-version; bh=8mrvv912YEk4m+W8B//PrrD6KXBGNZAIJvlX9/OMznE=; b=TdGrh/LQVoYL0bKv+VtHIOEok9Lw7B9poULhodwjtNZ5sYW+7z/aJr8xfwXMwWuhBi h5qN1JMIKxDn6n015DxNt11e/4pr14wc1G4VqH4GpSdg/VlccpNW4A7U2hVDt78xSyh3 /7dYSr3yktdJkTsoE1vcWt0lFcLYDZT6mU8QMjxddNUX//0JSxAFq0P3QZWB7bgoQcP1 HAU635oWwJG3duBDkTsoa4LqI8CF28rr8+DChhjE862Xn0/Rm87wJ1lRtiP+hBRoPi5J fbKtkpVwX5g8YEL5GYePjjhr7mCVgOEueuLvqbrNfrbRu+N3nDr/qwx60bwu3jmOHwxP /OXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version; bh=8mrvv912YEk4m+W8B//PrrD6KXBGNZAIJvlX9/OMznE=; b=SO9Sa50nTjCULrEUJC1PAV3Axwkt2OHOQz1l0WS/hpnclxMBpi56EjMsHa2RE9VNdE a34kZ2ipI7Oe4R+dTBz+wVJLjYe4cuScO6XRwuuirp83tFo9HjJ7Fb4dxQKQh4VqtDq0 36rSbX091bwiM7Wt+zwk63uHM2AU7PQs4AzPSkCMt27C1RWDKvCMuak4tMgZNsGG8LoO 4PtHFj6T/1PBRkr77Wvm45sob7vgp5NfLMJJp2c7MFVNuEWHlYRqVnZHjEppaXwp7SWf HI9irZ8FUEF0FVNsbKeT+m3tXDIJXA+tsr6ZjHcjzwyPd6dVH68al1VKn23MwN0SUPls 0+/g== X-Gm-Message-State: AN3rC/7at4TcwvuPXUQMAJKhR0ALpmZuscCKnVle5QhvlUa17IgxJW8M blNuhlIDtpBIBFy1yyA= X-Received: by 10.223.168.97 with SMTP id l88mr21880584wrc.54.1493766373299; Tue, 02 May 2017 16:06:13 -0700 (PDT) Received: from energia.localnet ([2a02:8108:4b3f:d254::5]) by smtp.gmail.com with ESMTPSA id z31sm17118739wrb.41.2017.05.02.16.06.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2017 16:06:12 -0700 (PDT) From: Kajetan Staszkiewicz To: freebsd-pf@freebsd.org Subject: Re: Similar entries in source tracking table Date: Wed, 03 May 2017 01:06:02 +0200 Message-ID: <2288236.yDEDrzzsxi@energia> Organization: tuxpowered.net User-Agent: KMail/5.2.3 (Linux/4.9.0-22.1-liquorix-amd64; KDE/5.28.0; x86_64; ; ) In-Reply-To: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> References: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1972261.IPdCAyK2qX"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.23 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, 02 May 2017 23:06:15 -0000 --nextPart1972261.IPdCAyK2qX Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Dnia poniedzia=C5=82ek, 1 maja 2017 19:29:23 CEST Babak Farrokhi pisze: > Hello, >=20 > I was running an experiment with pf in which I encountered an unusual cas= e. >=20 > In a nat setup, is this okay to have multiple similar entries in source > tracking table? >=20 > # pfctl -sS > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) > 192.168.232.1 -> 192.168.0.104 ( states 0, connections 0, rate 0.0/0s ) Such entries can be created from different rules in currently loaded pf.con= f,=20 that includes multiple rules generated from a single line in pf.conf which= =20 contains a table of ports or interfaces which gets expanded to multiple rul= es=20 or they can be still alive from previous load of pf.conf. > I can reproduce this behavior by reloading pf.conf That is exactly the case. Each source tracking entry is bound to rule and w= hen=20 you load pf.conf a new set of rules replaces the old ones even if they are = the=20 same. =2D-=20 | pozdrawiam / greetings | powered by Debian, FreeBSD and CentOS | | Kajetan Staszkiewicz | jabber,email: vegeta()tuxpowered net | | Vegeta | www: http://vegeta.tuxpowered.net | `------------------------^---------------------------------------' --nextPart1972261.IPdCAyK2qX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQSOEQZObv2B8mf0JbnjtFCvbXs6FAUCWQkQ2gAKCRDjtFCvbXs6 FKlyAJ4jT1n7L4nKEVvkNrpa+HBZ9+y6aACg2U02jNMKZtvecJEttG7XKGXiObA= =F/i0 -----END PGP SIGNATURE----- --nextPart1972261.IPdCAyK2qX--