From owner-freebsd-pf@FreeBSD.ORG Mon Oct 28 01:01:50 2013 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 37C70735 for ; Mon, 28 Oct 2013 01:01:50 +0000 (UTC) (envelope-from telbizov@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0819D27D4 for ; Mon, 28 Oct 2013 01:01:49 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id aq17so10412713iec.34 for ; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J5eTplOWYYKyBTTOANBEXblG9XKABXjnJFMrR25SEpY=; b=abg7nnIukuNKsA5LIV1O/IQBGu4DbLMuvtPG2qIWe1UtSHW9CIXXMrwyb1ykjpiD0Q ArblwfSR98DQgj3DqaMHg3FE1LIYXkAXumySnuwNf3IC4d4+nI+9CWwUeedERqdKkT5M MJslAreoMm3DGLVKMG76ytKkuEgzllR8SF1kAk8fTL9AnMSKLRBy/PR+GDUE8nnJrHFA fBRYe4986d292gA6IqHmGDMPe7ep9mXvCs+p8zY6aFWGKRf0szmtU1pXm/qrHJ1YwCK1 oFv4F8ok9Zb4AQhpl9UdQ5D5+5QPGe6sI+TL5MJroXThEW+p7L6kqG8geRcXJQSrgYz2 XOjg== MIME-Version: 1.0 X-Received: by 10.50.61.205 with SMTP id s13mr6678027igr.29.1382922109201; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) Received: by 10.50.2.101 with HTTP; Sun, 27 Oct 2013 18:01:49 -0700 (PDT) In-Reply-To: <201310272303.24096.vegeta@tuxpowered.net> References: <201310270128.47766.vegeta@tuxpowered.net> <201310272303.24096.vegeta@tuxpowered.net> Date: Sun, 27 Oct 2013 18:01:49 -0700 Message-ID: Subject: Re: PF sanity check From: Rumen Telbizov To: Kajetan Staszkiewicz Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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, 28 Oct 2013 01:01:50 -0000 Thanks again for coming back with more comments Kajetan. > Cool. I know the states are different (due to direction differences) but I > > was wondering if > > there was a way around that to save on the number of states and somehow > get > > away with > > only 1 state. So now I understand having two states per connection is > fine. > > Why shouldn't it be? Searching through states is quite fast. Even with > hundreds > of thousands of states much faster than going through a few hundreds of > rules, > from my experience. Yeah, only the number of states was my concern. On a related note what is the maximum number of states that you have been able to sustain and in what amount of memory? I know it's pretty low memory overhead but still. In other words how much memory per state is being consumed by PF? Currently I am prepared to start with 200K states and the router has 24GB or RAM. What is a reasonable maximum that I can expect to be able to handle? I am monitoring closely (nagios + graphite) those states as well btw. > > *Is there any security risk in me allowing the traffic pass the external > > interface and then dropping it on the internal interface?* > > That depends if the traffic from the Internet can hit the router's IP stack > directly. For example if you assign public IPs of servers in VLANs to the > router's $ext_if and use nat or route-to to forward traffic to VLANs. > Whatever > does not hit those rules but is passed on $ext_if, will hit the router > itself > in such case. Yes, that's a good point! I should have mentioned that the first few rules take care of traffic going to the router itself and end with block quick from any to where is a constant table of {self}. No NAT. So I guess it was just an irrational fear that I wanted to make sure it's only me that having let the packet "half-way in" through the external interface is OK as long as I filter it on the internal/vlan interface. No further implications aside from traffic destined to the firewall itself. Correct ? Thanks for all your comments, -- Rumen Telbizov Unix Systems Administrator