From owner-freebsd-pf@freebsd.org Mon Jul 6 14:39:12 2015 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 BD081A9D3 for ; Mon, 6 Jul 2015 14:39:12 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50BD11289 for ; Mon, 6 Jul 2015 14:39:11 +0000 (UTC) (envelope-from freebsd-pf@dino.sk) Received: from zeta.dino.sk (fw1.dino.sk [84.245.95.252]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Mon, 06 Jul 2015 16:33:58 +0200 id 00E2C40F.559A91D7.0000697A Date: Mon, 6 Jul 2015 16:33:58 +0200 From: Milan Obuch To: Ian FREISLICH Cc: Daniel Hartmeier , freebsd-pf@freebsd.org Subject: Re: Large scale NAT with PF - some weird problem Message-ID: <20150706163358.11a67ecf@zeta.dino.sk> In-Reply-To: <20150629125432.7aff9e66@zeta.dino.sk> References: <20150629114506.1cfd6f1b@zeta.dino.sk> <14e119e8fa8.2755.abfb21602af57f30a7457738c46ad3ae@capeaugusta.com> <20150621195753.7b162633@zeta.dino.sk> <20150623112331.668395d1@zeta.dino.sk> <20150628100609.635544e0@zeta.dino.sk> <20150629082654.GA22693@insomnia.benzedrine.ch> <20150629105201.7ee24e38@zeta.dino.sk> <20150629092932.GC22693@insomnia.benzedrine.ch> <20150629125432.7aff9e66@zeta.dino.sk> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; i386-portbld-freebsd10.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 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, 06 Jul 2015 14:39:12 -0000 On Mon, 29 Jun 2015 12:54:32 +0200 Milan Obuch wrote: > On Mon, 29 Jun 2015 12:42:22 +0200 > Ian FREISLICH wrote: > > > Milan Obuch wrote: [ snip ] > > > In cisco speak, there is just > > > > > > ip route x.y.24.0 255.255.252.0 x.y.3.19 > > > > > > statement and that's it. Nothing more. Whole address range from > > > x.y.24.0 to x.y.27.254 is routed here as it should be. For > > > something like this ARP would be really evil solution. > > > > That's OK, as long as the NAT network is routed to your PF box it > > will work. > > > > This was just an explanation, I am sure this is OK, as I have some > network experience already for... well, a ong time. > > > The situation you mentioned in a previous message where you see > > lots and lots of NAT states for a single public IP address is what > > I suspected was happening. When you require more NAT states per > > IP than ephemeral ports you will run into issues because you will > > run out of NAT space. > > > > No, there were not much states per problematic IP, maybe just tens of > them for one or couple internal IPs. That's weird. > > > If the round-robin works with a smaller pool, then I suspect Glebius > > will be interested. > > > > Well, if he chimes in, I would only welcome that. Currently I am > waiting for any signs of troubles with shrinked pool, if there will be > any. > > Milan > For about a week, I did not receive any complaints, so I think it works for now. I still see some hits for src-limit counter in 'pfctl -vs info' output, currently at 347, so it is approx. at 50 hits a day. If there is some good docs on these counters, I surely would like to know. I mean something like 'if this counter reaches 1000 (or 1000 daily or something similar), then it is sign of some problem'. Also, in 'pfctl -sa' output, there are currently three states with states count of 4294967295, 4294967295 and 4294967293, respectively. This one is for me sign of some trouble as it strongly resembles underflow of 32 bit integer counter, interpreted as unsigned number. Regards, Milan