From owner-freebsd-pf@FreeBSD.ORG Sun Mar 23 02:49:48 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB46106564A for ; Sun, 23 Mar 2008 02:49:48 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: from mail.mastercabo.com.br (mail.mastercabo.com.br [200.179.179.14]) by mx1.freebsd.org (Postfix) with SMTP id 2B2928FC15 for ; Sun, 23 Mar 2008 02:49:47 +0000 (UTC) (envelope-from daniel@dgnetwork.com.br) Received: (qmail 88037 invoked by uid 1008); 23 Mar 2008 02:23:07 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.6-unknown (2006-10-03) on srvmail3 X-Spam-Level: X-Spam-Status: No, score=-1.8 required=4.7 tests=AWL,BAYES_00 autolearn=ham version=3.1.6-unknown Received: from unknown (HELO ?10.0.1.10?) (daniel@dgnetwork.com.br@200.243.216.68) by mail.mastercabo.com.br with SMTP; 23 Mar 2008 02:23:03 -0000 Message-ID: <47E5BD04.5050806@dgnetwork.com.br> Date: Sat, 22 Mar 2008 23:14:28 -0300 From: =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves?= Organization: DGNET Network Solutions User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org, freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: FreeBSD OS Detection and Uptime X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: daniel@dgnetwork.com.br 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, 23 Mar 2008 02:49:49 -0000 Which methods used to prevent OS detection and uptime (nmap) ? http://nmap.org/misc/defeat-nmap-osdetect.html#BSD I tried, but not work. From owner-freebsd-pf@FreeBSD.ORG Sun Mar 23 15:28:57 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D1801065673 for ; Sun, 23 Mar 2008 15:28:57 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.184]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8648FC13 for ; Sun, 23 Mar 2008 15:28:56 +0000 (UTC) (envelope-from rpaulo@gmail.com) Received: by fk-out-0910.google.com with SMTP id b27so3278920fka.11 for ; Sun, 23 Mar 2008 08:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; bh=I+OesYSpS/2dwZG3sqL/h1cRTXnHriWfgSh17IaNBBc=; b=boXzepw48uSrnIRdlhT7Uj3iFMLx28KF73b0sRBlknTLDy5RphAXg5hO1WaGYDoEvak1quc4BNYRjMFcCNFZpc6WysnXVbXJvxwdnbuLLhbHLLpYzgvCIa3uZmbZFKI+8syLmE08t/VvWr/f5k/tgQYEumcLdBvjVwniO2r9p54= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=date:from:to:cc:subject:message-id:references:mime-version:content-type:content-disposition:in-reply-to:user-agent:sender; b=oT8Zj5u9H/AkM59OiYtho40GoaYxQMa/TfPqnrvTIhcdXlYQTOppaswEiL/qv1hykt39VBJXpcGono+a9H6kYfzkcZhbwX/0zWnFDFJaregFpdGqShfeD/oAgQa2t2TCzcSoQWkPdtA5VXbAQ344Z34mwXrko58gTRppUR4D5SA= Received: by 10.78.107.8 with SMTP id f8mr17088864huc.23.1206284452036; Sun, 23 Mar 2008 08:00:52 -0700 (PDT) Received: from fnop.net ( [83.144.141.62]) by mx.google.com with ESMTPS id c22sm11255606ika.3.2008.03.23.08.00.50 (version=SSLv3 cipher=OTHER); Sun, 23 Mar 2008 08:00:51 -0700 (PDT) Date: Sun, 23 Mar 2008 15:00:38 +0000 From: Rui Paulo To: =?us-ascii?B?PT9JU08tODg1OS0xP1E/RGFuaWVsX0RpYXNfR29uPUU3YWx2ZXNf?= , ?=@fnop.net Message-ID: <20080323150038.GA17070@fnop.net> References: <47E5BD04.5050806@dgnetwork.com.br> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47E5BD04.5050806@dgnetwork.com.br> User-Agent: Mutt/1.5.17 (2007-11-01) Sender: Rui Paulo Cc: freebsd-hackers@freebsd.org, freebsd-pf@freebsd.org, freebsd-net@freebsd.org Subject: Re: FreeBSD OS Detection and Uptime X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2008 15:28:57 -0000 On Sat, Mar 22, 2008 at 11:14:28PM -0300, =?ISO-8859-1?Q?Daniel_Dias_Gon=E7alves_ wrote: > Which methods used to prevent OS detection and uptime (nmap) ? > http://nmap.org/misc/defeat-nmap-osdetect.html#BSD > I tried, but not work. The TCP Drop SYN+FIN sysctl might help. % sysctl -d net.inet.tcp.drop_synfin net.inet.tcp.drop_synfin: Drop TCP packets with SYN+FIN set Regards. -- Rui Paulo From owner-freebsd-pf@FreeBSD.ORG Sun Mar 23 19:25:10 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 57E95106566C; Sun, 23 Mar 2008 19:25:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 27E238FC12; Sun, 23 Mar 2008 19:25:10 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2NJP4Tf086618; Sun, 23 Mar 2008 19:25:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2NJP4WS086614; Sun, 23 Mar 2008 19:25:04 GMT (envelope-from linimon) Date: Sun, 23 Mar 2008 19:25:04 GMT Message-Id: <200803231925.m2NJP4WS086614@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/122014: [panic] FreeBSD 6.2 panic in pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 23 Mar 2008 19:25:10 -0000 Old Synopsis: FreeBSD 6.2 panic in pf New Synopsis: [panic] FreeBSD 6.2 panic in pf Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Sun Mar 23 19:24:46 UTC 2008 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=122014 From owner-freebsd-pf@FreeBSD.ORG Mon Mar 24 11:07:11 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2D6BF1065670 for ; Mon, 24 Mar 2008 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2C22C8FC28 for ; Mon, 24 Mar 2008 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2OB7Afa087880 for ; Mon, 24 Mar 2008 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2OB7AaT087876 for freebsd-pf@FreeBSD.org; Mon, 24 Mar 2008 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 24 Mar 2008 11:07:10 GMT Message-Id: <200803241107.m2OB7AaT087876@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-pf@FreeBSD.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 24 Mar 2008 11:07:11 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/111220 pf [pf] repeatable hangs while manipulating pf tables 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/82271 pf [pf] cbq scheduler cause bad latency o kern/92949 pf [pf] PF + ALTQ problems with latency o bin/116610 pf [patch] teach tcpdump(1) to cope with the new-style pf o kern/117827 pf [pf] [panic] kernel panic with pf and ng o kern/120281 pf [request] lost returning packets to PF for a rdr rule o kern/122014 pf [panic] FreeBSD 6.2 panic in pf 6 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o sparc/93530 pf [pf] Incorrect checksums when using pf's route-to on s o kern/93825 pf [pf] pf reply-to doesn't work o kern/106400 pf [pf] fatal trap 12 at restart of PF with ALTQ if ng0 d s conf/110838 pf tagged parameter on nat not working on FreeBSD 5.2 o kern/114095 pf [carp] carp+pf delay with high state limit o kern/114567 pf [pf] LOR pf_ioctl.c + if.c f kern/116645 pf [request] pfctl -k does not work in securelevel 3 o kern/118355 pf [pf] [patch] pfctl help message options order false -t f kern/119661 pf [pf] "queue (someq, empy_acks)" doesn't work o kern/120057 pf [patch] Allow proper settings of ALTQ_HFSC. The check o kern/121704 pf [pf] PF mangles loopback packets 11 problems total. From owner-freebsd-pf@FreeBSD.ORG Tue Mar 25 00:03:55 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17CD6106566C for ; Tue, 25 Mar 2008 00:03:55 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from mailfilter.dawnsign.com (cetus.dawnsign.com [216.70.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id E00C48FC1A for ; Tue, 25 Mar 2008 00:03:54 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from cetus.dawnsign.com (cetus.dawnsign.com [192.168.1.5]) by mailfilter.dawnsign.com (Postfix) with ESMTP id 1506D9582B; Mon, 24 Mar 2008 17:03:53 -0700 (PDT) Received: by cetus.dawnsign.com with Internet Mail Service (5.5.2657.72) id ; Mon, 24 Mar 2008 17:03:53 -0700 Message-ID: <9DE6EC5B5CF8C84281AE3D7454376A0D6D028B@cetus.dawnsign.com> From: Doug Sampson To: 'Max Laier' , freebsd-pf@freebsd.org Date: Mon, 24 Mar 2008 17:03:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: Subject: RE: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Mar 2008 00:03:55 -0000 > On Friday 21 March 2008 21:59:46 Doug Sampson wrote: > > I want to back up a client running packet filter. I am > using Bacula to > > backup this client to a Bacula server in the internal network. The > > Bacula client has two interfaces- one external and one internal. The > > client's internal IF is 192.168.1.25. The Bacula server is at > > 192.168.1.17. > > > > When I attempt to contact the Bacula file daemon on the client, it > > responds by sending packets to the Bacula server daemon at > a different > > port. It should contact the storage daemon at port 9103 but > instead it > > attempts to contact the storage daemon at a port address that is not > > 9103. Thus the backup job fails. > > > > I've tried rdr to no avail. Here's my pf.conf: > > > > mailfilter@/usr/local/etc# pfctl -vvnf /etc/pf.conf > > use "pfctl -vvsr" instead of -nf to make sure you really get > the rules > that are loaded and not those that you wanted to load. > mailfilter-root@/usr/local/etc# pfctl -vvsr No ALTQ support in kernel ALTQ related functions disabled @0 scrub in all fragment reassemble [ Evaluations: 18953753 Packets: 9488185 Bytes: 0 States: 0 ] @0 block drop in log all [ Evaluations: 125309 Packets: 710 Bytes: 107361 States: 0 ] @1 pass in log inet proto tcp from any to xxx.xxx.xxx.xxx port = smtp flags S/SA synproxy state [ Evaluations: 61682 Packets: 333 Bytes: 141046 States: 0 ] @2 pass out log inet proto tcp from xxx.xxx.xxx.xxx to any port = smtp flags S/SA synproxy state [ Evaluations: 92705 Packets: 0 Bytes: 0 States: 0 ] @3 pass in log inet proto tcp from 192.168.1.0/24 to 192.168.1.25 port = smtp flags S/SA synproxy state [ Evaluations: 78929 Packets: 0 Bytes: 0 States: 0 ] @4 pass in log quick on xl0 inet proto tcp from any to 192.168.1.25 port = ssh flags S/SA synproxy state [ Evaluations: 29478 Packets: 0 Bytes: 0 States: 0 ] @5 block drop in log quick on rl0 inet from 127.0.0.0/8 to any [ Evaluations: 75458 Packets: 0 Bytes: 0 States: 0 ] @6 block drop in log quick on rl0 inet from 192.168.0.0/16 to any [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 ] @7 block drop in log quick on rl0 inet from 172.16.0.0/12 to any [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 ] @8 block drop in log quick on rl0 inet from 10.0.0.0/8 to any [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 ] @9 block drop out log quick on rl0 inet from any to 127.0.0.0/8 [ Evaluations: 62532 Packets: 0 Bytes: 0 States: 0 ] @10 block drop out log quick on rl0 inet from any to 192.168.0.0/16 [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 ] @11 block drop out log quick on rl0 inet from any to 172.16.0.0/12 [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 ] @12 block drop out log quick on rl0 inet from any to 10.0.0.0/8 [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 ] @13 block drop in log quick on ! xl0 inet from 192.168.1.0/24 to any [ Evaluations: 125309 Packets: 0 Bytes: 0 States: 0 ] @14 block drop in log quick inet from 192.168.1.25 to any [ Evaluations: 112752 Packets: 0 Bytes: 0 States: 0 ] @15 pass in on xl0 inet from 192.168.1.0/24 to any [ Evaluations: 61682 Packets: 60947 Bytes: 17390149 States: 0 ] @16 pass out log on xl0 inet from any to 192.168.1.0/24 [ Evaluations: 124639 Packets: 51070 Bytes: 43963111 States: 0 ] @17 pass out log quick on xl0 inet from any to 10.8.0.0/24 [ Evaluations: 51070 Packets: 0 Bytes: 0 States: 0 ] @18 pass out on rl0 proto tcp all flags S/SA modulate state [ Evaluations: 64297 Packets: 53895 Bytes: 42581384 States: 4 ] @19 pass out on rl0 proto udp all keep state [ Evaluations: 12557 Packets: 23586 Bytes: 1793665 States: 0 ] @20 pass out on rl0 proto icmp all keep state [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 ] @21 pass in on rl0 inet proto tcp from any to 192.168.1.4 port = http flags S/SA synproxy state [ Evaluations: 74239 Packets: 0 Bytes: 0 States: 0 ] @22 pass in on xl0 inet proto tcp from any to 192.168.1.25 port = ssh keep state [ Evaluations: 112420 Packets: 0 Bytes: 0 States: 0 ] mailfilter-root@/usr/local/etc# According to the output of "pfctl -vvsr", the packets are being allowed back into the internal network which is what I want (according to rule #16). However, I don't quite understand why the Bacula client is asking for a higher port number other than 9103. I am not seeing this behavior on any of my other Bacula clients. Is there another way of writing rules that will enable the Bacula client to pass packets to the correct port number? > > From the rules you quote above, I don't see why pf should interfere with > ports towards your internal net, but then again you might be having other > rules loaded than you think you are - the pflog is a strong indication. True. ~Doug From owner-freebsd-pf@FreeBSD.ORG Tue Mar 25 09:21:53 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3E3051065674 for ; Tue, 25 Mar 2008 09:21:53 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from v-smtp-auth-relay-2.gradwell.net (v-smtp-auth-relay-2.gradwell.net [79.135.125.41]) by mx1.freebsd.org (Postfix) with ESMTP id 9C2228FC15 for ; Tue, 25 Mar 2008 09:21:52 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from 87-194-161-157.bethere.co.uk ([87.194.161.157] helo=[192.168.0.150] country=GB ident=gregh#pop3&nviz#net) by v-smtp-auth-relay-2.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.288) id 47e8c456.50bf.a32; Tue, 25 Mar 2008 09:22:30 +0000 (envelope-sender ) Message-ID: <47E8C41C.9020708@nviz.net> Date: Tue, 25 Mar 2008 09:21:32 +0000 From: Greg Hennessy User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Doug Sampson References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D028B@cetus.dawnsign.com> In-Reply-To: <9DE6EC5B5CF8C84281AE3D7454376A0D6D028B@cetus.dawnsign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Mar 2008 09:21:53 -0000 Doug Sampson wrote: >> On Friday 21 March 2008 21:59:46 Doug Sampson wrote: >> >>> I want to back up a client running packet filter. I am >>> >> using Bacula to >> >>> backup this client to a Bacula server in the internal network. The >>> Bacula client has two interfaces- one external and one internal. The >>> client's internal IF is 192.168.1.25. The Bacula server is at >>> 192.168.1.17. >>> >>> When I attempt to contact the Bacula file daemon on the client, it >>> responds by sending packets to the Bacula server daemon at >>> >> a different >> >>> port. It should contact the storage daemon at port 9103 but >>> >> instead it >> >>> attempts to contact the storage daemon at a port address that is not >>> 9103. Thus the backup job fails. >>> >>> I've tried rdr to no avail. Here's my pf.conf: >>> >>> mailfilter@/usr/local/etc# pfctl -vvnf /etc/pf.conf >>> >> use "pfctl -vvsr" instead of -nf to make sure you really get >> the rules >> that are loaded and not those that you wanted to load. >> >> > > mailfilter-root@/usr/local/etc# pfctl -vvsr > No ALTQ support in kernel > ALTQ related functions disabled > @0 scrub in all fragment reassemble > [ Evaluations: 18953753 Packets: 9488185 Bytes: 0 States: 0 > ] > @0 block drop in log all > [ Evaluations: 125309 Packets: 710 Bytes: 107361 States: 0 > ] > @1 pass in log inet proto tcp from any to xxx.xxx.xxx.xxx port = smtp flags > S/SA synproxy state > [ Evaluations: 61682 Packets: 333 Bytes: 141046 States: 0 > ] > @2 pass out log inet proto tcp from xxx.xxx.xxx.xxx to any port = smtp flags > S/SA synproxy state > [ Evaluations: 92705 Packets: 0 Bytes: 0 States: 0 > ] > @3 pass in log inet proto tcp from 192.168.1.0/24 to 192.168.1.25 port = > smtp flags S/SA synproxy state > [ Evaluations: 78929 Packets: 0 Bytes: 0 States: 0 > ] > @4 pass in log quick on xl0 inet proto tcp from any to 192.168.1.25 port = > ssh flags S/SA synproxy state > [ Evaluations: 29478 Packets: 0 Bytes: 0 States: 0 > ] > @5 block drop in log quick on rl0 inet from 127.0.0.0/8 to any > [ Evaluations: 75458 Packets: 0 Bytes: 0 States: 0 > ] > @6 block drop in log quick on rl0 inet from 192.168.0.0/16 to any > [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 > ] > @7 block drop in log quick on rl0 inet from 172.16.0.0/12 to any > [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 > ] > @8 block drop in log quick on rl0 inet from 10.0.0.0/8 to any > [ Evaluations: 670 Packets: 0 Bytes: 0 States: 0 > ] > @9 block drop out log quick on rl0 inet from any to 127.0.0.0/8 > [ Evaluations: 62532 Packets: 0 Bytes: 0 States: 0 > ] > @10 block drop out log quick on rl0 inet from any to 192.168.0.0/16 > [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 > ] > @11 block drop out log quick on rl0 inet from any to 172.16.0.0/12 > [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 > ] > @12 block drop out log quick on rl0 inet from any to 10.0.0.0/8 > [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 > ] > @13 block drop in log quick on ! xl0 inet from 192.168.1.0/24 to any > [ Evaluations: 125309 Packets: 0 Bytes: 0 States: 0 > ] > @14 block drop in log quick inet from 192.168.1.25 to any > [ Evaluations: 112752 Packets: 0 Bytes: 0 States: 0 > ] > @15 pass in on xl0 inet from 192.168.1.0/24 to any > [ Evaluations: 61682 Packets: 60947 Bytes: 17390149 States: 0 > ] > @16 pass out log on xl0 inet from any to 192.168.1.0/24 > [ Evaluations: 124639 Packets: 51070 Bytes: 43963111 States: 0 > ] > @17 pass out log quick on xl0 inet from any to 10.8.0.0/24 > [ Evaluations: 51070 Packets: 0 Bytes: 0 States: 0 > ] > @18 pass out on rl0 proto tcp all flags S/SA modulate state > [ Evaluations: 64297 Packets: 53895 Bytes: 42581384 States: 4 > ] > @19 pass out on rl0 proto udp all keep state > [ Evaluations: 12557 Packets: 23586 Bytes: 1793665 States: 0 > ] > @20 pass out on rl0 proto icmp all keep state > [ Evaluations: 12557 Packets: 0 Bytes: 0 States: 0 > ] > @21 pass in on rl0 inet proto tcp from any to 192.168.1.4 port = http flags > S/SA synproxy state > [ Evaluations: 74239 Packets: 0 Bytes: 0 States: 0 > ] > @22 pass in on xl0 inet proto tcp from any to 192.168.1.25 port = ssh keep > state > [ Evaluations: 112420 Packets: 0 Bytes: 0 States: 0 > ] > mailfilter-root@/usr/local/etc# > > According to the output of "pfctl -vvsr", the packets are being allowed back > into the internal network which is what I want (according to rule #16). > That's part of the problem..... > Is there another way of writing rules that will enable the Bacula client to > pass packets to the correct port number? > Yes, make the 1st rule block log all to drop both ingress and egress traffic by default. Secondly get rid of the stateless rules. Use keep state everywhere, with flags S/SA if matching tcp traffic. Regards Greg From owner-freebsd-pf@FreeBSD.ORG Tue Mar 25 22:53:24 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA61A106564A for ; Tue, 25 Mar 2008 22:53:24 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from mailfilter.dawnsign.com (cetus.dawnsign.com [216.70.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id 73F048FC14 for ; Tue, 25 Mar 2008 22:53:24 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from cetus.dawnsign.com (cetus.dawnsign.com [192.168.1.5]) by mailfilter.dawnsign.com (Postfix) with ESMTP id 5C15C9582A; Tue, 25 Mar 2008 15:53:24 -0700 (PDT) Received: by cetus.dawnsign.com with Internet Mail Service (5.5.2657.72) id ; Tue, 25 Mar 2008 15:53:24 -0700 Message-ID: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> From: Doug Sampson To: 'Greg Hennessy' Date: Tue, 25 Mar 2008 15:53:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Cc: freebsd-pf@freebsd.org Subject: RE: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 25 Mar 2008 22:53:24 -0000 > > Is there another way of writing rules that will enable the > Bacula client to > > pass packets to the correct port number? > > > Yes, make the 1st rule > > block log all > > to drop both ingress and egress traffic by default. > > Secondly get rid of the stateless rules. Use keep state > everywhere, with > flags S/SA if matching tcp traffic. > > I hate to bug you guys but I ain't a pf guru like you guys. I am not understanding the significance of the "keep state" and the "flags S/SA synproxy state" qualifiers. I have been copying some rules from articles here and there. Thus these rules are not unified in the sense that these are designed from the beginning to work harmoniously. Would it be helpful if I supplied the actual pf.conf below and let you have at it? See the new addition I added today below in which I added "keep state" at the end of the rule. Would this enable the Bacula client to accept packets from the Bacula server and send packets out to port 9103 on the Bacula server? Here's my pf.conf: # $FreeBSD: src/etc/pf.conf,v 1.2.2.1 2006/04/04 20:31:20 mlaier Exp $ # $OpenBSD: pf.conf,v 1.21 2003/09/02 20:38:44 david Exp $ # # See pf.conf(5) and /usr/share/examples/pf for syntax and examples. # Required order: options, normalization, queueing, translation, filtering. # Macros and tables may be defined and used anywhere. # Note that translation rules are first match while filter rules are last match. # Macros: define common values, so they can be referenced and changed easily. ext_if="rl0" # replace with actual external interface name i.e., dc0 int_if="xl0" # replace with actual internal interface name i.e., dc1 internal_net="192.168.1.1/24" external_addr="xxx.xxx.xxx.xxx" vpn_net="xxx.xxx.xxx.xxx/24" # Added by DSS - 2/28/07 NoRouteIPs = "{ 127.0.0.0/8 192.168.0.0/16 172.16.0.0/12 10.0.0.0/8 }" # machines inside webserver ="192.168.1.4" set skip on lo0 set skip on gif0 # Normalization: reassemble fragments and resolve or reduce traffic ambiguities. scrub in all # Translation: specify how addresses are to be mapped or redirected. # nat: packets going out through $ext_if with source address $internal_net will # get translated as coming from the address of $ext_if, a state is created for # such packets, and incoming packets will be redirected to the internal address. nat on $ext_if from $internal_net to any -> ($ext_if) nat on $ext_if from $vpn_net to any -> ($ext_if) # rdr: packets coming in on $ext_if with destination $external_addr:1234 will # be redirected to 10.1.1.1:5678. A state is created for such packets, and # outgoing packets will be translated as coming from the external address. #rdr on $ext_if proto tcp from any to $external_addr/32 port 1234 -> 10.1.1.1 port 5678 rdr on $ext_if proto tcp from any to $external_addr/32 port 80 -> $webserver port 80 # spamd-setup puts addresses to be redirected into table . table persist table persist table persist file "/usr/local/etc/spamd/spamd-mywhite" # redirect to spamd #rdr inet proto tcp from to any port smtp -> 127.0.0.1 port 8025 rdr pass inet proto tcp from to $external_addr port smtp -> 127.0.0.1 port smtp rdr pass inet proto tcp from to $external_addr port smtp -> 127.0.0.1 port spamd rdr pass inet proto tcp from ! to $external_addr port smtp -> 127.0.0.1 port spamd # block all incoming packets but allow ssh, pass all outgoing tcp and udp # connections and keep state, logging blocked packets. block in log all # allow inbound/outbound mail! pass in log inet proto tcp from any to $external_addr port smtp flags S/SA synproxy state pass out log inet proto tcp from $external_addr to any port smtp flags S/SA synproxy state pass in log inet proto tcp from $internal_net to $int_if port smtp flags S/SA synproxy state # added by DSS - 2/28/07 pass in quick log on $int_if proto tcp from any to $int_if port 22 flags S/SA synproxy state block in quick log on $ext_if from $NoRouteIPs to any block out quick log on $ext_if from any to $NoRouteIPs antispoof log quick for $int_if inet # pass all traffic to and from the local network pass in on $int_if from $internal_net to any pass out log on $int_if from any to $internal_net pass out quick log on $int_if from any to $vpn_net pass out on $ext_if proto tcp all modulate state flags S/SA pass out on $ext_if proto { udp, icmp } all keep state pass in on $ext_if inet proto tcp from any to $webserver port 80 flags S/SA synproxy state pass in on $int_if proto tcp from any to $int_if port 22 keep state # added by DSS - 3/25/08 pass in on $int_if proto tcp from any to $int_if port 9102 keep state # end of DSS's additions Thank you! ~Doug From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 02:53:17 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 22606106566B for ; Wed, 26 Mar 2008 02:53:17 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id 092CA8FC1F for ; Wed, 26 Mar 2008 02:53:16 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id CBBDF1CC060; Tue, 25 Mar 2008 19:53:16 -0700 (PDT) Date: Tue, 25 Mar 2008 19:53:16 -0700 From: Jeremy Chadwick To: Doug Sampson Message-ID: <20080326025316.GA68607@eos.sc1.parodius.com> References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: 'Greg Hennessy' , freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 02:53:17 -0000 On Tue, Mar 25, 2008 at 03:53:15PM -0700, Doug Sampson wrote: > > > Is there another way of writing rules that will enable the > > Bacula client to > > > pass packets to the correct port number? > > > > > Yes, make the 1st rule > > > > block log all > > > > to drop both ingress and egress traffic by default. > > > > Secondly get rid of the stateless rules. Use keep state > > everywhere, with > > flags S/SA if matching tcp traffic. This isn't a reply to you (Doug), but -- do not blindly use "keep state" everywhere! There's been too many cases I've experienced where using "keep state" blindly results in state-mismatch increasing at a very fast rate. When I implemented this mentality on our production servers, our users started pointing out that scp's between machines would randomly get severed mis-stream, same with ssh sessions where large TCP windows were used (such as doing 'dmesg' over and over): http://lists.freebsd.org/pipermail/freebsd-pf/2008-January/004050.html The "use keep state on everything!" attitude seems to stem from people reading the OpenBSD pf.conf documentation, which states that as of OpenBSD 4.1, "keep state" is implicit on every rule (meaning it's done whether you say "keep state" or not). FreeBSD's pf isn't like this. > I hate to bug you guys but I ain't a pf guru like you guys. I am not > understanding the significance of the "keep state" and the "flags S/SA > synproxy state" qualifiers. I have been copying some rules from articles > here and there. Thus these rules are not unified in the sense that these are > designed from the beginning to work harmoniously. The easiest way to explain "keep state" is: with rules that use "keep state", every time a packet matching that rule is encountered, pf keeps track of the current TCP state and permits/denies based on the TCP state, rather than having to reiterate through all of your rulesets over and over. I'll try to explain it with a very small ruleset and a couple scenarios: $ext_if = network interface that's got a public IP address 4.4.4.4 = our public IP address pass out quick all flags S/SA keep state pass out quick all block in log all pass in quick on $ext_if inet proto tcp from any to 4.4.4.4 port ssh Two scenarios: 1) When an incoming TCP packet from to 4.4.4.4 on port 22 is seen, that incoming packet is permitted (rule #4). Outbound responses from 4.4.4.4 to are also permitted (rule #1). Note the "keep state". pf will begin keep tracking of the TCP state from that point forward, which means it doesn't have to reiterate through your rules to continue passing inbound/outbound traffic for that TCP session. 2) An outbound TCP packet from 4.4.4.4 port 50345 to 12.90.124.50 port 25 is attempted. That packet is permitted (rule #1), and the TCP state is tracked in pf. The *response* packets from 12.90.124.50 port 25 to 4.4.4.4 port 50345 are also permitted -- yet you see no rule for such, do you? This is because pf's state tracking ("keep state") is doing the pass/deny for you. It gets more confusing when you consider the fact that even though UDP and ICMP are stateless protocols, pf can keep track of their state too, though I don't know if FreeBSD pf supports that (OpenBSD pf does). Now, about flags S/SA -- you need to understand how TCP works to really understand what purpose this serves. "flags" causes pf to look at only certain TCP flags (bits), and check to see which of those bits are set or clear. You can check against FIN, SYn, RST, PSH, ACK, URG, ECE, and CWR. That criteria must be matched for the rule in question to be used. The official docs are here, which also describes synproxy (which I haven't used): http://www.openbsd.org/faq/pf/filter.html#tcpflags Let's take rule #1 in the above ruleset: pass out quick all flags S/SA keep state This means pass any outbound traffic (from any IP address of ours) with the TCP flag SYN set (but only look at the SYN and ACK flags when doing that comparison) -- and keep track of TCP state. This explanation should also provide you an answer to what rule #2 is for -- permitting outbound packets which DO NOT match that criteria. You might be wondering "so why not nuke rule #1 and just use #2?", to which my reply would be, "see Scenario #2 -- incoming packets from 12.90.124.50 port 25 to 4.4.4.4 port 50345 would then get blocked!" Does this make more sense to you? :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 09:07:55 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3568A106566B for ; Wed, 26 Mar 2008 09:07:55 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe9.ukr.net (ffe9.ukr.net [195.214.192.28]) by mx1.freebsd.org (Postfix) with ESMTP id E58208FC21 for ; Wed, 26 Mar 2008 09:07:54 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from mail by ffe9.ukr.net with local ID 1JeRMO-000DPt-Bg for freebsd-pf@freebsd.org; Wed, 26 Mar 2008 10:51:52 +0200 MIME-Version: 1.0 To: freebsd-pf@freebsd.org From: "Vitaliy Vladimirovich" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.4.1 X-Originating-Ip: [194.0.148.10] X-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Message-Id: Date: Wed, 26 Mar 2008 10:51:52 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: PF rules for internal interface X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 09:07:55 -0000 Hello! I have problem with restriction rules for my internal interface. This is my rules for $int_if: pass out quick on $int_if block in on $int_if pass in on $int_if from $mynet to any But in this situation computers from another subnets can ping my internal interface. Were is my mistake? Thanks in advance. From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 09:09:48 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13622106566B for ; Wed, 26 Mar 2008 09:09:48 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from v-smtp-auth-relay-1.gradwell.net (v-smtp-auth-relay-1.gradwell.net [79.135.125.40]) by mx1.freebsd.org (Postfix) with ESMTP id 57F8E8FC2E for ; Wed, 26 Mar 2008 09:09:47 +0000 (UTC) (envelope-from Greg.Hennessy@nviz.net) Received: from 87-194-161-157.bethere.co.uk ([87.194.161.157] helo=[192.168.0.227] country=GB ident=gregh*pop3&nviz$net) by v-smtp-auth-relay-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.287) id 47ea12eb.1106.16ed; Wed, 26 Mar 2008 09:10:03 +0000 (envelope-sender ) Message-ID: <47EA12CA.90305@nviz.net> Date: Wed, 26 Mar 2008 09:09:30 +0000 From: Greg Hennessy User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Jeremy Chadwick References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> In-Reply-To: <20080326025316.GA68607@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 09:09:48 -0000 Jeremy Chadwick wrote: > This isn't a reply to you (Doug), but -- do not blindly use "keep state" > everywhere! > Hard cases make for bad laws. I have got to point out the error in the above statement. > There's been too many cases I've experienced where using "keep state" > blindly results in state-mismatch increasing at a very fast rate. When > I implemented this mentality on our production servers, our users > started pointing out that scp's between machines would randomly get > severed mis-stream, same with ssh sessions where large TCP windows were > used (such as doing 'dmesg' over and over): > > http://lists.freebsd.org/pipermail/freebsd-pf/2008-January/004050.html > Which (taking a rough guess) looking at your rule set in the above has very little to do with 'keep state' and a lot to do with 'modulate state'. IIRC there is a filed bug which displays all of the aforementioned symptoms when modulate state meets selective acknowledgement (SACK). I'm sure Max has the gory detail, it may even be fixed. > The "use keep state on everything!" attitude seems to stem from people > reading the OpenBSD pf.conf documentation, which states that as of > OpenBSD 4.1, "keep state" is implicit on every rule (meaning it's done > whether you say "keep state" or not). FreeBSD's pf isn't like this. > You miss out the most important bit of the new PF 4.1 state keeping defaults, 'flags S/SA'. Our cousins over the road in the OpenBSD neighbourhood have done this precisely because of the issues caused in prior versions of PF by using stateless rules and/or establishing TCP state on anything other than the 3 way handshake. > > It gets more confusing when you consider the fact that even though UDP > and ICMP are stateless protocols, pf can keep track of their state too, > though I don't know if FreeBSD pf supports that (OpenBSD pf does). > This is not a flame, but if you really do not know that, you really should not be publicly advocating a position on the basis of incomplete information. Regards Greg From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 10:00:30 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3252106566B for ; Wed, 26 Mar 2008 10:00:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id D70648FC15 for ; Wed, 26 Mar 2008 10:00:30 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id B8C411CC060; Wed, 26 Mar 2008 03:00:30 -0700 (PDT) Date: Wed, 26 Mar 2008 03:00:30 -0700 From: Jeremy Chadwick To: Vitaliy Vladimirovich Message-ID: <20080326100030.GA79074@eos.sc1.parodius.com> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-pf@freebsd.org Subject: Re: PF rules for internal interface X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 10:00:31 -0000 On Wed, Mar 26, 2008 at 10:51:52AM +0200, Vitaliy Vladimirovich wrote: > Hello! I have problem with restriction rules for my internal interface. > ... Please don't stick stuff like this all on one line. It's impossible to read. > This is my rules for $int_if: > > pass out quick on $int_if > block in on $int_if > pass in on $int_if from $mynet to any > > But in this situation computers from another subnets can ping my > internal interface. Were is my mistake? Thanks in advance. Are these the ONLY RULES you have in your pf.conf? If not: you must remember that the deny/block in "block in on $int_if" may get overridden later in the file, depending upon what rules past that point are. This may be what's happening, assuming later rules do not specify an interface (thus matching all interfaces). For example, if your rules are: pass out quick on $int_if block in on $int_if pass in on $int_if from $mynet to any pass in from $othernet to any In this case, the "block" will not happen when incoming packets from $othernet arrive on $int_if. I've two recommendations: 1) Consider using "antispoof", if your concern is someone spoofing packets across $int_if 2) Consider using these rules instead: pass in quick on $int_if from $mynet to any pass out quick on $int_if from $mynet to any block in quick on $int_if {...other rules...} -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 10:55:03 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3713F1065670 for ; Wed, 26 Mar 2008 10:55:03 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe7.ukr.net (ffe7.ukr.net [195.214.192.26]) by mx1.freebsd.org (Postfix) with ESMTP id E34998FC16 for ; Wed, 26 Mar 2008 10:55:02 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from mail by ffe7.ukr.net with local ID 1JeTHY-000IRm-OH ; Wed, 26 Mar 2008 12:55:00 +0200 MIME-Version: 1.0 To: Jeremy Chadwick From: "Vitaliy Vladimirovich" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.4.1 X-Originating-Ip: [194.0.148.10] In-Reply-To: <20080326100030.GA79074@eos.sc1.parodius.com> X-Browser: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12 Message-Id: Date: Wed, 26 Mar 2008 12:55:00 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re[2]: PF rules for internal interface X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 10:55:03 -0000 --- Original Message --- From: Jeremy Chadwick To: Vitaliy Vladimirovich Date: 26 march, 12:00:30 Subject: Re: PF rules for internal interface > On Wed, Mar 26, 2008 at 10:51:52AM +0200, Vitaliy Vladimirovich wrote: > > Hello! I have problem with restriction rules for my internal interface. > > ... > > Please don't stick stuff like this all on one line. It's impossible to > read. > > > This is my rules for $int_if: > > > > pass out quick on $int_if > > block in on $int_if > > pass in on $int_if from $mynet to any > > > > But in this situation computers from another subnets can ping my > > internal interface. Were is my mistake? Thanks in advance. > > Are these the ONLY RULES you have in your pf.conf? No. This is rules for my int_if only. I have ommited antispoof quick for { lo0 sk0 }. sk0 - this is internal if. > > If not: you must remember that the deny/block in "block in on $int_if" > may get overridden later in the file, depending upon what rules past > that point are. Thi s may be what's happening, later rules do > not specify an interface (thus matching all interfaces). For example, > if your rules are: > > pass out quick on $int_if > block in on $int_if > pass in on $int_if from $mynet to any > pass in from $othernet to any > > In this case, the "block" will not happen when incoming packets from > $othernet arrive on $int_if. > > I've two recommendations: > > 1) Consider using "antispoof", if your concern is someone spoofing > packets across $int_if > > 2) Consider using these rules instead: > > pass in quick on $int_if from $mynet to any > pass out quick on $int_if from $mynet to any > block in quick on $int_if > {...other rules...} OK. Below my new rules within your recommendations: int_if="sk0" mynet="10.0.100.0/16" antispoof quick for { lo0 sk0 } pass in quick on $int_if from $mynet to any pass out quick on $int_if from any to $mynet block in quick on $int_if But it is not work. I can ping my server from another host not in mynet. What's wrong?? From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 10:58:18 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EBF81065670 for ; Wed, 26 Mar 2008 10:58:18 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe1.ukr.net (ffe1.ukr.net [195.214.192.7]) by mx1.freebsd.org (Postfix) with ESMTP id EC1878FC15 for ; Wed, 26 Mar 2008 10:58:17 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from mail by ffe1.ukr.net with local ID 1JeTKi-000IsH-ED ; Wed, 26 Mar 2008 12:58:16 +0200 MIME-Version: 1.0 To: Jeremy Chadwick From: "Vitaliy Vladimirovich" X-Life: is great, enjoy it! X-Mailer: freemail.ukr.net mPOP 3.4.1 X-Originating-Ip: [194.0.148.10] In-Reply-To: <20080326100030.GA79074@eos.sc1.parodius.com> X-Browser: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Message-Id: Date: Wed, 26 Mar 2008 12:58:16 +0200 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 8bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re[2]: PF rules for internal interface X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 10:58:18 -0000 --- Original Message --- From: Jeremy Chadwick To: Vitaliy Vladimirovich Date: 26 march, 12:00:30 Subject: Re: PF rules for internal interface > On Wed, Mar 26, 2008 at 10:51:52AM +0200, Vitaliy Vladimirovich wrote: > > Hello! I have problem with restriction rules for my internal interface. > > ... > > Please don't stick stuff like this all on one line. It's impossible to > read. > > > This is my rules for $int_if: > > > > pass out quick on $int_if > > block in on $int_if > > pass in on $int_if from $mynet to any > > > > But in this situation computers from another subnets can ping my > > internal interface. Were is my mistake? Thanks in advance. > > Are these the ONLY RULES you have in your pf.conf? > > If not: you must remember that the deny/block in "block in on $int_if" > may get overridden later in the file, depending upon what rules past > that point are. This may be what's happening, assuming later rules do > not specify an interface (thus matching all interfaces). For example, > if your rules are: > > pass out quick on $int_if > block in on $int_if > pass in on $int_if from $mynet to any > pass in from $othernet to any > > In this case, the "block" will not happen when incoming packets from > $othernet arrive on $int_if. > > I've two recommendations: > > 1) Consider using "antispoof", if your concern is someone spoofing > packets across $int_if > > 2) Consider using these rules instead: > > pass in quick on $int_if from $mynet to any > pass out quick on $int_if from $mynet to any > block in quick on $int_if > {...other rules...} OK. Below my new rules within your recommendations: int_if="sk0" mynet="10.0.100.0/16" antispoof quick for { lo0 sk0 } pass in quick on $int_if from $mynet to any pass out quick on $int_if from any to $mynet block in quick on $int_if But it is not work. I can ping my server from another host not in mynet. What's wrong?? From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 11:47:10 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A09106564A for ; Wed, 26 Mar 2008 11:47:10 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id A133A8FC2D for ; Wed, 26 Mar 2008 11:47:10 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 7F07E1CC060; Wed, 26 Mar 2008 04:47:10 -0700 (PDT) Date: Wed, 26 Mar 2008 04:47:10 -0700 From: Jeremy Chadwick To: Greg Hennessy Message-ID: <20080326114710.GA81567@eos.sc1.parodius.com> References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <47EA12CA.90305@nviz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47EA12CA.90305@nviz.net> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 11:47:10 -0000 On Wed, Mar 26, 2008 at 09:09:30AM +0000, Greg Hennessy wrote: > Jeremy Chadwick wrote: >> There's been too many cases I've experienced where using "keep state" >> blindly results in state-mismatch increasing at a very fast rate. When >> I implemented this mentality on our production servers, our users >> started pointing out that scp's between machines would randomly get >> severed mis-stream, same with ssh sessions where large TCP windows were >> used (such as doing 'dmesg' over and over): >> >> http://lists.freebsd.org/pipermail/freebsd-pf/2008-January/004050.html > > Which (taking a rough guess) looking at your rule set in the above has very > little to do with 'keep state' and a lot to do with 'modulate state'. IIRC > there is a filed bug which displays all of the aforementioned symptoms when > modulate state meets selective acknowledgement (SACK). I'm sure Max has the > gory detail, it may even be fixed. Which is interesting for two reasons: 1) I never got an explanation in aforementioned thread, thus I had no knowledge of this bug until now -- thank you for telling me! 2) The documentation for FreeBSD pf is minimal. The best we've got is pf.conf(5), /etc/pf.conf (which tells you to read pf.conf(5)), and /usr/share/examples/pf/* which doesn't give you much in the ways of education either. This forces users to turn to the official OpenBSD pf documentation, which strongly advocates the use of "modulate state" with TCP packets: http://www.openbsd.org/faq/pf/filter.html#state With these facts at hand, surely you can see how someone would end up in this situation? And I am not the only one: Doug Sampson's mail is further proof of this. Now that you have educated me in regards to said bug, I will have to go back and try using "keep state" instead. Again, thank you! >> The "use keep state on everything!" attitude seems to stem from people >> reading the OpenBSD pf.conf documentation, which states that as of >> OpenBSD 4.1, "keep state" is implicit on every rule (meaning it's done >> whether you say "keep state" or not). FreeBSD's pf isn't like this. >> > You miss out the most important bit of the new PF 4.1 state keeping > defaults, 'flags S/SA'. I assume "pf 4.1" means "OpenBSD 4.1's pf", or is there some internal pf versioning number? This brings up another situation: there's no version number of pf in FreeBSD that I can find. The OpenBSD docs continually say "as of OpenBSD x.y". This confuses people, who when using pf under FreeBSD, have no knowledge of what version of pf we're using. What version is in RELENG_6? 7? CURRENT? I didn't know until a few minutes ago -- because I went to cvsweb and had to look up the CVS commit messages myself: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c Now that I know, I can make appropriate adjustments. But requiring users to look at CVS commit messages is a bit unrealistic, don't you think? Maybe I should submit a PR asking that the version of pf pulled into FreeBSD be kept in the pf(4), pf.conf(5), and pfctl(8) manpages? What do you suggest? > Our cousins over the road in the OpenBSD neighbourhood have done this > precisely because of the issues caused in prior versions of PF by using > stateless rules and/or establishing TCP state on anything other than the 3 > way handshake. Yep, aware of that -- except that users have no idea as to whether the implicit "keep state" on every rule applies to FreeBSD or not, or if it's "safe" or not, because OpenBSD != FreeBSD. They read the OpenBSD docs and go "errr... so what version is FreeBSD using?" >> It gets more confusing when you consider the fact that even though UDP >> and ICMP are stateless protocols, pf can keep track of their state too, >> though I don't know if FreeBSD pf supports that (OpenBSD pf does). >> > This is not a flame, but if you really do not know that, you really should > not be publicly advocating a position on the basis of incomplete > information. And "incomplete information" is induced by what I described in my above paragraphs. Please don't be so harsh under the circumstances -- I was going off of all the available information I had at the time. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 13:33:24 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CBBF4106564A; Wed, 26 Mar 2008 13:33:24 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) Received: from ironport2-out.teksavvy.com (ironport2-out.teksavvy.com [206.248.154.182]) by mx1.freebsd.org (Postfix) with ESMTP id 84A728FC12; Wed, 26 Mar 2008 13:33:24 +0000 (UTC) (envelope-from kkutzko@teksavvy.com) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwEAKjt6UdMCqa7/2dsb2JhbACBWolQn1sE X-IronPort-AV: E=Sophos;i="4.25,558,1199682000"; d="scan'208";a="16851271" Received: from mail.pppoe.ca (HELO mail.teksavvy.com) ([65.39.192.132]) by ironport2-out.teksavvy.com with ESMTP; 26 Mar 2008 09:32:21 -0400 Received: from kevin ([76.10.166.187]) by mail.teksavvy.com (Internet Mail Server v1.0) with ASMTP id GQG41821; Wed, 26 Mar 2008 09:32:21 -0400 From: "Kevin K" To: "'Vitaliy Vladimirovich'" , "'Jeremy Chadwick'" References: <20080326100030.GA79074@eos.sc1.parodius.com> In-Reply-To: Date: Wed, 26 Mar 2008 09:31:57 -0400 Message-ID: <000801c88f45$c3d76dd0$4b864970$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AciPMFqGbbYR4JUDSbewhov64jmXCgAFVNqA Content-Language: en-us Cc: freebsd-pf@freebsd.org Subject: RE: Re[2]: PF rules for internal interface X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 13:33:24 -0000 > -----Original Message----- > From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd- > pf@freebsd.org] On Behalf Of Vitaliy Vladimirovich > Sent: Wednesday, March 26, 2008 6:58 AM > To: Jeremy Chadwick > Cc: freebsd-pf@freebsd.org > Subject: Re[2]: PF rules for internal interface > > --- Original Message --- From: Jeremy Chadwick To: Vitaliy > Vladimirovich Date: 26 march, 12:00:30 Subject: Re: PF rules for > internal interface > On Wed, Mar 26, 2008 at 10:51:52AM +0200, Vitaliy > Vladimirovich wrote: > > Hello! I have problem with restriction rules > for my internal interface. > > ... > > Please don't stick stuff like > this all on one line. It's impossible to > read. > > > This is my rules > for $int_if: > > > > pass out quick on $int_if > > block in on $int_if > > > pass in on $int_if from $mynet to any > > > > But in this situation > computers from another subnets can ping my > > internal interface. Were > is my mistake? Thanks in advance. > > Are these the ONLY RULES you have > in your pf.conf? > > If not: you must remember that the deny/block in > "block in on $int_if" > may get overridden later in the file, depending > upon what rules past > that point are. This may be what's happening, > assuming later rules do > not specify an interface (thus matching all > interfaces). For > example, > if your rules are: > > pass out quick on $int_if > block in > on $int_if > pass in on $int_if from $mynet to any > pass in from > $othernet to any > > In this case, the "block" will not happen when > incoming packets from > $othernet arrive on $int_if. > > I've two > recommendations: > > 1) Consider using "antispoof", if your concern is > someone spoofing > packets across $int_if > > 2) Consider using these > rules instead: > > pass in quick on $int_if from $mynet to any > pass > out quick on $int_if from $mynet to any > block in quick on $int_if > > {...other rules...} OK. Below my new rules within your recommendations: > int_if="sk0" mynet="10.0.100.0/16" antispoof quick for { lo0 sk0 } pass > in quick on $int_if from $mynet to any pass out quick on $int_if from > any to $mynet block in quick on $int_if But it is not work. I can ping > my server from another host not in mynet. What's wrong?? Something is wrong with your formatting in your emails. Newlines are non-existant and your email is impossible to read. Please re-format your emails. From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 15:02:06 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 839651065686 for ; Wed, 26 Mar 2008 15:02:06 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.186]) by mx1.freebsd.org (Postfix) with ESMTP id 07AD58FC26 for ; Wed, 26 Mar 2008 15:02:05 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: by gv-out-0910.google.com with SMTP id n40so836659gve.39 for ; Wed, 26 Mar 2008 08:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=9cyofqGerH3MCZNEmU1Fp6TpYjxSHtFUloY0+zgfcRs=; b=rUP6jYEKKQPUtzCbJ8WdfPShPWlgWxn5vQHLR/HZSCujMmwC7aWaCde+ynQIqjGYmnVDBQJCbxG6683Ddlx/1CrZW9wLfHTdUrl0hDHgLUSalj98BmFCqYFUgvdDwHODVEuxK9GhHmwOIIEYHoTp8ZLcB+P9ZpTVN08rWDw98fs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=RJbLMdxt5w/gJPKE2TWEv28ZGuEr0BhnHdqgbk6EyFN6y3UM9myI1YBR/NE8rf/HM2mmiX3OMNKdX6T/24GhHzHmUsAcAF5nOppt2A2P41TkJUs3qQ5i+xQrTpzgd3xSwI5/UpwbAq2RqD5et/2wq1LgLjTVH2XNY2k313wk6pY= Received: by 10.150.158.8 with SMTP id g8mr91063ybe.25.1206543722379; Wed, 26 Mar 2008 08:02:02 -0700 (PDT) Received: by 10.150.228.11 with HTTP; Wed, 26 Mar 2008 08:02:02 -0700 (PDT) Message-ID: <866fa9520803260802v3686b24dq1ee7aa1cc4b35f75@mail.gmail.com> Date: Wed, 26 Mar 2008 16:02:02 +0100 From: "Dalibor Gudzic" To: "Jeremy Chadwick" In-Reply-To: <20080326025316.GA68607@eos.sc1.parodius.com> MIME-Version: 1.0 References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Greg Hennessy , freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 15:02:06 -0000 On Wed, Mar 26, 2008 at 3:53 AM, Jeremy Chadwick wrote: > I'll try to explain it with a very small ruleset and a couple scenarios: > > $ext_if = network interface that's got a public IP address > 4.4.4.4 = our public IP address > > pass out quick all flags S/SA keep state > pass out quick all > block in log all > pass in quick on $ext_if inet proto tcp from any to 4.4.4.4 port ssh > > Two scenarios: > > 1) When an incoming TCP packet from to 4.4.4.4 on port 22 is seen, > that incoming packet is permitted (rule #4). Outbound responses from > 4.4.4.4 to are also > permitted (rule #1). Note the "keep state". > > > Correct me if I'm wrong, but I think the outbound packet will be matched against the #2 rule, as the rule #1 has "flags S/SA" and will not match the packet since the packet would have "ACK" flag set. Thus, the state will not be created in state table. That is if the rule #4 doesn't include "keep state" (which is default in RELENG_7). From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 15:07:04 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2A83D106566B for ; Wed, 26 Mar 2008 15:07:04 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.184]) by mx1.freebsd.org (Postfix) with ESMTP id A4D1E8FC16 for ; Wed, 26 Mar 2008 15:07:03 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: by gv-out-0910.google.com with SMTP id n40so838120gve.39 for ; Wed, 26 Mar 2008 08:07:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=LE/mDDPRmSCg7HbOqyK8yeZXI3ETh371cQbMQPQZSJM=; b=EZz4ZD0aRlO5L7J/ZEvdsZ3WyP041dWMbHhbbqX5unqdFEzyA8slb+b1UKuF9fvsBKb95dHG+J0P0aNeCzpII/+op++Fx1+br9yuXAmEEKmSyqUavWw3IulUZSTRfndv7qr0Y7zXOkKsSsvRuDCdnQq1DIPts8legOYD+aG0uJ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aTgrtT26NWezLKZvyYI/exyD9obZ6JzU1W/2MatQYlQ2dPwxMHE4fob5gK1++V7tDZbTdNUlhc6TfMz3IzX0Xs7ZxgGZB+BlQZuXD2yUfZ0eucrctZFu393VLN9DXjjLqRg+2G9nkY68wF22/fqXc0Ay7IgKo3iPZkbXofL2pro= Received: by 10.151.38.12 with SMTP id q12mr47954ybj.174.1206542462594; Wed, 26 Mar 2008 07:41:02 -0700 (PDT) Received: by 10.150.228.11 with HTTP; Wed, 26 Mar 2008 07:41:02 -0700 (PDT) Message-ID: <866fa9520803260741rdf08419w178b0050315718b3@mail.gmail.com> Date: Wed, 26 Mar 2008 15:41:02 +0100 From: "Dalibor Gudzic" To: "Jeremy Chadwick" In-Reply-To: <20080326114710.GA81567@eos.sc1.parodius.com> MIME-Version: 1.0 References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <47EA12CA.90305@nviz.net> <20080326114710.GA81567@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Greg Hennessy , freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 15:07:04 -0000 On Wed, Mar 26, 2008 at 12:47 PM, Jeremy Chadwick wrote: > This brings up another situation: there's no version number of pf in > FreeBSD that I can find. The OpenBSD docs continually say "as of > OpenBSD x.y". This confuses people, who when using pf under FreeBSD, > have no knowledge of what version of pf we're using. What version is in > RELENG_6? 7? CURRENT? I didn't know until a few minutes ago -- > because I went to cvsweb and had to look up the CVS commit messages > myself: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c > > Now that I know, I can make appropriate adjustments. But requiring > users to look at CVS commit messages is a bit unrealistic, don't you > think? Maybe I should submit a PR asking that the version of pf pulled > into FreeBSD be kept in the pf(4), pf.conf(5), and pfctl(8) manpages? > What do you suggest? > > > Our cousins over the road in the OpenBSD neighbourhood have done this > > precisely because of the issues caused in prior versions of PF by using > > stateless rules and/or establishing TCP state on anything other than the > 3 > > way handshake. > > Yep, aware of that -- except that users have no idea as to whether the > implicit "keep state" on every rule applies to FreeBSD or not, or if > it's "safe" or not, because OpenBSD != FreeBSD. They read the OpenBSD > docs and go "errr... so what version is FreeBSD using?" > From: http://pf4freebsd.love2party.net/ Status The port is part of the base system of FreeBSD 5.X as of March, 8th 2004. - In RELENG_5 - pf is at OpenBSD 3.5 - In RELENG_6 - pf is at OpenBSD 3.7 - In RELENG_7 - pf is at OpenBSD 4.1 - In HEAD - pf is at OpenBSD 4.1 - at this time. - It has been said several times on the list as well. :) From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 15:42:17 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D5A071065673 for ; Wed, 26 Mar 2008 15:42:17 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id BF1828FC24 for ; Wed, 26 Mar 2008 15:42:17 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id 99C211CC060; Wed, 26 Mar 2008 08:42:17 -0700 (PDT) Date: Wed, 26 Mar 2008 08:42:17 -0700 From: Jeremy Chadwick To: Dalibor Gudzic Message-ID: <20080326154217.GA87250@eos.sc1.parodius.com> References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <866fa9520803260802v3686b24dq1ee7aa1cc4b35f75@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <866fa9520803260802v3686b24dq1ee7aa1cc4b35f75@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Greg Hennessy , freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 15:42:18 -0000 On Wed, Mar 26, 2008 at 04:02:02PM +0100, Dalibor Gudzic wrote: > On Wed, Mar 26, 2008 at 3:53 AM, Jeremy Chadwick wrote: > > I'll try to explain it with a very small ruleset and a couple scenarios: > > > > $ext_if = network interface that's got a public IP address > > 4.4.4.4 = our public IP address > > > > pass out quick all flags S/SA keep state > > pass out quick all > > block in log all > > pass in quick on $ext_if inet proto tcp from any to 4.4.4.4 port ssh > > > > Two scenarios: > > > > 1) When an incoming TCP packet from to 4.4.4.4 on port 22 is seen, > > that incoming packet is permitted (rule #4). Outbound responses from > > 4.4.4.4 to are also > > permitted (rule #1). Note the "keep state". > > > Correct me if I'm wrong, but I think the outbound packet will be matched > against the #2 rule, as the rule #1 has "flags S/SA" and will not match the > packet since the packet would have "ACK" flag set. Thus, the state will not > be created in state table. The pf.conf(5) manpage for STATEFUL INSPECTION has this to say: If a packet matches a pass ... keep state rule, the filter creates a state for this connection and automatically lets pass all subsequent packets of that connection. I read this as: "if a packet matches a pass ... keep state rule, pf begins permitting all I/O for that now-state-tracked session". One of the entire points of state tracking is that it lets pf avoid having to reiterate the rule table for every packet. This is how I understand it, at least on RELENG_6 with the above rules: pfbox (4.4.4.4) tries to connect to some host on the Internet via TCP (ignoring port numbers for now): pfbox -> somehost = TCP flags SYN set, ACK not set = PASS: matches rule #1 = pf creates state-table entry for tracking somehost -> pfbox = TCP flags: SYN set, ACK set = PASS: has state-table entry pfbox -> somehost = TCP flags: SYN not set, ACK set = PASS: has state-table entry Things in this case should work fine, relying on the state-table entry for permitted I/O. Now the opposite, where some host on the Internet attempts to connect to 4.4.4.4 on port 22: somehost -> pfbox = TCP flags SYN set, ACK not set = PASS: matches rule #4 pfbox -> somehost = TCP flags: SYN set, ACK set = PASS: matches rule #2 somehost -> pfbox = TCP flags SYN not set, ACK set = PASS: matches rule #4 A state-table entry won't be created for this one, since rule #1 specifies "flags S/SA" (won't match SYN+ACK both set). If one was to add "keep state" to rule #4 (RELENG_6), or use RELENG_7 (where "keep state" is implied) and some host on the Internet attempts to connect to 4.4.4.4 on port 22, we should see: somehost -> pfbox = TCP flags SYN set, ACK not set = PASS: matches rule #4 = pf creates state-table entry for tracking pfbox -> somehost = TCP flags: SYN set, ACK set = PASS: has state-table entry somehost -> pfbox = TCP flags SYN not set, ACK set = PASS: has state-table entry Do we agree? -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 15:51:26 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D7159106564A for ; Wed, 26 Mar 2008 15:51:26 +0000 (UTC) (envelope-from jdc@parodius.com) Received: from mx01.sc1.parodius.com (mx01.sc1.parodius.com [72.20.106.3]) by mx1.freebsd.org (Postfix) with ESMTP id CB3828FC17 for ; Wed, 26 Mar 2008 15:51:26 +0000 (UTC) (envelope-from jdc@parodius.com) Received: by mx01.sc1.parodius.com (Postfix, from userid 1000) id B1F051CC060; Wed, 26 Mar 2008 08:51:26 -0700 (PDT) Date: Wed, 26 Mar 2008 08:51:26 -0700 From: Jeremy Chadwick To: Dalibor Gudzic Message-ID: <20080326155126.GA87959@eos.sc1.parodius.com> References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <47EA12CA.90305@nviz.net> <20080326114710.GA81567@eos.sc1.parodius.com> <866fa9520803260741rdf08419w178b0050315718b3@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <866fa9520803260741rdf08419w178b0050315718b3@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) Cc: Greg Hennessy , freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 15:51:27 -0000 On Wed, Mar 26, 2008 at 03:41:02PM +0100, Dalibor Gudzic wrote: > From: http://pf4freebsd.love2party.net/ > Status > > The port is part of the base system of FreeBSD 5.X as of March, 8th 2004. > > - In RELENG_5 - pf is at OpenBSD 3.5 > - In RELENG_6 - pf is at OpenBSD 3.7 > - In RELENG_7 - pf is at OpenBSD 4.1 > - In HEAD - pf is at OpenBSD 4.1 - at this time. That's the official home page for FreeBSD pf(4)? Wow, I had no idea. I'd have expected it to be on freebsd.org somewhere, especially since it's such a heavily-relied upon piece of FreeBSD. Thank you for pointing me to this! Regardless, I'll submit a PR to have the version number mentioned in some pf-related manpages, since users are going to look there first, logically. > It has been said several times on the list as well. :) Users aren't going to check a mailing list every time they want to know what version of a program they're using. :-) -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 16:17:37 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E419C1065670 for ; Wed, 26 Mar 2008 16:17:37 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from svarun.infrax.si (syssvarun.infrax.si [89.212.81.4]) by mx1.freebsd.org (Postfix) with ESMTP id 9A0B98FC21 for ; Wed, 26 Mar 2008 16:17:37 +0000 (UTC) (envelope-from nejc@skoberne.net) Received: from localhost (sysSvarun.infrax.si [89.212.81.4]) by svarun.infrax.si (Postfix) with ESMTP id A131324AA5A for ; Wed, 26 Mar 2008 17:02:10 +0100 (CET) Received: from svarun.infrax.si ([89.212.81.4]) by localhost (svarun.infrax.si [89.212.81.4]) (amavisd-maia, port 10024) with ESMTP id 36766-02 for ; Wed, 26 Mar 2008 17:02:07 +0100 (CET) Received: from [192.168.15.2] (lk.84.20.249.154.dc.cable.static.lj-kabel.net [84.20.249.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: nejko@infrax.si) by svarun.infrax.si (Postfix) with ESMTP id 37B4224AA36 for ; Wed, 26 Mar 2008 17:02:07 +0100 (CET) Message-ID: <47EA737B.8060009@skoberne.net> Date: Wed, 26 Mar 2008 17:02:03 +0100 From: =?ISO-8859-2?Q?Nejc_=A9koberne?= User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard Subject: pf and SMP and busy wires X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 16:17:38 -0000 Hello, I like pf very much and I was planning to use it as a "central" firewall at one of the customers like this: subnet_3 | | subnet_1 ---------- PF_firewall --------------- subnet_2 | | internet_gw However, since these are subnets with many computers, these would be gigabit connections. But, I am afraid that this machine would not be able to process data with gigabit speeds. So my questions are: 1. Are there any real-life performance evaluations with PF as firewall(s) (doing also NAT if possible)? 2. How efficiently does PF use SMP (FreeBSD 7.0)? 3. How much would I profit if I had a server with two Dual-Core Intel processors? This means 4 cores, right? I guess this should be able to process data with gigabit speed in the situation above? 4. How would PF scale if there were 5 or more such subnets instead of 3 (with gigabit speeds)? 5. Are there any PF vs Cisco|Juniper|3Com layer3 switches comparisons? 6. What role does the network cards play when looking at performance? Are there network cards which do more work by themselves to let CPU to do other things? Thanks. Nejc From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 16:20:45 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 88BD51065676 for ; Wed, 26 Mar 2008 16:20:45 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by mx1.freebsd.org (Postfix) with ESMTP id 0E31B8FC19 for ; Wed, 26 Mar 2008 16:20:44 +0000 (UTC) (envelope-from dalibor.gudzic@gmail.com) Received: by ti-out-0910.google.com with SMTP id j2so1299957tid.3 for ; Wed, 26 Mar 2008 09:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=NrcS8Ge2SY97Cgib2iJLiRr/yU00f1/al4ZxGBInjyE=; b=Uw+znPlOypt7tMpa+LpEcZX8Nyg+SSZj/s32H9ubzcifjGoXYPLH+kTrRXxug+8n0y+MYfeNdT0wCzC1cZfs8YBV8elrrJcyojUHn1bMP8kejcj+TKzg+GSWCh7Ji9O2L1uYPTNiviKijoxL/cuVfqYKEkdHRHfuMD7CdumW8fA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=gEdXba4wBEJ8p3Z6q5oE0gH99mbcomd+jIM/VE+Kf6qZ44m8yy+cdSKQd/+CefvvA0bPoZ4Bv4BxieBJo3/r1MzA0+l7iYZY1v+bcm5Sbrta2JSxVDvMdGTpHc0/rpVY12Cts+z++l4MPRDFF9XXp0HHZ7IqXK8znKXA0ksDOAk= Received: by 10.151.103.11 with SMTP id f11mr110821ybm.194.1206548441736; Wed, 26 Mar 2008 09:20:41 -0700 (PDT) Received: by 10.150.228.11 with HTTP; Wed, 26 Mar 2008 09:20:41 -0700 (PDT) Message-ID: <866fa9520803260920s61c09e54v398be6cf0312a90b@mail.gmail.com> Date: Wed, 26 Mar 2008 17:20:41 +0100 From: "Dalibor Gudzic" To: "Jeremy Chadwick" In-Reply-To: <20080326154217.GA87250@eos.sc1.parodius.com> MIME-Version: 1.0 References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <866fa9520803260802v3686b24dq1ee7aa1cc4b35f75@mail.gmail.com> <20080326154217.GA87250@eos.sc1.parodius.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-pf@freebsd.org Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 16:20:45 -0000 On Wed, Mar 26, 2008 at 4:42 PM, Jeremy Chadwick wrote: > > Now the opposite, where some host on the Internet attempts to connect to > 4.4.4.4 on port 22: > > somehost -> pfbox = TCP flags SYN set, ACK not set > = PASS: matches rule #4 > pfbox -> somehost = TCP flags: SYN set, ACK set > = PASS: matches rule #2 > somehost -> pfbox = TCP flags SYN not set, ACK set > = PASS: matches rule #4 > > A state-table entry won't be created for this one, since rule #1 > specifies "flags S/SA" (won't match SYN+ACK both set). > > If one was to add "keep state" to rule #4 (RELENG_6), or use RELENG_7 > (where "keep state" is implied) and some host on the Internet attempts > to connect to 4.4.4.4 on port 22, we should see: > > somehost -> pfbox = TCP flags SYN set, ACK not set > = PASS: matches rule #4 > = pf creates state-table entry for tracking > pfbox -> somehost = TCP flags: SYN set, ACK set > = PASS: has state-table entry > somehost -> pfbox = TCP flags SYN not set, ACK set > = PASS: has state-table entry > > Do we agree? > > -- > | Jeremy Chadwick jdc at parodius.com | > | Parodius Networking http://www.parodius.com/ | > | UNIX Systems Administrator Mountain View, CA, USA | > | Making life hard for others since 1977. PGP: 4BD6C0CB | > > Seems to be OK now. Sorry, I should have made it more clearer in the previous message; I meant, and should've said, "SYN-ACK" i.e. the response packet from host. From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 16:54:34 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76D2B1065678 for ; Wed, 26 Mar 2008 16:54:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.174]) by mx1.freebsd.org (Postfix) with ESMTP id 1450A8FC1A for ; Wed, 26 Mar 2008 16:54:34 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-066-046-062.pools.arcor-ip.net [88.66.46.62]) by mrelayeu.kundenserver.de (node=mrelayeu7) with ESMTP (Nemesis) id 0ML2xA-1JeYtU30d0-0000Wt; Wed, 26 Mar 2008 17:54:33 +0100 Received: (qmail 49511 invoked from network); 26 Mar 2008 16:53:42 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 26 Mar 2008 16:53:42 -0000 From: Max Laier Organization: FreeBSD To: freebsd-pf@freebsd.org Date: Wed, 26 Mar 2008 17:52:50 +0100 User-Agent: KMail/1.9.9 References: <47EA737B.8060009@skoberne.net> In-Reply-To: <47EA737B.8060009@skoberne.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200803261752.50776.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/F3LFukBMr/03XrQOoxRDIAfRmGVrr82/FGpa fY7yrlsj/NRHC77b3qJWG23qwjCVaYGI5CK53TC5OM739jCOMh CPflULbN3u5PXi1SWj+7g== Cc: Subject: Re: pf and SMP and busy wires X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 16:54:34 -0000 On Wednesday 26 March 2008 17:02:03 Nejc =A9koberne wrote: > I like pf very much and I was planning to use it as a "central" > firewall at one of the customers like this: > > subnet_3 > > > subnet_1 ---------- PF_firewall --------------- subnet_2 > > > internet_gw > > However, since these are subnets with many computers, these would be > gigabit connections. But, I am afraid that this machine would not be > able to process data with gigabit speeds. So my questions are: > > 1. Are there any real-life performance evaluations with PF as > firewall(s) (doing also NAT if possible)? Yes there are, but I don't have a concrete example at hand. NAT isn't all= =20 that expensive with pf. In general you can hope for up to 750kpps=20 forwarding performance. If that's enough in your situation depends on=20 the kind of traffic you are looking at. > 2. How efficiently does PF use SMP (FreeBSD 7.0)? Not at all. I have plans to change that, though: http://pf4freebsd.love2party.net/pflock/ N.B. this is a long shot and something for the 8.0 time frame. > 3. How much would I profit if I had a server with two Dual-Core Intel > processors? This means 4 cores, right? I guess this should be able to > process data with gigabit speed in the situation above? While pf is a serialization point, the rest of the processing=20 (ether_input -> ip_input -> forward -> ip_output -> ether_output) and the=20 internet servicing can run in parallel. If you just do forwarding the=20 natural limit for parallelization is the number of interfaces, although=20 you won't likely achieve that kind of parallelism more cores certainly=20 help. If you add other processing - e.g. VPN endpoints - it's even=20 better to have "spare" cores. > 4. How would PF scale if there were 5 or more such subnets instead of 3 > (with gigabit speeds)? The limiting factor for any firewall/packet forwarder are packets per=20 second, not throughput (so much). pf on FreeBSD currently provides=20 ~750kpps (1M has been reported with careful tuning). This is roughly=20 1Gbps with 1500 Byte packets. > 5. Are there any PF vs Cisco|Juniper|3Com layer3 switches comparisons? Not that I'm aware of, but pf on commodity hardware will always have an=20 edge in the cost/performance column. You have to pay quite a bit to=20 obtain a hardware solution that can really *firewall* 750kpps and this=20 will usually fall short of pf in terms of additional features. Note for example, the possibility to build a redundant firewall with ARP=20 load balancing using CARP and pfsync. > 6. What role does the network cards play when looking at performance? > Are there network cards which do more work by themselves to let CPU to > do other things? YES! Buying good network cards is essential! The general consensus seems= =20 to be to stick with Intel server cards. In any case stay away from the=20 low end on-board stuff. The bus interface is also very important! The=20 plain old PCI bus has a limit of ~1Gbps itself, so go for PCI-X or better=20 yet PCIe. Buy a motherboard that offers more than one bus. In the end it very much depends on your traffic patterns and security if=20 pf is the right choice for you. If you should really have steady 1Gbps=20 streams between your subnets it very likely is not. But then again,=20 there are very few alternatives to choose from. If you are only looking=20 at sporadic inter-subnet communication and reliable, secure internet=20 access for all of them (where usually the uplink is the limiting=20 factor) - then FreeBSD and pf can certainly provide what you need. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News From owner-freebsd-pf@FreeBSD.ORG Wed Mar 26 18:50:11 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4AAEE1065674 for ; Wed, 26 Mar 2008 18:50:11 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from mailfilter.dawnsign.com (cetus.dawnsign.com [216.70.250.4]) by mx1.freebsd.org (Postfix) with ESMTP id E649A8FC15 for ; Wed, 26 Mar 2008 18:50:10 +0000 (UTC) (envelope-from dougs@dawnsign.com) Received: from cetus.dawnsign.com (cetus.dawnsign.com [192.168.1.5]) by mailfilter.dawnsign.com (Postfix) with ESMTP id 951C89582B; Wed, 26 Mar 2008 11:50:10 -0700 (PDT) Received: by cetus.dawnsign.com with Internet Mail Service (5.5.2657.72) id ; Wed, 26 Mar 2008 11:50:10 -0700 Message-ID: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0293@cetus.dawnsign.com> From: Doug Sampson To: 'Jeremy Chadwick' Date: Wed, 26 Mar 2008 11:50:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain Cc: freebsd-pf@freebsd.org Subject: RE: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Wed, 26 Mar 2008 18:50:11 -0000 > This isn't a reply to you (Doug), but -- do not blindly use > "keep state" > everywhere! > > There's been too many cases I've experienced where using "keep state" > blindly results in state-mismatch increasing at a very fast > rate. When > I implemented this mentality on our production servers, our users > started pointing out that scp's between machines would randomly get > severed mis-stream, same with ssh sessions where large TCP > windows were > used (such as doing 'dmesg' over and over): > > http://lists.freebsd.org/pipermail/freebsd-pf/2008-January/004050.html > > The "use keep state on everything!" attitude seems to stem from people > reading the OpenBSD pf.conf documentation, which states that as of > OpenBSD 4.1, "keep state" is implicit on every rule (meaning it's done > whether you say "keep state" or not). FreeBSD's pf isn't like this. > > > I hate to bug you guys but I ain't a pf guru like you guys. I am not > > understanding the significance of the "keep state" and the > "flags S/SA > > synproxy state" qualifiers. I have been copying some rules > from articles > > here and there. Thus these rules are not unified in the > sense that these are > > designed from the beginning to work harmoniously. > > The easiest way to explain "keep state" is: with rules that use "keep > state", every time a packet matching that rule is > encountered, pf keeps > track of the current TCP state and permits/denies based on the TCP > state, rather than having to reiterate through all of your > rulesets over > and over. > > I'll try to explain it with a very small ruleset and a couple > scenarios: > > $ext_if = network interface that's got a public IP address > 4.4.4.4 = our public IP address > > pass out quick all flags S/SA keep state > pass out quick all > block in log all > pass in quick on $ext_if inet proto tcp from any to 4.4.4.4 port ssh > > Two scenarios: > > 1) When an incoming TCP packet from to 4.4.4.4 on port > 22 is seen, > that incoming packet is permitted (rule #4). Outbound responses from > 4.4.4.4 to are also > permitted (rule #1). Note the "keep state". > > pf will begin keep tracking of the TCP state from that point forward, > which means it doesn't have to reiterate through your rules > to continue > passing inbound/outbound traffic for that TCP session. > > 2) An outbound TCP packet from 4.4.4.4 port 50345 to 12.90.124.50 port > 25 is attempted. That packet is permitted (rule #1), and the TCP > state is tracked in pf. > > The *response* packets from 12.90.124.50 port 25 to 4.4.4.4 port 50345 > are also permitted -- yet you see no rule for such, do you? This is > because pf's state tracking ("keep state") is doing the pass/deny > for you. > > > It gets more confusing when you consider the fact that even though UDP > and ICMP are stateless protocols, pf can keep track of their > state too, > though I don't know if FreeBSD pf supports that (OpenBSD pf does). > > Now, about flags S/SA -- you need to understand how TCP works > to really > understand what purpose this serves. > > "flags" causes pf to look at only certain TCP flags (bits), > and check to > see which of those bits are set or clear. You can check against FIN, > SYn, RST, PSH, ACK, URG, ECE, and CWR. That criteria must be matched > for the rule in question to be used. The official docs are > here, which > also describes synproxy (which I haven't used): > > http://www.openbsd.org/faq/pf/filter.html#tcpflags > > Let's take rule #1 in the above ruleset: > > pass out quick all flags S/SA keep state > > This means pass any outbound traffic (from any IP address of > ours) with > the TCP flag SYN set (but only look at the SYN and ACK flags > when doing > that comparison) -- and keep track of TCP state. > > This explanation should also provide you an answer to what rule #2 is > for -- permitting outbound packets which DO NOT match that criteria. > You might be wondering "so why not nuke rule #1 and just use #2?", to > which my reply would be, "see Scenario #2 -- incoming packets from > 12.90.124.50 port 25 to 4.4.4.4 port 50345 would then get blocked!" > > > Does this make more sense to you? :-) I've picked up a few things here. Thanks, Jeremy. I'm going to comb over my rule set and see where I can go from here on. Oh, sheesh. I just now noticed a state where an outgoing packet to port 9103 went to an opendns server! I poked around and realized that this machine is using opendns as an external name server and thus didn't know what to make of a packet destined for a fully qualified domain name for the internal server. I've since then modified the /etc/hosts file and now I'm able to complete the Bacula back up job. Egads! ~Doug From owner-freebsd-pf@FreeBSD.ORG Fri Mar 28 17:09:33 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 323681065677 for ; Fri, 28 Mar 2008 17:09:33 +0000 (UTC) (envelope-from fox@verio.net) Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACDB8FC19 for ; Fri, 28 Mar 2008 17:09:32 +0000 (UTC) (envelope-from fox@verio.net) Received: from [129.250.36.63] (helo=dfw-mmp3.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 1JfHgQ-0000hT-4u for freebsd-pf@freebsd.org; Fri, 28 Mar 2008 16:44:02 +0000 Received: from [129.250.40.241] (helo=limbo.int.dllstx01.us.it.verio.net) by dfw-mmp3.email.verio.net with esmtp id 1JfHgP-0001V0-W5 for freebsd-pf@freebsd.org; Fri, 28 Mar 2008 16:44:02 +0000 Received: by limbo.int.dllstx01.us.it.verio.net (Postfix, from userid 1000) id CDD9E8E296; Fri, 28 Mar 2008 11:44:01 -0500 (CDT) Date: Fri, 28 Mar 2008 11:44:01 -0500 From: David DeSimone To: freebsd-pf@freebsd.org Message-ID: <20080328164401.GE29001@verio.net> Mail-Followup-To: freebsd-pf@freebsd.org References: <9DE6EC5B5CF8C84281AE3D7454376A0D6D0290@cetus.dawnsign.com> <20080326025316.GA68607@eos.sc1.parodius.com> <47EA12CA.90305@nviz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <47EA12CA.90305@nviz.net> Precedence: bulk User-Agent: Mutt/1.5.9i Subject: Re: Bacula File/Storage Connection Woes using PF X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 28 Mar 2008 17:09:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Hennessy wrote: > > Jeremy Chadwick wrote: > > Do not blindly use "keep state" everywhere! > > Hard cases make for bad laws. I have got to point out the error in > the above statement. To expand upon this (for further education), "keep state" is beneficial for two reasons: 1. A state table lookup is more efficient than parsing the rule base for every packet. 2. It is MORE SECURE to use state tables to pass packets, because PF watches the state very closely, and permits only the specific sequence numbers that should be active on the connection. Of course, if that state tracking is buggy, this leads to the failures referenced here: > > There's been too many cases I've experienced where using "keep > > state" blindly results in state-mismatch increasing at a very fast > > rate. When I implemented this mentality on our production servers, > > our users started pointing out that scp's between machines would > > randomly get severed mis-stream, same with ssh sessions where large > > TCP windows were used (such as doing 'dmesg' over and over): What's being described here is a failure of PF to track state correctly. If a user types a command that results in a large amount of output, like "dmesg" or "ls -lR /", the connection will stall because PF isn't permitting the entire window to advance. Greg makes reference to the "modulate state" bug, which I was not aware of, but it is also important to be aware of this: > You miss out the most important bit of the new PF 4.1 state keeping > defaults, 'flags S/SA'. > Our cousins over the road in the OpenBSD neighbourhood have done this > precisely because of the issues caused in prior versions of PF by > using stateless rules and/or establishing TCP state on anything other > than the 3 way handshake. The reason that it's so important to ONLY create state on the initial handshake is that crucial information (namely window-scaling factors) are exchanged ONLY at this time. If PF were to boot up and see a connection only in the middle, it would assume "unscaled" window factors in use, and thus would only permit a very small range of the allowed window, causing severe performance degradation. Establishing state on the initial SYN avoids this problem entirely. > > It gets more confusing when you consider the fact that even though > > UDP and ICMP are stateless protocols, pf can keep track of their > > state too, though I don't know if FreeBSD pf supports that (OpenBSD > > pf does). Of course PF supports this, but "state" on a "stateless" connection is maintained purely with timers. When the timers expire, the state expires. - -- David DeSimone == Network Admin == fox@verio.net "This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, dis- tribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. Verio, Inc. makes no warranty that this email is error or virus free. Thank you." --Lawyer Bot 6000 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFH7SBRFSrKRjX5eCoRAvE0AJ4vxqFWA2lhSajoDHc3jX7R/qvrQQCgo67w oOpUudaxHqtN70S6oURstns= =IQZw -----END PGP SIGNATURE----- From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 00:30:03 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 678051065670 for ; Sat, 29 Mar 2008 00:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 582298FC22 for ; Sat, 29 Mar 2008 00:30:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T0U33E043569 for ; Sat, 29 Mar 2008 00:30:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T0U39B043560; Sat, 29 Mar 2008 00:30:03 GMT (envelope-from gnats) Date: Sat, 29 Mar 2008 00:30:03 GMT Message-Id: <200803290030.m2T0U39B043560@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: dfilter@FreeBSD.org (dfilter service) Cc: Subject: Re: kern/106400: commit references a PR X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service 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: Sat, 29 Mar 2008 00:30:03 -0000 The following reply was made to PR kern/106400; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/106400: commit references a PR Date: Sat, 29 Mar 2008 00:24:46 +0000 (UTC) mlaier 2008-03-29 00:24:36 UTC FreeBSD src repository Modified files: contrib/pf/pfctl pfctl_altq.c pfctl_qstats.c sys/contrib/pf/net pf_if.c pf_ioctl.c pfvar.h Log: Make ALTQ cope with disappearing interfaces (particularly common with mpd and netgraph in gernal). This also allows to add queues for an interface that is not yet existing (you have to provide the bandwidth for the interface, however). PR: kern/106400, kern/117827 MFC after: 2 weeks Revision Changes Path 1.10 +12 -0 src/contrib/pf/pfctl/pfctl_altq.c 1.7 +26 -0 src/contrib/pf/pfctl/pfctl_qstats.c 1.15 +6 -0 src/sys/contrib/pf/net/pf_if.c 1.31 +116 -2 src/sys/contrib/pf/net/pf_ioctl.c 1.17 +7 -0 src/sys/contrib/pf/net/pfvar.h _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 00:30:05 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F32106566C for ; Sat, 29 Mar 2008 00:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B84A88FC13 for ; Sat, 29 Mar 2008 00:30:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T0U52Q043820 for ; Sat, 29 Mar 2008 00:30:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T0U5V5043817; Sat, 29 Mar 2008 00:30:05 GMT (envelope-from gnats) Date: Sat, 29 Mar 2008 00:30:05 GMT Message-Id: <200803290030.m2T0U5V5043817@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: dfilter@FreeBSD.org (dfilter service) Cc: Subject: Re: kern/117827: commit references a PR X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service 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: Sat, 29 Mar 2008 00:30:05 -0000 The following reply was made to PR kern/117827; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/117827: commit references a PR Date: Sat, 29 Mar 2008 00:24:47 +0000 (UTC) mlaier 2008-03-29 00:24:36 UTC FreeBSD src repository Modified files: contrib/pf/pfctl pfctl_altq.c pfctl_qstats.c sys/contrib/pf/net pf_if.c pf_ioctl.c pfvar.h Log: Make ALTQ cope with disappearing interfaces (particularly common with mpd and netgraph in gernal). This also allows to add queues for an interface that is not yet existing (you have to provide the bandwidth for the interface, however). PR: kern/106400, kern/117827 MFC after: 2 weeks Revision Changes Path 1.10 +12 -0 src/contrib/pf/pfctl/pfctl_altq.c 1.7 +26 -0 src/contrib/pf/pfctl/pfctl_qstats.c 1.15 +6 -0 src/sys/contrib/pf/net/pf_if.c 1.31 +116 -2 src/sys/contrib/pf/net/pf_ioctl.c 1.17 +7 -0 src/sys/contrib/pf/net/pfvar.h _______________________________________________ cvs-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/cvs-all To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 01:00:04 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99A9E1065670 for ; Sat, 29 Mar 2008 01:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6F7B58FC19 for ; Sat, 29 Mar 2008 01:00:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T104WT047428 for ; Sat, 29 Mar 2008 01:00:04 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T104ib047427; Sat, 29 Mar 2008 01:00:04 GMT (envelope-from gnats) Date: Sat, 29 Mar 2008 01:00:04 GMT Message-Id: <200803290100.m2T104ib047427@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Max Laier Cc: Subject: Re: kern/117827: [pf] [panic] kernel panic with pf and ng X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Laier 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: Sat, 29 Mar 2008 01:00:04 -0000 The following reply was made to PR kern/117827; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, dimanenator@gmail.com Cc: Subject: Re: kern/117827: [pf] [panic] kernel panic with pf and ng Date: Sat, 29 Mar 2008 01:56:36 +0100 Here are MFC patches for RELENG_6 and RELENG_7, please test and report back, thanks! http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R6.diff http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R7.diff -- Max From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 01:00:16 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E3821065670; Sat, 29 Mar 2008 01:00:16 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 254588FC19; Sat, 29 Mar 2008 01:00:16 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T10Gg4047846; Sat, 29 Mar 2008 01:00:16 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T10GZP047842; Sat, 29 Mar 2008 01:00:16 GMT (envelope-from mlaier) Date: Sat, 29 Mar 2008 01:00:16 GMT Message-Id: <200803290100.m2T10GZP047842@freefall.freebsd.org> To: bst2006@dva.dyndns.org, mlaier@FreeBSD.org, freebsd-pf@FreeBSD.org From: mlaier@FreeBSD.org Cc: Subject: Re: kern/106400: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 29 Mar 2008 01:00:16 -0000 Synopsis: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached State-Changed-From-To: open->feedback State-Changed-By: mlaier State-Changed-When: Sat Mar 29 00:59:25 UTC 2008 State-Changed-Why: MFC patches need testing, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=106400 From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 01:00:48 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2D51065671; Sat, 29 Mar 2008 01:00:48 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 62E0B8FC1D; Sat, 29 Mar 2008 01:00:48 +0000 (UTC) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T10mAT047896; Sat, 29 Mar 2008 01:00:48 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T10m5p047892; Sat, 29 Mar 2008 01:00:48 GMT (envelope-from mlaier) Date: Sat, 29 Mar 2008 01:00:48 GMT Message-Id: <200803290100.m2T10m5p047892@freefall.freebsd.org> To: dimanenator@gmail.com, mlaier@FreeBSD.org, freebsd-pf@FreeBSD.org From: mlaier@FreeBSD.org Cc: Subject: Re: kern/117827: [pf] [panic] kernel panic with pf and ng X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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: Sat, 29 Mar 2008 01:00:48 -0000 Synopsis: [pf] [panic] kernel panic with pf and ng State-Changed-From-To: open->feedback State-Changed-By: mlaier State-Changed-When: Sat Mar 29 01:00:24 UTC 2008 State-Changed-Why: MFC patches need testing, thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=117827 From owner-freebsd-pf@FreeBSD.ORG Sat Mar 29 01:10:02 2008 Return-Path: Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B96FF106566B for ; Sat, 29 Mar 2008 01:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8FA828FC16 for ; Sat, 29 Mar 2008 01:10:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m2T1A20q048105 for ; Sat, 29 Mar 2008 01:10:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m2T1A2FV048104; Sat, 29 Mar 2008 01:10:02 GMT (envelope-from gnats) Date: Sat, 29 Mar 2008 01:10:02 GMT Message-Id: <200803290110.m2T1A2FV048104@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: Max Laier Cc: Subject: Re: kern/106400: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Max Laier 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: Sat, 29 Mar 2008 01:10:02 -0000 The following reply was made to PR kern/106400; it has been noted by GNATS. From: Max Laier To: bug-followup@freebsd.org, bst2006@dva.dyndns.org Cc: Subject: Re: kern/106400: [pf] fatal trap 12 at restart of PF with ALTQ if ng0 device has detached Date: Sat, 29 Mar 2008 01:56:46 +0100 Here are MFC patches for RELENG_6 and RELENG_7, please test and report back, thanks! http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R6.diff http://people.freebsd.org/%7Emlaier/pf.dyn_altq.R7.diff -- Max