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