Date: Mon, 01 May 2017 19:29:23 +0430 From: "Babak Farrokhi" <farrokhi@FreeBSD.org> To: freebsd-pf@freebsd.org Subject: Similar entries in source tracking table Message-ID: <5923A420-6BE6-4758-AE37-89C019F179E5@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
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 <internal-net> to any -> <external-net> 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_=--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5923A420-6BE6-4758-AE37-89C019F179E5>