From owner-freebsd-pf@FreeBSD.ORG Mon Nov 14 11:02:33 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F49916A425 for ; Mon, 14 Nov 2005 11:02:33 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0D2F43D45 for ; Mon, 14 Nov 2005 11:02:32 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAEB2WEi073800 for ; Mon, 14 Nov 2005 11:02:32 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAEB2WnK073794 for freebsd-pf@freebsd.org; Mon, 14 Nov 2005 11:02:32 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Nov 2005 11:02:32 GMT Message-Id: <200511141102.jAEB2WnK073794@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-pf@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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, 14 Nov 2005 11:02:33 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/06/15] kern/82271 pf [pf] cbq scheduler cause bad latency f [2005/07/31] kern/84370 pf [modules] Unload pf.ko cause page fault f [2005/09/13] i386/86072 pf [pf] Packet Filter rule not working prope 3 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2005/05/15] conf/81042 pf [pf] [patch] /etc/pf.os doesn't match Fre 1 problem total. From owner-freebsd-pf@FreeBSD.ORG Mon Nov 14 12:25:02 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B69F16A41F for ; Mon, 14 Nov 2005 12:25:02 +0000 (GMT) (envelope-from montarotech@optusnet.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id A983443D46 for ; Mon, 14 Nov 2005 12:25:01 +0000 (GMT) (envelope-from montarotech@optusnet.com.au) Received: from delta (d220-236-83-17.dsl.nsw.optusnet.com.au [220.236.83.17]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with SMTP id jAECOnWQ021219 for ; Mon, 14 Nov 2005 23:24:56 +1100 Message-ID: <002701c5e916$6d8285f0$0600a8c0@delta> From: "Josh Finlay" To: Date: Mon, 14 Nov 2005 22:24:47 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: 2x SDSL + Load sharing 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, 14 Nov 2005 12:25:02 -0000 Hi, I have a setup that has 2 (two) 512/512kbps SDSL lines and around 20 computers on the network I am setting up PF/ALTQ to load share between the two I am assuming I can do a round-robin NAT with PF? and when specifying the available bandwidth for ALTQ would I be able to just say 1M up 1M down and have them all share both lines, or would I need to specify the queues for each SDSL line seperately as 512/512 and put say 10 machines sharing one connection and 10 the other? Regards, Josh Finlay. From owner-freebsd-pf@FreeBSD.ORG Tue Nov 15 18:24:33 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AAAD16A41F; Tue, 15 Nov 2005 18:24:33 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CFE543D55; Tue, 15 Nov 2005 18:24:29 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAFIOS9X080976; Tue, 15 Nov 2005 18:24:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAFIOSBB080972; Tue, 15 Nov 2005 18:24:28 GMT (envelope-from linimon) Date: Tue, 15 Nov 2005 18:24:28 GMT From: Mark Linimon Message-Id: <200511151824.jAFIOSBB080972@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: bin/89058: [pf] pfctl(8) parser is too terse when detecting syntax in table specification 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, 15 Nov 2005 18:24:33 -0000 Synopsis: [pf] pfctl(8) parser is too terse when detecting syntax in table specification Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Tue Nov 15 18:24:18 GMT 2005 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=89058 From owner-freebsd-pf@FreeBSD.ORG Tue Nov 15 18:56:39 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9FCE516A421; Tue, 15 Nov 2005 18:56:39 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9238643D46; Tue, 15 Nov 2005 18:56:28 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAFIuSGR084080; Tue, 15 Nov 2005 18:56:28 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAFIuR43084074; Tue, 15 Nov 2005 18:56:27 GMT (envelope-from mlaier) Date: Tue, 15 Nov 2005 18:56:27 GMT From: Max Laier Message-Id: <200511151856.jAFIuR43084074@freefall.freebsd.org> To: vlada@devnull.cz, mlaier@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: bin/89058: [pf] pfctl(8) parser is too terse when detecting syntax in table specification 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, 15 Nov 2005 18:56:39 -0000 Synopsis: [pf] pfctl(8) parser is too terse when detecting syntax in table specification State-Changed-From-To: open->closed State-Changed-By: mlaier State-Changed-When: Tue Nov 15 18:54:46 GMT 2005 State-Changed-Why: This is fixed in 6.0 and later. MFC is considered too disruptive for this low critical problem. Possibly pfctl -nvf helps. http://www.freebsd.org/cgi/query-pr.cgi?pr=89058 From owner-freebsd-pf@FreeBSD.ORG Tue Nov 15 19:20:19 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B4E1716A41F for ; Tue, 15 Nov 2005 19:20:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DBA043D49 for ; Tue, 15 Nov 2005 19:20:19 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAFJKJ8d090121 for ; Tue, 15 Nov 2005 19:20:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAFJKJS5090120; Tue, 15 Nov 2005 19:20:19 GMT (envelope-from gnats) Date: Tue, 15 Nov 2005 19:20:19 GMT Message-Id: <200511151920.jAFJKJS5090120@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: =?ISO-8859-1?Q?Vladim=EDr_Kotal?= Cc: Subject: Re: bin/89058: [pf] pfctl(8) parser is too terse when detecting syntax in table specification X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Vladim=EDr_Kotal?= 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, 15 Nov 2005 19:20:19 -0000 The following reply was made to PR bin/89058; it has been noted by GNATS. From: =?ISO-8859-1?Q?Vladim=EDr_Kotal?= To: bug-followup@FreeBSD.org, =?ISO-8859-1?Q?Vladim=EDr_Kotal?= Cc: Subject: Re: bin/89058: [pf] pfctl(8) parser is too terse when detecting syntax in table specification Date: Tue, 15 Nov 2005 20:10:55 +0100 The -n option does not even report the syntax error help because of this code in pfctl.c: if (parse_rules(fin, &pf) < 0) { if ((opts & PF_OPT_NOACTION) == 0) ERRX("Syntax error in config file: " "pf rules not loaded"); else goto _error; } The -v option does not help either. From owner-freebsd-pf@FreeBSD.ORG Tue Nov 15 22:35:06 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6479616A420 for ; Tue, 15 Nov 2005 22:35:06 +0000 (GMT) (envelope-from sebosik@demax.sk) Received: from dorm.student.utc.sk (dorm.student.utc.sk [158.193.82.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6963343D58 for ; Tue, 15 Nov 2005 22:35:04 +0000 (GMT) (envelope-from sebosik@demax.sk) Received: from [192.168.1.2] (unknown [158.193.82.138]) by dorm.student.utc.sk (Postfix) with ESMTP id BB18673093 for ; Tue, 15 Nov 2005 23:44:14 +0100 (CET) Message-ID: <437A6296.2010105@demax.sk> Date: Tue, 15 Nov 2005 23:35:02 +0100 From: Jany User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20050929 MultiZilla/1.7.9.0a X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Multicast over NAT 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, 15 Nov 2005 22:35:06 -0000 Hello in our network it is possible to watch TV and to hear radio over net (they are multicasted). I`ve got simple NAT on my FreeBSD 6 (pf.conf) box: ## PF config for my test box # ## macros ext_if = "fxp0" int_if = "ex0" ## tables table const { 192.168.1.0/24 } ## packet normalization scrub in all ## NAT nat on $ext_if from $int_if:network to any -> $ext_if # FTP workaround rdr pass on $int_if proto tcp from any to !($ext_if) port 21 -> 127.0.0.1 port 8021 # DC++ redir -port 19670 rdr pass on $ext_if proto {tcp,udp} from any to 195.62.17.204 port 19670 \ -> 192.168.1.2 # torrent to local LAN on port 41800:41810 rdr pass on $ext_if proto {tcp,udp} from any to $ext_if port 41800:41810 \ -> 192.168.1.2 port 41800:* ## packet filtering ####################################################################### ## default blocking policy block in log on $ext_if all ## antispoof-ing :) antispoof quick for $int_if inet ## lo0 all traffic passing pass on lo0 all ## allowing traffic to the LAN pass on $int_if from any to any flags S/SA keep state ## allow traffic to remote hosts from $ext_if pass out on $ext_if proto {tcp, udp} from $ext_if to any flags S/SA modulate state pass in log on $ext_if proto {tcp, udp} from any to $ext_if port {123, 53}\ keep state flags S/SA ## allow DNS resolving from local to 195.62.17.204 pass out on $int_if proto {tcp, udp} from $int_if:network to $int_if \ port 53 flags S/SA keep state pass out on lo0 proto {tcp, udp} from $ext_if to $ext_if port 53 keep state ## allowing ICMP from internet, 8-echo 0-echoreply 3-destination unreachable pass inet proto { icmp } icmp-type { 0, 3, 8 } keep state ## allowing torrent traffic pass in on $ext_if proto {tcp,udp} from any to 195.62.17.204 port \ { 6880 >< 6890, 40800 >< 40810, 41800 >< 41810 } flags S/SA keep state ## allow DC++ traffic pass in on $ext_if proto { tcp, udp } from any to 195.62.17.204 port 19670 flags S/SA keep state ## allow accessing FTP server from internet pass in log on $ext_if proto { tcp, udp } from any to 195.62.17.204 port 21 \ flags S/SA keep state pass in log on $ext_if proto { tcp, udp } from any to 195.62.17.204 port >= 49152 \ flags S/SA keep state ## FTP from local net pass in on $ext_if inet proto tcp from port 20 to ($ext_if) \ user proxy flags S/SA keep state I found that I need to allow packets with allow-opts (IGMP) - which I also tried, but it doesn`t help... If i trie to fetch playlist in VLC via SAP announces, it sends some IGMP packets to $int_if, but they won`t pass out on $ext_if. Is it possible to config Packet Filter to support multicast traffic. From owner-freebsd-pf@FreeBSD.ORG Tue Nov 15 23:10:32 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 030BD16A421 for ; Tue, 15 Nov 2005 23:10:32 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91A4343D4C for ; Tue, 15 Nov 2005 23:10:31 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so1093328nzo for ; Tue, 15 Nov 2005 15:10:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cR+U9qRErYwYX1wTRHedrL/tJnT/kmYR8on3YbfBN2Az8DtQafD3GKGthZg3vCAyw7yKjwiUgsD9zxRvRM3EuyaWfIEG0DIVPHzVUf00amMLURYr7sz966ZECaZFq5uqLUQLJvoFuYK/gfZFcWow89GVTJVtwE2TQhrG9ZLmop0= Received: by 10.37.18.73 with SMTP id v73mr5636482nzi; Tue, 15 Nov 2005 15:10:31 -0800 (PST) Received: by 10.36.101.18 with HTTP; Tue, 15 Nov 2005 15:10:31 -0800 (PST) Message-ID: <6650332b0511151510x4b80684er3032af22182f4480@mail.gmail.com> Date: Tue, 15 Nov 2005 15:10:31 -0800 From: Steven Schoch Sender: schoch6@gmail.com To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Problem with ftp-proxy 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, 15 Nov 2005 23:10:32 -0000 I can't get ftp-proxy to work for a non-passive FTP. Here's how I have it set up: in /etc/pf.conf: # rdr outgoing FTP requests to the ftp-proxy rdr on $int_if proto tcp from any to !($ext_if) port ftp -> 127.0.0.1 port = 8021 I put ftp-proxy in debug mode with this line in /etc/inetd.conf: ftp-proxy stream tcp nowait root /usr/libexec/ftp-proxy ftp-proxy -u proxy -m 55000 -M 57000 -D 3 When I connect from an internel machine, ftp proxy logs lots of info to /var/log/debug.log. Something is getting in the way, however. I run ftp from a Windows XP machine on 102.168.1.104: ftp> debug ftp> open ftp.starnet.com Connected to starnet.com. 220 starnet.com NcFTPd Server (licensed copy) ready. User (starnet.com:(none)): ftp ---> USER ftp 331 Guest login ok, send your complete e-mail address as password. Password: ---> PASS @starnet.com 230-You are user #1 of 32 simultaneous users allowed. 230- 230 Logged in anonymously. ftp> ls ---> PORT 192,168,1,104,17,233 200 PORT command successful. ---> NLST And then, nothing. Calculating 17 * 256 + 233 =3D 4585, and yes, my Windows machine is actually listening on that port: C:\>netstat -a Active Connections Proto Local Address Foreign Address State TCP steven:4585 steven:0 LISTENING However, when I examine the debug.log file on the gateway, it has this: Nov 15 14:51:36 freebsd ftp-proxy[24862]: client line buffer is "PORT 192,168,1,104,19,137^M " Nov 15 14:51:36 freebsd ftp-proxy[24862]: Got a PORT command Nov 15 14:51:36 freebsd ftp-proxy[24862]: client wants us to use 192.168.1.104:5001 Where did this translation take place? I looked at the source for ftp-proxy and it seems to log the "client line buffer" as it reads it from the client. I verified that there is only one copy of ftp-proxy running, so what did this translation? Ftp-proxy attempts to connect to port 5001 instead of 4585, which of course fails. -- Steve From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 00:24:19 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6DF316A41F for ; Wed, 16 Nov 2005 00:24:19 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55DFD43D45 for ; Wed, 16 Nov 2005 00:24:19 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: by zproxy.gmail.com with SMTP id k1so1576510nzf for ; Tue, 15 Nov 2005 16:24:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=txmiFtlLJZi2Bb2ECTKohgB/CyxpN2bH9QKkeh3aSzHvxPtyUoq7R3HJfd0/e2dW5rLnjhBelxxjdirYZD6iYO4KGo97Sx9RO71i4IKGQvKCi9eF4/xRJGney6Sjl5dr7SfxYX58ZISkrGK/F6jZzCYrbv5mMeYVieevU9ySpBM= Received: by 10.36.247.5 with SMTP id u5mr5627660nzh; Tue, 15 Nov 2005 16:24:18 -0800 (PST) Received: by 10.36.101.18 with HTTP; Tue, 15 Nov 2005 16:24:18 -0800 (PST) Message-ID: <6650332b0511151624g6333cae6md931f95ea71e6572@mail.gmail.com> Date: Tue, 15 Nov 2005 16:24:18 -0800 From: Steven Schoch Sender: schoch6@gmail.com To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Another problem with ftp-proxy 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, 16 Nov 2005 00:24:19 -0000 This one seems to be caused by a mis-behaving FTP client, in this case ClickTracks. But ftp-proxy looks like it's doing something wrong. Here are a few lines from the logfile: Nov 15 16:05:01 freebsd ftp-proxy[27010]: client line buffer is "STRU F^M " Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:01 freebsd ftp-proxy[27010]: server line buffer is "200 Structure okay.^M " Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:01 freebsd ftp-proxy[27010]: client line buffer is "CWD " Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:01 freebsd ftp-proxy[27010]: client line buffer is "^M " Nov 15 16:05:01 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:03 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:03 freebsd ftp-proxy[27010]: server line buffer is "501 Syntax error in parameters.^M " Nov 15 16:05:03 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:03 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:03 freebsd ftp-proxy[27010]: client line buffer is "PASV^M " Nov 15 16:05:03 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:06 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:06 freebsd ftp-proxy[27010]: server line buffer is "500 Syntax error, command unrecognized.^M " Nov 15 16:05:06 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:06 freebsd ftp-proxy[27010]: client is alive; server is alive Nov 15 16:05:06 freebsd ftp-proxy[27010]: server line buffer is "227 Entering Passive Mode (209,197,97,252,208,116)^M " Notice that most of the client line buffers end in ^M, which I assume is a good clue that the next character is a newline, but the "CWD" line seems to be split in two, which results in two responses from the server: "501 Syntax error" and "500 Syntax error". The client seems to handle the first 501 error ok, but since the 500 error is still in its buffer, it sees that as an error to the "PASV" command. Anyone else seen this? -- Steve From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 05:58:32 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1550F16A41F; Wed, 16 Nov 2005 05:58:32 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id A50F943D46; Wed, 16 Nov 2005 05:58:31 +0000 (GMT) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAG5wVfQ099791; Wed, 16 Nov 2005 05:58:31 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAG5wVoj099786; Wed, 16 Nov 2005 05:58:31 GMT (envelope-from linimon) Date: Wed, 16 Nov 2005 05:58:31 GMT From: Mark Linimon Message-Id: <200511160558.jAG5wVoj099786@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: bin/89079: pfctl(8) does not check interface name against list of known interfaces with () operator 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, 16 Nov 2005 05:58:32 -0000 Old Synopsis: pfctl does not check interface name against list of known interfaces with () operator New Synopsis: pfctl(8) does not check interface name against list of known interfaces with () operator Responsible-Changed-From-To: freebsd-bugs->freebsd-pf Responsible-Changed-By: linimon Responsible-Changed-When: Wed Nov 16 05:57:18 GMT 2005 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=89079 From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 07:55:45 2005 Return-Path: X-Original-To: freebsd-pf@hub.freebsd.org Delivered-To: freebsd-pf@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 608F316A420; Wed, 16 Nov 2005 07:55:45 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EBEE43D45; Wed, 16 Nov 2005 07:55:45 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from freefall.freebsd.org (mlaier@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jAG7tjIX018040; Wed, 16 Nov 2005 07:55:45 GMT (envelope-from mlaier@freefall.freebsd.org) Received: (from mlaier@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jAG7tiwr018036; Wed, 16 Nov 2005 07:55:44 GMT (envelope-from mlaier) Date: Wed, 16 Nov 2005 07:55:44 GMT From: Max Laier Message-Id: <200511160755.jAG7tiwr018036@freefall.freebsd.org> To: vlada@devnull.cz, mlaier@FreeBSD.org, freebsd-pf@FreeBSD.org Cc: Subject: Re: bin/89079: pfctl(8) does not check interface name against list of known interfaces with () operator 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, 16 Nov 2005 07:55:45 -0000 Synopsis: pfctl(8) does not check interface name against list of known interfaces with () operator State-Changed-From-To: open->closed State-Changed-By: mlaier State-Changed-When: Wed Nov 16 07:53:00 GMT 2005 State-Changed-Why: This is not a bug. One needs this behaviour in order to write rules for not-yet existing interfaces. e.g. loading rules *before* bringing up pppd(8) and thus tun0. Can you please take such problems to the freebsd-pf@ mailing list first. Thanks. http://www.freebsd.org/cgi/query-pr.cgi?pr=89079 From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 22:11:49 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACBC916A420 for ; Wed, 16 Nov 2005 22:11:49 +0000 (GMT) (envelope-from MGrooms@seton.org) Received: from mx1-out.seton.org (mx1-out.seton.org [207.193.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FEF443D68 for ; Wed, 16 Nov 2005 22:11:45 +0000 (GMT) (envelope-from MGrooms@seton.org) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id 4CA83F000945 for ; Wed, 16 Nov 2005 16:11:44 -0600 (CST) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 13562-45 for ; Wed, 16 Nov 2005 16:11:44 -0600 (CST) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id 3D083F00090A for ; Wed, 16 Nov 2005 16:11:44 -0600 (CST) Received: from [10.20.160.190] ([10.20.160.190]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 16:11:11 -0600 Message-ID: <437BB031.9090504@seton.org> Date: Wed, 16 Nov 2005 16:18:25 -0600 From: Matthew Grooms Organization: Seton Healthcare Network User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 22:11:11.0131 (UTC) FILETIME=[A6D026B0:01C5EAFA] X-Virus-Scanned: by amavisd-new at seton.org Subject: Traffic Shaping with 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, 16 Nov 2005 22:11:49 -0000 All, I have a couple of firewalls running freebsd 5.4 and pf and was planning to use ALTQ for traffic shaping. But after doing a bit of reading, it would seem that ALTQ only works on traffic passing outbound on an interface. Since most of the traffic passing through my firewall is http and ftp traffic, the inbound direction is the path being saturated. Did I read the ALTQ documentation wrong or is there another mechanism available for use with pf that could help me prioritize bandwidth usage? Thanks in advance, -Matthew From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 22:20:08 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1468116A41F for ; Wed, 16 Nov 2005 22:20:08 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7179443D49 for ; Wed, 16 Nov 2005 22:20:07 +0000 (GMT) (envelope-from max@love2party.net) Received: from [84.163.204.14] (helo=donor.laier.local) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1EcVdM2QVv-0002MI; Wed, 16 Nov 2005 23:20:05 +0100 From: Max Laier To: freebsd-pf@freebsd.org Date: Wed, 16 Nov 2005 23:19:47 +0100 User-Agent: KMail/1.8.2 References: <437BB031.9090504@seton.org> In-Reply-To: <437BB031.9090504@seton.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8147444.O8u2PtQztv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200511162319.58857.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Matthew Grooms Subject: Re: Traffic Shaping with 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, 16 Nov 2005 22:20:08 -0000 --nextPart8147444.O8u2PtQztv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 16 November 2005 23:18, Matthew Grooms wrote: > I have a couple of firewalls running freebsd 5.4 and pf and was > planning to use ALTQ for traffic shaping. But after doing a bit of > reading, it would seem that ALTQ only works on traffic passing outbound > on an interface. Since most of the traffic passing through my firewall > is http and ftp traffic, the inbound direction is the path being > saturated. Did I read the ALTQ documentation wrong or is there another > mechanism available for use with pf that could help me prioritize > bandwidth usage? You can not control inbound traffic! You can not control what other people= =20 sent to you! It's impossible. The only way to do it is to limit *outbound= *=20 traffic on an upstream router. =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 --nextPart8147444.O8u2PtQztv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQBDe7COXyyEoT62BG0RApMOAJ92eDkfxCtlrIn8TOdG2kzwLEpHDgCfV93C OJsmnUGbbCXGxLAa6NzGlU4= =3jqU -----END PGP SIGNATURE----- --nextPart8147444.O8u2PtQztv-- From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 22:43:31 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 476C216A41F for ; Wed, 16 Nov 2005 22:43:31 +0000 (GMT) (envelope-from MGrooms@seton.org) Received: from mx1-out.seton.org (mx1-out.seton.org [207.193.126.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id DAD5C43D46 for ; Wed, 16 Nov 2005 22:43:30 +0000 (GMT) (envelope-from MGrooms@seton.org) Received: from localhost (unknown [127.0.0.1]) by mx1-out.seton.org (Postfix) with ESMTP id 80DC5F00094C; Wed, 16 Nov 2005 16:43:30 -0600 (CST) Received: from mx1-out.seton.org ([10.21.254.249]) by localhost (mx1 [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 14388-01; Wed, 16 Nov 2005 16:43:30 -0600 (CST) Received: from ausexfe01.seton.org (ausexfe01.seton.org [10.20.10.211]) by mx1-out.seton.org (Postfix) with ESMTP id 6F5F8F00090A; Wed, 16 Nov 2005 16:43:30 -0600 (CST) Received: from [10.20.160.190] ([10.20.160.190]) by ausexfe01.seton.org with Microsoft SMTPSVC(6.0.3790.211); Wed, 16 Nov 2005 16:43:28 -0600 Message-ID: <437BB7A3.2080005@seton.org> Date: Wed, 16 Nov 2005 16:50:11 -0600 From: Matthew Grooms Organization: Seton Healthcare Network User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Laier References: <437BB031.9090504@seton.org> <200511162319.58857.max@love2party.net> In-Reply-To: <200511162319.58857.max@love2party.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Nov 2005 22:43:28.0077 (UTC) FILETIME=[2952A7D0:01C5EAFF] X-Virus-Scanned: by amavisd-new at seton.org Cc: freebsd-pf@freebsd.org Subject: Re: Traffic Shaping with 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, 16 Nov 2005 22:43:31 -0000 Max Laier wrote: > On Wednesday 16 November 2005 23:18, Matthew Grooms wrote: > >> I have a couple of firewalls running freebsd 5.4 and pf and was >>planning to use ALTQ for traffic shaping. But after doing a bit of >>reading, it would seem that ALTQ only works on traffic passing outbound >>on an interface. Since most of the traffic passing through my firewall >>is http and ftp traffic, the inbound direction is the path being >>saturated. Did I read the ALTQ documentation wrong or is there another >>mechanism available for use with pf that could help me prioritize >>bandwidth usage? > > > You can not control inbound traffic! You can not control what other people > sent to you! It's impossible. The only way to do it is to limit *outbound* > traffic on an upstream router. > Max, As always, thanks for your reply. Sounds like you may have heard this question once or twice ;) Sorry for being naive. I understand what you are saying and this makes sense to me. But would it stand to reason that if you limit the rate of packets in a TCP stream that the windowing would slow the generation of traffic from the source host? I understand UDP is another animal all together. Do pipes in ipfw only effect outbound traffic on an interface? Thanks, -Matthew From owner-freebsd-pf@FreeBSD.ORG Wed Nov 16 23:35:44 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63B7016A41F for ; Wed, 16 Nov 2005 23:35:44 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id B3D3F43D45 for ; Wed, 16 Nov 2005 23:35:43 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jAGNZca8007805 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2005 00:35:38 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jAGNZc30029540; Thu, 17 Nov 2005 00:35:38 +0100 (MET) Date: Thu, 17 Nov 2005 00:35:37 +0100 From: Daniel Hartmeier To: Matthew Grooms Message-ID: <20051116233537.GT29615@insomnia.benzedrine.cx> References: <437BB031.9090504@seton.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <437BB031.9090504@seton.org> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: Traffic Shaping with 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, 16 Nov 2005 23:35:44 -0000 On Wed, Nov 16, 2005 at 04:18:25PM -0600, Matthew Grooms wrote: > I have a couple of firewalls running freebsd 5.4 and pf and was > planning to use ALTQ for traffic shaping. But after doing a bit of > reading, it would seem that ALTQ only works on traffic passing outbound > on an interface. Since most of the traffic passing through my firewall > is http and ftp traffic, the inbound direction is the path being > saturated. Did I read the ALTQ documentation wrong or is there another > mechanism available for use with pf that could help me prioritize > bandwidth usage? This question pops up frequently, if this reply is too wordy, that's just so I can reference it in the future and safe typing. My apologies to the poster if this is all obvious already. ;) Rate-limiting network packets means dropping packets. It's not like a water utility pipe where you can shut the faucet incrementally and slow down the water running towards you from the water company, leaving unused water in their tanks. There are no reservoirs like that in a network (ignoring some very small buffers). If a sender is sending you packets at a rate higher than you can receive them, packets are dropped whereever there are gaps of decreasing bandwidth. And these gaps are on routers at your ISP and further upstream. Many of them will drop random packets. Some can be configured to drop based on criteria, but you don't control those criteria, because they're not your routers. Imagine you have a 1024 kbit/s downlink from your ISP to you. Assume your ISP himself has a much larger downlink himself. You're downloading a file from a web server on the Internet. Then some evil person starts sending you a flood of pings. Let's say that person has an uplink of 2048 kbit/s. Now your ISP is receiving two kinds of packets destined for you: a stream of TCP packets from the web server, and a stream of pings at 2048 kbits/. He can't possibly forward all these packets to you, since only less than half of them fit onto the link to you. So he simply forwards as many packets as he can, randomly dropping the rest. Obviously many of the TCP packets will get dropped randomly now. TCP is clever and adjust to this, the sender recognizes that there is loss between him and you, and will start to send at a lower rate. Meanwhile the flooder continues to send you pings at a happy rate of 2048 kbit/s. You'll notice how your download gets slower and slower, and you consider using rate-limiting incoming packets. You identify that the http packets are those that you prefer over the pings, and tell ALTQ to drop incoming pings exceeding, say, a harmless rate of 64 kbit/s and reserve the rest for the more important http packets. Fine, it could do that. But it wouldn't change anything, because the congestion is upstream of your ALTQ box. You can drop as many packets as you like after you received them, that doesn't free up any bandwidth on your downlink. The downlink will continue to carry mostly ping packets, because you dropping packets has no influence on what happens at either sender, at your ISP's router dropping random packets, or on your downlink. Just like the rate of water you can draw from your water line isn't influenced by what you do with the water that has already come out of it. Rate-limiting is not like a faucet. This is the reason you often get the answer "It just doesn't make sense to rate-limit incoming packets", and I guess that's the reason why ALTQ simply doesn't add queues for incoming packets, but only outgoing ones. Now, if we forget about the DoS case, and assume you have only flow-controlled TCP connections with cooperative peers, things are a little different. If you receive two streams of TCP packets, and you start dropping packets of one stream (after you have received them and they have taken up bandwidth on your downlink), the corresponding peer will detect that loss and helpfully slow down sending, freeing up bandwidth on your downlink for the other peer. In fact, if you tell your ALTQ box to limit one stream to, say, 128 kbit/s, and drop all excess packets, that peer will (eventually, by trial and error) come to the conclusion that sending you packets at a rate of about 128 kbit/s is the optimal thing to do. But it's important to realize that you're not really "enforcing" this limit, but it's the peer that kindly reacts in that way. If you want to do this with ALTQ, you can do so by limiting outgoing packets on the "other" interface, assuming the box is forwarding all packets between two interfaces. If a browser (on a separate local box) is downloading a file from an external web server _through_ the ALTQ box, you rate-limit packets going out through the internal interface. Every packet coming in on the external interface obviously goes out through the internal interface, hence rate-limiting outgoing packets on the internal interface has the same effect as rate-limiting incoming packets on the external interface. This does not work if the client is on the ALTQ box itself, obviously (there is no "other" interface to rate-limit on). In this case you're facing a limitation of ALTQ itself. You might have to move ALTQ onto an additional intermediate box, just so you do have a second interface. I don't think there are any plans to introduce incoming queues in ALTQ. Daniel From owner-freebsd-pf@FreeBSD.ORG Thu Nov 17 06:44:42 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DB4F16A41F for ; Thu, 17 Nov 2005 06:44:42 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id A241D43D49 for ; Thu, 17 Nov 2005 06:44:41 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id i5so86858wra for ; Wed, 16 Nov 2005 22:44:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=flnVoPDVpWmiTSTlnDhZSp+kVQpw0mkXQnYPVYHVNzN01d0iM2h5ksM9+5RG/7Py+kJyS4i5t6F3UEDVyvO+TX1BPKeVexfGfXQI2bHXrK6aPYfpAv8klwOvcO5QphXQ9kL2ZKRMTGbrHd6ssiXAD/ESg0iInsSGqOTDkn7yByE= Received: by 10.54.151.13 with SMTP id y13mr307597wrd; Wed, 16 Nov 2005 22:44:41 -0800 (PST) Received: by 10.54.80.14 with HTTP; Wed, 16 Nov 2005 22:44:41 -0800 (PST) Message-ID: Date: Thu, 17 Nov 2005 00:44:41 -0600 From: "Travis H." To: Daniel Hartmeier In-Reply-To: <20051108095903.GB6116@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051108074236.18256.qmail@web32602.mail.mud.yahoo.com> <20051108095903.GB6116@insomnia.benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: PF "keep state" for ICMP 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: Thu, 17 Nov 2005 06:44:42 -0000 (Any ICMP traffic is allowed back in after an outbound ICMP that keeps stat= e) > Assuming you're a malicious A, what do you gain, though? You're already > getting pinged by C, so you know it's there. You could already deliver > an arbitrary amount of reply packets. Fingerprinting sillyness? Oooh, a challenge in creative thinking! First, remember that src IPs are eminently spoofable. So no protection the= re. Next let's handle the issue of the IDs. They appear to be 16-bit values, so if the number sent out during a state expiry period is P, and the attacker sends Q responses, then we expect that a reply will get back in if PQ is close to 65536, and this assumes perfectly random IDs in both the outbound and inbound... i.e. a perfect world. Lemme see, anything that handled net/host unreach intelligently could be fooled into thinking C doesn't exist causing DoS... You could send net redirect messages to reroute traffic to arbitrary places= ... You could query the timestamp on A which may reveal system uptime and thus help distinguish between machines who may be behind NAT and appear to share same IP... The attacker could force the source host to fragment packets for C, which may do something interesting. At least it would reduce the bandwidth from A to C, but it may be a DoS since something in between may be dropping fragments. It could induce such short UDP/TCP fragments such that they don't contain src/dst port information, and thus are dropped by a firewall causing DoS... or possibly allocate reassembly buffers, which could cause DoS in pathological cases.... You could query the address (subnet) mask.... of the internal network. Not scandalous, but do outside hosts really need that information?=20 That's enough to get your subnet-directed broadcast address, and thus use your network as an amplifier. Hmm, nothing too earthshaking but lots of DoS possibilities and some information disclosure. -- http://www.lightconsulting.com/~travis/ -><- "We already have enough fast, insecure systems." -- Schneier & Ferguson GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B From owner-freebsd-pf@FreeBSD.ORG Thu Nov 17 08:21:05 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 605EB16A420 for ; Thu, 17 Nov 2005 08:21:05 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A67943D53 for ; Thu, 17 Nov 2005 08:21:04 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jAH8L0g7000885 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 17 Nov 2005 09:21:01 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jAH8L0ld000404; Thu, 17 Nov 2005 09:21:00 +0100 (MET) Date: Thu, 17 Nov 2005 09:21:00 +0100 From: Daniel Hartmeier To: "Travis H." Message-ID: <20051117082100.GW29615@insomnia.benzedrine.cx> References: <20051108074236.18256.qmail@web32602.mail.mud.yahoo.com> <20051108095903.GB6116@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: PF "keep state" for ICMP 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: Thu, 17 Nov 2005 08:21:05 -0000 On Thu, Nov 17, 2005 at 12:44:41AM -0600, Travis H. wrote: > (Any ICMP traffic is allowed back in after an outbound ICMP that keeps state) No, not any ICMP traffc. Any ICMP error (not query/reply) that references the ICMP query that created state by including its header in the payload. Yes, that header consists of only source/destination address and ICMP id. I.e. even if you know (or guess) the appropriate source and destination addresses, you can still only deliver ICMP errors for that tuple. > > Assuming you're a malicious A, what do you gain, though? You're already > > getting pinged by C, so you know it's there. You could already deliver > > an arbitrary amount of reply packets. Fingerprinting sillyness? > > Oooh, a challenge in creative thinking! > > First, remember that src IPs are eminently spoofable. So no protection there. > > Next let's handle the issue of the IDs. They appear to be 16-bit > values, so if the number sent out during a state expiry period is P, > and the attacker sends Q responses, then we expect that a reply will > get back in if PQ is close to 65536, and this assumes perfectly random > IDs in both the outbound and inbound... i.e. a perfect world. So you're introducing a malicious third party, let's say M, which guesses that there is a state for an ICMP query from C to A. Right, if there is such a state, M can probably guess its address tuple and ICMP id with that many tries. (In the original post, C is the origin of the ICMP query, and A is replying, i.e. C is pinging A. I think you switched those. I'll use S for 'source of query, recpient of reply and spoofed error' and D for 'destination of query, real peer' now.) > Lemme see, anything that handled net/host unreach intelligently could > be fooled into thinking C doesn't exist causing DoS... M could deliver a spoofed ICMP unreach error to S, pretending one of S's query packets to D couldn't reach D, yes. If S is handling ICMP unreach errors _intelligently_, it will not honour that bit of information for other connections, because it's aware that the credentials of referencing an ICMP header are weak (compared to referencing a TCP header including sequence numbers). If S is handling that _stupidly_, it might stop sending _any_ connections to D (or redirect connections to D through M, or such). Yes, it would be nice if pf could protect stupid S against this. But it can't, because there is the legitimate case where D is sending the same ICMP error (where D is really unreachable), and pf can't distinguish the two cases, and can't filter ICMP unreach errors generally, because that would break the legitimate cases, too. E.g. for ping(8) on FreeBSD, an incoming ICMP error referencing one of the outgoing ICMP echo requests is not an unexpected (assumed illegitimate) occurance, it even prints them nicely when they occur. > The attacker could force the source host to fragment packets for C, > which may do something interesting. At least it would reduce the > bandwidth from A to C, but it may be a DoS since something in between > may be dropping fragments. It could induce such short UDP/TCP > fragments such that they don't contain src/dst port information, and > thus are dropped by a firewall causing DoS... or possibly allocate > reassembly buffers, which could cause DoS in pathological cases.... This is the same thing again. You can't very well filter ICMP ttl-exceeded errors referencing ICMP queries, because then you'd immediately break legitimate cases, too. S might be sending ICMP queries with dont-fragment set to do PMTU discovery, for instance. So, you can't drop ICMP errors in general, because they are needed for proper operation of legitimate connections. Only if the sender of an ICMP query is stupid will he allow ICMP errors referencing ICMP queries allow to affect other protocols in his stack. I guess if you want to protect S in this case, you shouldn't allow it to ping untrusted D's, by not creating state. Daniel From owner-freebsd-pf@FreeBSD.ORG Thu Nov 17 10:09:35 2005 Return-Path: X-Original-To: freebsd-pf@FreeBSD.org Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 188DA16A41F for ; Thu, 17 Nov 2005 10:09:35 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from mallaury.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E6B643D5C for ; Thu, 17 Nov 2005 10:09:31 +0000 (GMT) (envelope-from e-masson@kisoft-services.com) Received: from srvbsdnanssv.interne.kisoft-services.com (kisoft.net1.nerim.net [62.212.107.51]) by mallaury.nerim.net (Postfix) with ESMTP id 8CD9D4F3BF for ; Thu, 17 Nov 2005 11:09:24 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by srvbsdnanssv.interne.kisoft-services.com (Postfix) with ESMTP id 059A2D83F for ; Thu, 17 Nov 2005 11:10:08 +0100 (CET) Received: from srvbsdnanssv.interne.kisoft-services.com ([127.0.0.1]) by localhost (srvbsdnanssv.interne.kisoft-services.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54591-05 for ; Thu, 17 Nov 2005 11:10:07 +0100 (CET) Received: by srvbsdnanssv.interne.kisoft-services.com (Postfix, from userid 1001) id 5CED5D837; Thu, 17 Nov 2005 11:10:07 +0100 (CET) To: Mailing List FreeBSD PF From: Eric Masson X-Operating-System: FreeBSD 5.4-RELEASE-p2 i386 Date: Thu, 17 Nov 2005 11:10:07 +0100 Message-ID: <86y83n7fgg.fsf@srvbsdnanssv.interne.kisoft-services.com> User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at interne.kisoft-services.com Cc: Subject: Henning's slide from Venice 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: Thu, 17 Nov 2005 10:09:35 -0000 Hello, Has anyone seen this slide : http://www.openbsd.org/papers/ven05-henning/index.html PF section talks about new features and certain ones such as interface groups are really nifty. Is there any hope to see new features in FreeBSD one of these days or are these changes way too intrusive ? Regards Éric Masson -- J2M> l'usurpation est décelable par le plus neuneu des neuneus... Pour le plus neuneus de neuneus, sans doute. Pour le contributeur moyen de fr.rec.humour, non. -+- GS in : Soyons précis -+- From owner-freebsd-pf@FreeBSD.ORG Thu Nov 17 15:50:42 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA28116A41F for ; Thu, 17 Nov 2005 15:50:42 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (smtp.top.net.ua [193.109.60.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A6A143D46 for ; Thu, 17 Nov 2005 15:50:42 +0000 (GMT) (envelope-from mt@smtp.top.net.ua) Received: from smtp.top.net.ua (localhost [127.0.0.1]) by smtp.top.net.ua (Postfix) with ESMTP id BBA4E5FF78F for ; Thu, 17 Nov 2005 17:50:40 +0200 (EET) Received: by smtp.top.net.ua (Postfix, from userid 1012) id 9E8D15FF78E; Thu, 17 Nov 2005 17:50:40 +0200 (EET) Date: Thu, 17 Nov 2005 17:50:40 +0200 From: Maxim Tuliuk To: freebsd-pf@freebsd.org Message-ID: <20051117155040.GB86099@top.net.ua> References: <437BB031.9090504@seton.org> <200511162319.58857.max@love2party.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200511162319.58857.max@love2party.net> User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Traffic Shaping with 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: Thu, 17 Nov 2005 15:50:42 -0000 On Wed, Nov 16, 2005 at 23:19 +0100, Max Laier wrote: > > on an interface. Since most of the traffic passing through my firewall > > is http and ftp traffic, the inbound direction is the path being > > saturated. Did I read the ALTQ documentation wrong or is there another > > mechanism available for use with pf that could help me prioritize > > bandwidth usage? > > You can not control inbound traffic! You can not control what other people > sent to you! It's impossible. The only way to do it is to limit *outbound* > traffic on an upstream router. But if I'm an ISP, I have to control inbound traffic (botnets, contract agreements etc); in this case rate limit is the simplist and cheapest way -- Maxim Tuliuk WWW: http://primats.org.ua/~mt/ ICQ: 21134222 The bike is absolute freedom of moving From owner-freebsd-pf@FreeBSD.ORG Fri Nov 18 17:01:42 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EA7AC16A41F for ; Fri, 18 Nov 2005 17:01:41 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: from mail01.bsdmail.net (mail01.bsdmail.net [64.243.181.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id B92F643E3A for ; Fri, 18 Nov 2005 17:01:00 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 60384 invoked by uid 89); 18 Nov 2005 17:00:08 -0000 Received: by simscan 1.1.0 ppid: 60318, pid: 60335, t: 6.7743s scanners: attach: 1.1.0 clamav: 0.85.1/m:32/d:941 spam: 3.0.2 Received: from unknown (HELO ?64.243.181.151?) (david@icuhost.net@64.243.181.151) by mail01.bsdmail.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 18 Nov 2005 17:00:01 -0000 Message-ID: <437E088F.7080809@wombatsweb.com> Date: Fri, 18 Nov 2005 11:59:59 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail01.bsdmail.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: Best practices for service provider? 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: Fri, 18 Nov 2005 17:01:42 -0000 This is a loaded question so please bear with me. I could really use the advice/help. I am coming from a FreeBSD 4.9 IPLess IPFW Bridging Firewall ... I had followed the directions from the FreeBSD Handbook ... Recently it crashed, so I had to rebuild it, uhm ... quickly ... This time I decided to include a 3rd NIC so that I could get the nightly emails and pay a bit better attention to its status ... It is working, but giving me some errors about arp: xx:xx:xx:xx:xx:xx is using my IP address my.c.class.xx! I have been scouring the Internet for information, and I decided to give PF a try ... I installed OpenBSD 3.8 but didn't like its CLI interface ... Not that I use a GUI, I don't ... I just hop around much better on FreeBSD ... I drew a picture of what I am envisioning as a firewall solution for me here: http://www.davidpierron.com/img/net-map.jpg I installed FreeBSD 6.0 and cvsup'd ports and src ... put the following into GENERIC: # to allow bridge support device if_bridge #PF device pf device pflog device pfsync #ALTQ options ALTQ options ALTQ_CBQ # Class Bases Queuing (CBQ) options ALTQ_RED # Random Early Detection (RED) options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) options ALTQ_PRIQ # Priority Queuing (PRIQ) #options ALTQ_NOPCC # Required for SMP build # other stuff options IPSTEALTH options HZ=1000 I put the following into rc.conf: defaultrouter="my.c.class.1" hostname="firewall.foo.org" ifconfig_xl0="inet my.c.class.2 netmask 255.255.255.0" usbd_enable="NO" sendmail_enable="NO" cloned_interfaces="bridge0" # create a bridge ifconfig_bridge0="addm rl0 addm rl1" # set bridge to use particular NICs #gateway_enable="YES" pf_enable="YES" # Enable PF (load module if required) pf_rules="/etc/pf.conf" # rules definition file for pf pf_flags="" # additional flags for pfctl startup pflog_enable="YES" # start pflogd(8) pflog_logfile="/var/log/pflog" # where pflogd should store the logfile pflog_flags="" # additional flags for pflogd startup ... and into sysctl.conf: net.link.bridge.pfil_bridge=1 # enables packet filtering on bridge net.link.bridge.pfil_member=1 # enables packet filtering on in and out interfaces #net.inet.ip.forwarding=1 # instead of gateway_enable in rc.conf? I am running into one of two things ... Trying to find information that isn't widely available yet, or trying to figure this out from old posts that don't apply anymore ... The other thing going against me is that I haven't seen anything that resembles my setup ... I am not running any NAT ... I am using real world routable IP addresses ... I am assuming I need a 3rd NIC to be separate from the firewall ... From my recent readings of this lists archives, it doesn't seem that I would want to run a bridge ... It won't allow me to keep state ... If this is the case, how do I not assign the network cards that will be doing the filtering no ip address? I tried some interesting combinations with ifconfig in rc.conf, but they didn't work ... When I thought everything was up and running correctly, I put this box between my router and switch but traffic didn't flow ... I could ping internally, but could not ping the router's address which is the gateway (x.x.x.1) ... I assumed that the internal pinging was working on the 3rd NIC with the real IP address ... My question is, can I use two NICs for PF to do firewalling on to put between the router and the switch and then plug the 3rd NIC in and have it act as a separate interface on the box, or should I simply use 2 NICs and assign them real IP addresses ... If I do that, will IPSTEALTH compiled into the kernel not show the presence of the filtering? I think I have successfully confused myself with redundant or old information out there on the 'net, so again ... any suggestions or advice on what I am trying to accomplish would be greatly appreciated. Thank you for reading, David Pierron From owner-freebsd-pf@FreeBSD.ORG Fri Nov 18 20:26:35 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 347AD16A41F for ; Fri, 18 Nov 2005 20:26:35 +0000 (GMT) (envelope-from dfullerton@mantor.org) Received: from trypticon.mentr.cc (trypticon.mentr.cc [65.98.54.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD54C43D4C for ; Fri, 18 Nov 2005 20:26:32 +0000 (GMT) (envelope-from dfullerton@mantor.org) Received: from [192.168.0.36] (trypticon.mentr.cc [65.98.54.142]) by trypticon.mentr.cc (Mail Daemon) with ESMTP id 4ECA68751 for ; Fri, 18 Nov 2005 15:29:11 -0500 (EST) Message-ID: <437E38EA.6050409@mantor.org> Date: Fri, 18 Nov 2005 15:26:18 -0500 From: Danny Fullerrton User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <437E088F.7080809@wombatsweb.com> In-Reply-To: <437E088F.7080809@wombatsweb.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mentr-MailScanner-Information: Please contact the ISP for more information X-Mentr-MailScanner: Found to be clean X-Mentr-MailScanner-SpamCheck: not spam, SpamAssassin (score=-2.257, required 8, autolearn=not spam, AWL 0.34, BAYES_00 -2.60) X-MailScanner-From: dfullerton@mantor.org Subject: Re: Best practices for service provider? 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: Fri, 18 Nov 2005 20:26:35 -0000 David Pierron wrote: > This is a loaded question so please bear with me. I could really use > the advice/help. > > I am coming from a FreeBSD 4.9 IPLess IPFW Bridging Firewall ... I > had followed the directions from the FreeBSD Handbook ... Recently it > crashed, so I had to rebuild it, uhm ... quickly ... > > This time I decided to include a 3rd NIC so that I could get the > nightly emails and pay a bit better attention to its status ... It is > working, but giving me some errors about arp: xx:xx:xx:xx:xx:xx is > using my IP address my.c.class.xx! I have been scouring the Internet > for information, and I decided to give PF a try ... I installed > OpenBSD 3.8 but didn't like its CLI interface ... Not that I use a > GUI, I don't ... I just hop around much better on FreeBSD ... > > I drew a picture of what I am envisioning as a firewall solution for > me here: > http://www.davidpierron.com/img/net-map.jpg > > I installed FreeBSD 6.0 and cvsup'd ports and src ... put the > following into GENERIC: > > # to allow bridge support > device if_bridge > > #PF > device pf > device pflog > device pfsync > > #ALTQ > options ALTQ > options ALTQ_CBQ # Class Bases Queuing (CBQ) > options ALTQ_RED # Random Early Detection (RED) > options ALTQ_RIO # RED In/Out > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > options ALTQ_PRIQ # Priority Queuing (PRIQ) > #options ALTQ_NOPCC # Required for SMP build > > # other stuff > options IPSTEALTH > options HZ=1000 > > I put the following into rc.conf: > > defaultrouter="my.c.class.1" > hostname="firewall.foo.org" > ifconfig_xl0="inet my.c.class.2 netmask 255.255.255.0" > usbd_enable="NO" > sendmail_enable="NO" > > cloned_interfaces="bridge0" # create a bridge > ifconfig_bridge0="addm rl0 addm rl1" # set bridge to use particular NICs > #gateway_enable="YES" > > pf_enable="YES" # Enable PF (load module if > required) > pf_rules="/etc/pf.conf" # rules definition file for pf > pf_flags="" # additional flags for pfctl startup > pflog_enable="YES" # start pflogd(8) > pflog_logfile="/var/log/pflog" # where pflogd should store the > logfile > pflog_flags="" # additional flags for pflogd > startup > > .. and into sysctl.conf: > > net.link.bridge.pfil_bridge=1 # enables packet filtering on bridge > net.link.bridge.pfil_member=1 # enables packet filtering on in and > out interfaces > #net.inet.ip.forwarding=1 # instead of gateway_enable in rc.conf? > > I am running into one of two things ... Trying to find information > that isn't widely available yet, or trying to figure this out from old > posts that don't apply anymore ... The other thing going against me > is that I haven't seen anything that resembles my setup ... I am not > running any NAT ... I am using real world routable IP addresses ... I > am assuming I need a 3rd NIC to be separate from the firewall ... You can use firewalled interface or bridge interface as normal interface too. It's only depending on your config. You'll find lots of stuff on google refering to a setup like yours but when searching for OpenBSD stuff. > > From my recent readings of this lists archives, it doesn't seem that I > would want to run a bridge ... It won't allow me to keep state ... > If this is the case, how do I not assign the network cards that will > be doing the filtering no ip address? I tried some interesting > combinations with ifconfig in rc.conf, but they didn't work ... When > I thought everything was up and running correctly, I put this box > between my router and switch but traffic didn't flow ... I could ping > internally, but could not ping the router's address which is the > gateway (x.x.x.1) ... I assumed that the internal pinging was working > on the 3rd NIC with the real IP address ... > Statefull mode is working in bridge mode using OpenBSD PF. But I dont known if it's presently the case with the FreeBSD implementation. > My question is, can I use two NICs for PF to do firewalling on to put > between the router and the switch and then plug the 3rd NIC in and > have it act as a separate interface on the box, or should I simply use > 2 NICs and assign them real IP addresses ... If I do that, will > IPSTEALTH compiled into the kernel not show the presence of the > filtering? > As I said, you could use this kind of setup (3 card to keep it simple logic) or ,while using 2 interface in bridge mode, use 1 of them with an internal ip address (bridge and standard). > I think I have successfully confused myself with redundant or old > information out there on the 'net, so again ... any suggestions or > advice on what I am trying to accomplish would be greatly appreciated. > > Thank you for reading, > David Pierron > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > You should begin by playing with Packet Filter while being in bridge mode and gradually including feature like the management ip/interface before going to far and not understanding. Danny Fullerton ---------------------- IT Security Specialist dfullerton@mantor.org From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 00:09:27 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF3A216A41F for ; Sat, 19 Nov 2005 00:09:27 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ECC243D45 for ; Sat, 19 Nov 2005 00:09:27 +0000 (GMT) (envelope-from schoch6@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so317012nzo for ; Fri, 18 Nov 2005 16:09:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mzvta6v2etf6ec0GFgHxXb1T65dPfRMX728ECocd8KEpD7dAQLyHt2jYHsG86Malq09+5ZP7+1AL2nCXz9KPugMclBeqHf9DA9wQc40n08nY6Lwv84qm5VwSxOLo9P6ozAmuc7wySnCty75a7Y5DwucgSOEQwx/WRT8r2lNmTSg= Received: by 10.36.252.75 with SMTP id z75mr326400nzh; Fri, 18 Nov 2005 16:09:27 -0800 (PST) Received: by 10.36.55.6 with HTTP; Fri, 18 Nov 2005 16:09:27 -0800 (PST) Message-ID: <6650332b0511181609s1540c083v2faf8f2f6d2e3790@mail.gmail.com> Date: Fri, 18 Nov 2005 16:09:27 -0800 From: Steven Schoch Sender: schoch6@gmail.com To: freebsd-pf@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Still have ftp-proxy problems - Any help? 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, 19 Nov 2005 00:09:28 -0000 Am I the only one who can't get active FTP to work over a NAT gateway? I'm starting to tear my hair out on this one. Again, the problem is that the client says: PORT 192,168,1,104,6,226 But ftp-proxy logs: client line buffer is "PORT 192,168,1,104,19,137^M " I may not be the only one with this problem. On Mon, 22 Nov 2004 "J. Martin Petersen" had a similar problem I found in this message: http://docs.freebsd.org/cgi/mid.cgi?1101152753.41a241f113332 But there were no answers. Any new answers? -- Steve From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 00:16:51 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0DB16A420 for ; Sat, 19 Nov 2005 00:16:51 +0000 (GMT) (envelope-from soren3@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868A843D49 for ; Sat, 19 Nov 2005 00:16:50 +0000 (GMT) (envelope-from soren3@gmail.com) Received: by xproxy.gmail.com with SMTP id s8so333344wxc for ; Fri, 18 Nov 2005 16:16:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=A2DgW8w+6RljTAkVv9EDP+11jlYMBLiwJQlhhnS40dRb4f68AKUz4p2uWeO22k2LVPbvAfHl8gVyY4e7q1d/DCu0pLOWUNCPj+I/qrInNjvzQ8hC5UtpBsrOxZfuHvV1eltMhKvgtcAjdlDvQl3zKZ1WFUtSJitaxU63SMSAny4= Received: by 10.65.148.6 with SMTP id a6mr431779qbo; Fri, 18 Nov 2005 16:16:49 -0800 (PST) Received: from vertov.inequality ( [200.165.8.240]) by mx.gmail.com with ESMTP id q17sm217257qbq.2005.11.18.16.16.48; Fri, 18 Nov 2005 16:16:49 -0800 (PST) From: Soren Worach To: freebsd-pf@freebsd.org Date: Fri, 18 Nov 2005 22:19:05 -0200 User-Agent: KMail/1.8.3 References: <437E088F.7080809@wombatsweb.com> <437E38EA.6050409@mantor.org> In-Reply-To: <437E38EA.6050409@mantor.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511182219.05951.soren3@gmail.com> Subject: Re: Best practices for service provider? 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, 19 Nov 2005 00:16:51 -0000 On Friday 18 November 2005 18:26, Danny Fullerrton wrote: > David Pierron wrote: > > This is a loaded question so please bear with me. I could really use > > the advice/help. > > > > I am coming from a FreeBSD 4.9 IPLess IPFW Bridging Firewall ... I > > had followed the directions from the FreeBSD Handbook ... Recently it > > crashed, so I had to rebuild it, uhm ... quickly ... > > > > This time I decided to include a 3rd NIC so that I could get the > > nightly emails and pay a bit better attention to its status ... It is > > working, but giving me some errors about arp: xx:xx:xx:xx:xx:xx is > > using my IP address my.c.class.xx! I have been scouring the Internet > > for information, and I decided to give PF a try ... I installed > > OpenBSD 3.8 but didn't like its CLI interface ... Not that I use a > > GUI, I don't ... I just hop around much better on FreeBSD ... > > > > I drew a picture of what I am envisioning as a firewall solution for > > me here: > > http://www.davidpierron.com/img/net-map.jpg > > > > I installed FreeBSD 6.0 and cvsup'd ports and src ... put the > > following into GENERIC: > > > > # to allow bridge support > > device if_bridge > > > > #PF > > device pf > > device pflog > > device pfsync > > > > #ALTQ > > options ALTQ > > options ALTQ_CBQ # Class Bases Queuing (CBQ) > > options ALTQ_RED # Random Early Detection (RED) > > options ALTQ_RIO # RED In/Out > > options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) > > options ALTQ_PRIQ # Priority Queuing (PRIQ) > > #options ALTQ_NOPCC # Required for SMP build > > > > # other stuff > > options IPSTEALTH > > options HZ=1000 > > > > I put the following into rc.conf: > > > > defaultrouter="my.c.class.1" > > hostname="firewall.foo.org" > > ifconfig_xl0="inet my.c.class.2 netmask 255.255.255.0" > > usbd_enable="NO" > > sendmail_enable="NO" > > > > cloned_interfaces="bridge0" # create a bridge > > ifconfig_bridge0="addm rl0 addm rl1" # set bridge to use particular NICs > > #gateway_enable="YES" > > > > pf_enable="YES" # Enable PF (load module if > > required) > > pf_rules="/etc/pf.conf" # rules definition file for pf > > pf_flags="" # additional flags for pfctl startup > > pflog_enable="YES" # start pflogd(8) > > pflog_logfile="/var/log/pflog" # where pflogd should store the > > logfile > > pflog_flags="" # additional flags for pflogd > > startup > > > > .. and into sysctl.conf: > > > > net.link.bridge.pfil_bridge=1 # enables packet filtering on bridge > > net.link.bridge.pfil_member=1 # enables packet filtering on in and > > out interfaces > > #net.inet.ip.forwarding=1 # instead of gateway_enable in rc.conf? > > > > I am running into one of two things ... Trying to find information > > that isn't widely available yet, or trying to figure this out from old > > posts that don't apply anymore ... The other thing going against me > > is that I haven't seen anything that resembles my setup ... I am not > > running any NAT ... I am using real world routable IP addresses ... I > > am assuming I need a 3rd NIC to be separate from the firewall ... > > You can use firewalled interface or bridge interface as normal interface > too. It's only depending on your config. You'll find lots of stuff on > google refering to a setup like yours but when searching for OpenBSD stuff. > > > From my recent readings of this lists archives, it doesn't seem that I > > would want to run a bridge ... It won't allow me to keep state ... > > If this is the case, how do I not assign the network cards that will > > be doing the filtering no ip address? I tried some interesting > > combinations with ifconfig in rc.conf, but they didn't work ... When > > I thought everything was up and running correctly, I put this box > > between my router and switch but traffic didn't flow ... I could ping > > internally, but could not ping the router's address which is the > > gateway (x.x.x.1) ... I assumed that the internal pinging was working > > on the 3rd NIC with the real IP address ... > > Statefull mode is working in bridge mode using OpenBSD PF. But I dont > known if it's presently the case with the FreeBSD implementation. it _is_ the case, pf supports statefull with bridging. I'm using 6.0 since betaX on a couple of setups like this. > > > My question is, can I use two NICs for PF to do firewalling on to put > > between the router and the switch and then plug the 3rd NIC in and > > have it act as a separate interface on the box, or should I simply use > > 2 NICs and assign them real IP addresses ... If I do that, will > > IPSTEALTH compiled into the kernel not show the presence of the > > filtering? > > As I said, you could use this kind of setup (3 card to keep it simple > logic) or ,while using 2 interface in bridge mode, use 1 of them with an > internal ip address (bridge and standard). > > > I think I have successfully confused myself with redundant or old > > information out there on the 'net, so again ... any suggestions or > > advice on what I am trying to accomplish would be greatly appreciated. please post your pf.conf. > > > > Thank you for reading, > > David Pierron > > _______________________________________________ > > freebsd-pf@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > You should begin by playing with Packet Filter while being in bridge > mode and gradually including feature like the management ip/interface > before going to far and not understanding. > > Danny Fullerton > ---------------------- > IT Security Specialist > dfullerton@mantor.org > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 07:21:53 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 799B416A41F for ; Sat, 19 Nov 2005 07:21:53 +0000 (GMT) (envelope-from nobody@ecn.cz) Received: from ecn4.ecn.cz (ecnd.ecn.cz [62.44.10.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id C075443D49 for ; Sat, 19 Nov 2005 07:21:52 +0000 (GMT) (envelope-from nobody@ecn.cz) Received: from ecn1.ecn.cz (ecna.ecn.cz [62.44.10.7]) by ecn4.ecn.cz (8.12.11/8.12.11) with ESMTP id jAJ7LocN023912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2005 08:21:50 +0100 Received: from ecn1.ecn.cz (ecn1-new [127.0.0.1]) by ecn1.ecn.cz (8.13.1/8.12.8) with ESMTP id jAJ7LjrC008407; Sat, 19 Nov 2005 08:21:45 +0100 Received: (from nobody@localhost) by ecn1.ecn.cz (8.13.1/8.13.1/Submit) id jAJ7Ljc2008404; Sat, 19 Nov 2005 08:21:45 +0100 Date: Sat, 19 Nov 2005 08:21:45 +0100 Message-Id: <200511190721.jAJ7Ljc2008404@ecn1.ecn.cz> To: freebsd-pf@freebsd.org From: Best Postcards X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b3 (ecn4.ecn.cz [62.44.10.8]); Sat, 19 Nov 2005 08:21:50 +0100 (CET) X-Virus-Scanned: ClamAV version 0.87, clamav-milter version 0.87 on ecn8.ecn.cz X-Virus-Status: Clean MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: postcard@postcard.com Subject: You have received an electronic postcard. 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, 19 Nov 2005 07:21:53 -0000 Hello friend ! You have just received a postcard from someone who cares about you! This is a part of the message: "Hy there! It has been a long time since I haven´t heared about you! I´ve just found out about this service from Claire, a friend of mine who also told me that..." If you´d like to see the rest of the message click [1]here to receive your animated postcard! =================== Thank you for using www.postcard1000.com ´s services !!! Please take this opportunity to let your friends hear about us by sending them a postcard from our collection ! ================== References 1. http://www.yourpostcard.home.ro/postcard.gif.exe From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 08:31:08 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB6116A41F for ; Sat, 19 Nov 2005 08:31:08 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0C5E43D45 for ; Sat, 19 Nov 2005 08:31:07 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.12.11) with ESMTP id jAJ8Uj9O005379 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 19 Nov 2005 09:30:45 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jAJ8UbfH032414; Sat, 19 Nov 2005 09:30:37 +0100 (MET) Date: Sat, 19 Nov 2005 09:30:35 +0100 From: Daniel Hartmeier To: Steven Schoch Message-ID: <20051119083035.GB28611@insomnia.benzedrine.cx> References: <6650332b0511181609s1540c083v2faf8f2f6d2e3790@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6650332b0511181609s1540c083v2faf8f2f6d2e3790@mail.gmail.com> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: Still have ftp-proxy problems - Any help? 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, 19 Nov 2005 08:31:08 -0000 On Fri, Nov 18, 2005 at 04:09:27PM -0800, Steven Schoch wrote: > I may not be the only one with this problem. On Mon, 22 Nov 2004 "J. > Martin Petersen" had a similar problem I found in > this message: > http://docs.freebsd.org/cgi/mid.cgi?1101152753.41a241f113332 > > But there were no answers. Any new answers? Depends on whether it's the same problem or not, you didn't supply the same diagnostics. In Martin's case, the problem was that the ftp-proxy couldn't establish the data connection to the client, most likely due to his ruleset. The ftp-proxy sends the TCP SYN to the client, passing by rule pass on $int_if all and not creating state. Then the client's SYN+ACK comes back in on $int_if, passing by rule pass log on $int_if from "10.1.4.50" modulate state here the SYN+ACK does get modulated and create state. This doesn't work. If you want to modulate sequence numbers, you have to do it on the initial SYN (and create state). In short, any ruleset that creates state on non-first packets is highly suspicious. I have no idea why Martin doesn't create state on so many rules, then just throws in a 'modulate state' on that particular rule. In general: a) don't pass without creating state, search for 'pass' rules which don't also have 'keep state' b) don't create state on non-first packets, search for 'pass' rules (applying to TCP connections) which don't contains 'flags S/SA' It could be an entirely different problem in your case. Martin did supply many relevant logs, you could do the same :) Daniel From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 19:10:06 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8F5016A420 for ; Sat, 19 Nov 2005 19:10:06 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: from mail01.bsdmail.net (mail01.bsdmail.net [64.243.181.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id E4D3B43D6E for ; Sat, 19 Nov 2005 19:09:56 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 79494 invoked by uid 89); 19 Nov 2005 19:09:55 -0000 Received: by simscan 1.1.0 ppid: 79488, pid: 79490, t: 3.6746s scanners: attach: 1.1.0 clamav: 0.85.1/m:32/d:941 spam: 3.0.2 Received: from unknown (HELO ?64.243.181.151?) (david@icuhost.net@64.243.181.151) by mail01.bsdmail.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 19 Nov 2005 19:09:51 -0000 Message-ID: <437F7880.708@wombatsweb.com> Date: Sat, 19 Nov 2005 14:09:52 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <437E088F.7080809@wombatsweb.com> <437E38EA.6050409@mantor.org> <200511182219.05951.soren3@gmail.com> In-Reply-To: <200511182219.05951.soren3@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on mail01.bsdmail.net X-Spam-Level: X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: Re: Best practices for service provider? 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, 19 Nov 2005 19:10:07 -0000 Soren Worach on 11/18/2005 7:19 PM wrote: >On Friday 18 November 2005 18:26, Danny Fullerrton wrote: > > >>David Pierron wrote: >> >> >>>This is a loaded question so please bear with me. I could really use >>>the advice/help. >>> >>>I am coming from a FreeBSD 4.9 IPLess IPFW Bridging Firewall ... I >>>had followed the directions from the FreeBSD Handbook ... Recently it >>>crashed, so I had to rebuild it, uhm ... quickly ... >>> >>>This time I decided to include a 3rd NIC so that I could get the >>>nightly emails and pay a bit better attention to its status ... It is >>>working, but giving me some errors about arp: xx:xx:xx:xx:xx:xx is >>>using my IP address my.c.class.xx! I have been scouring the Internet >>>for information, and I decided to give PF a try ... I installed >>>OpenBSD 3.8 but didn't like its CLI interface ... Not that I use a >>>GUI, I don't ... I just hop around much better on FreeBSD ... >>> >>>I drew a picture of what I am envisioning as a firewall solution for >>>me here: >>>http://www.davidpierron.com/img/net-map.jpg >>> >>>I installed FreeBSD 6.0 and cvsup'd ports and src ... put the >>>following into GENERIC: >>> >>># to allow bridge support >>>device if_bridge >>> >>>#PF >>>device pf >>>device pflog >>>device pfsync >>> >>>#ALTQ >>>options ALTQ >>>options ALTQ_CBQ # Class Bases Queuing (CBQ) >>>options ALTQ_RED # Random Early Detection (RED) >>>options ALTQ_RIO # RED In/Out >>>options ALTQ_HFSC # Hierarchical Packet Scheduler (HFSC) >>>options ALTQ_PRIQ # Priority Queuing (PRIQ) >>>#options ALTQ_NOPCC # Required for SMP build >>> >>># other stuff >>>options IPSTEALTH >>>options HZ=1000 >>> >>>I put the following into rc.conf: >>> >>>defaultrouter="my.c.class.1" >>>hostname="firewall.foo.org" >>>ifconfig_xl0="inet my.c.class.2 netmask 255.255.255.0" >>>usbd_enable="NO" >>>sendmail_enable="NO" >>> >>>cloned_interfaces="bridge0" # create a bridge >>>ifconfig_bridge0="addm rl0 addm rl1" # set bridge to use particular NICs >>>#gateway_enable="YES" >>> >>>pf_enable="YES" # Enable PF (load module if >>>required) >>>pf_rules="/etc/pf.conf" # rules definition file for pf >>>pf_flags="" # additional flags for pfctl startup >>>pflog_enable="YES" # start pflogd(8) >>>pflog_logfile="/var/log/pflog" # where pflogd should store the >>>logfile >>>pflog_flags="" # additional flags for pflogd >>>startup >>> >>>.. and into sysctl.conf: >>> >>>net.link.bridge.pfil_bridge=1 # enables packet filtering on bridge >>>net.link.bridge.pfil_member=1 # enables packet filtering on in and >>>out interfaces >>>#net.inet.ip.forwarding=1 # instead of gateway_enable in rc.conf? >>> >>>I am running into one of two things ... Trying to find information >>>that isn't widely available yet, or trying to figure this out from old >>>posts that don't apply anymore ... The other thing going against me >>>is that I haven't seen anything that resembles my setup ... I am not >>>running any NAT ... I am using real world routable IP addresses ... I >>>am assuming I need a 3rd NIC to be separate from the firewall ... >>> >>> >>You can use firewalled interface or bridge interface as normal interface >>too. It's only depending on your config. You'll find lots of stuff on >>google refering to a setup like yours but when searching for OpenBSD stuff. >> >> I have been using Google and searching ... I have not been successful in finding a HOW-TO or something similiar to help me configure this FreeBSD 6.0 machine the way it ought to be configured ... Many sites and spiders of mailing lists are outdated ... As stated above, I want to use FreeBSD for this solution ... >>>From my recent readings of this lists archives, it doesn't seem that I >>>would want to run a bridge ... It won't allow me to keep state ... >>>If this is the case, how do I not assign the network cards that will >>>be doing the filtering no ip address? I tried some interesting >>>combinations with ifconfig in rc.conf, but they didn't work ... When >>>I thought everything was up and running correctly, I put this box >>>between my router and switch but traffic didn't flow ... I could ping >>>internally, but could not ping the router's address which is the >>>gateway (x.x.x.1) ... I assumed that the internal pinging was working >>>on the 3rd NIC with the real IP address ... >>> >>> >>Statefull mode is working in bridge mode using OpenBSD PF. But I dont >>known if it's presently the case with the FreeBSD implementation. >> >> > >it _is_ the case, pf supports statefull with bridging. I'm using 6.0 since >betaX on a couple of setups like this. > > I found messages in this archive only months old that suggest that although state is displayed that it may not be reporting correctly ... these messages were from 12/2004 and Jan/2005, and looking at them again, it's possible that they weren't even talking about if_bridge ... >>>My question is, can I use two NICs for PF to do firewalling on to put >>>between the router and the switch and then plug the 3rd NIC in and >>>have it act as a separate interface on the box, or should I simply use >>>2 NICs and assign them real IP addresses ... If I do that, will >>>IPSTEALTH compiled into the kernel not show the presence of the >>>filtering? >>> >>> >>As I said, you could use this kind of setup (3 card to keep it simple >>logic) or ,while using 2 interface in bridge mode, use 1 of them with an >>internal ip address (bridge and standard). >> >> >> >>>I think I have successfully confused myself with redundant or old >>>information out there on the 'net, so again ... any suggestions or >>>advice on what I am trying to accomplish would be greatly appreciated. >>> >>> > >please post your pf.conf. > > Whoa ... we're not even there yet ... I am trying to get the hardware configured ... I am not clear as to the parameters required for the bridge or the options to allow IP Forwarding across the bridge and keeping the 3rd NIC separate ... I set up a simple pf.conf to block all traffic: scrub in all block out log on $ext_if all block in log on $ext_if all I saw no activity logged at all when I attached cables from the router and then to the switch ... >>>Thank you for reading, >>>David Pierron >>>_______________________________________________ >>> >>> >>You should begin by playing with Packet Filter while being in bridge >>mode and gradually including feature like the management ip/interface >>before going to far and not understanding. >> >>Danny Fullerton >> >> I think my initial problem when installing the 3 NICs and giving one an IP address is that they all use the default gateway ... Do I need to install the gateway just to the 3rd NIC somehow? (which I would call the management NIC) ... Should I remove "defaultrouter="x.x.x.1"" from rc.conf? I would have thought the bridge would live in his own space ... The bridge just needs to filter packets not caring about its own IP addresses ... I would be able to deny or throttle by destination IP, but the bridge itself should see traffic coming in, filter it based on the rules, and then pass it on if okay or drop it if not okay ... The outside world wouldn't know that there was an extra hardware appliance hop to their destination ... The assumption in using 3 NICs is that FreeBSD will run an IPLess stateful packet filter on the 2 NIC bridge, the 3rd NIC's traffic will eventually travel across that bridge as shown in the diagram I drew ... This has to be possible, but there must be some trick to it that I haven't grasped ... Not many setups or HOWTOs explain this sort of setup or idea ... Maybe I should have asked one question at a time? I just thought this was all encompassing ... the hardware setup supporting the PF machine ... David Pierron From owner-freebsd-pf@FreeBSD.ORG Sat Nov 19 19:51:57 2005 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47B5D16A41F for ; Sat, 19 Nov 2005 19:51:57 +0000 (GMT) (envelope-from brunotm@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD19C43D45 for ; Sat, 19 Nov 2005 19:51:56 +0000 (GMT) (envelope-from brunotm@gmail.com) Received: by xproxy.gmail.com with SMTP id t16so402202wxc for ; Sat, 19 Nov 2005 11:51:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=A+nWNQ91mjYZuUOvvM10c87i++VN3F6DhnTHC7lK2Js7VZWqF7GMECJbRGjknyRVQw5/xCngigVcVOlFUXQuGWz4SLFtrfJBYPOrRrY+AXyGil8RsvHGlY4F/RP6ZXLsMKHjDH6+RXJlxqkESfxqYc7RAOaWAddbiax/ObuprIw= Received: by 10.65.105.2 with SMTP id h2mr1061569qbm; Sat, 19 Nov 2005 11:51:55 -0800 (PST) Received: from vertov.inequality ( [200.165.8.240]) by mx.gmail.com with ESMTP id f12sm1901531qba.2005.11.19.11.51.53; Sat, 19 Nov 2005 11:51:54 -0800 (PST) From: Bruno Tavares To: freebsd-pf@freebsd.org Date: Sat, 19 Nov 2005 17:54:11 -0200 User-Agent: KMail/1.8.3 References: <437E088F.7080809@wombatsweb.com> <200511182219.05951.soren3@gmail.com> <437F7880.708@wombatsweb.com> In-Reply-To: <437F7880.708@wombatsweb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200511191754.12254.brunotm@gmail.com> Subject: Re: Best practices for service provider? 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, 19 Nov 2005 19:51:57 -0000 On Saturday 19 November 2005 17:09, David Pierron wrote: > Whoa ... we're not even there yet ... I am trying to get the hardware > configured ... I am not clear as to the parameters required for the > bridge or the options to allow IP Forwarding across the bridge and > keeping the 3rd NIC separate ... I set up a simple pf.conf to block all > traffic: > > scrub in all > block out log on $ext_if all > block in log on $ext_if all > > I saw no activity logged at all when I attached cables from the router > and then to the switch ... The 3rd interface will do nothing within the bridge(they will bridge the traffic only between themselves ) try passing traffic on all bridge interfaces (including bridge0) by default and check what address the bridge have learned with `ifconfig addr bridge0` > > I think my initial problem when installing the 3 NICs and giving one an > IP address is that they all use the default gateway ... Do I need to > install the gateway just to the 3rd NIC somehow? (which I would call the > management NIC) ... Should I remove "defaultrouter="x.x.x.1"" from > rc.conf? I would have thought the bridge would live in his own space ... the bridging interfaces will only touch that if you give them ip addresses, which you don't need to since you have a 3rd interface for management. > > The bridge just needs to filter packets not caring about its own IP > addresses ... I would be able to deny or throttle by destination IP, > but the bridge itself should see traffic coming in, filter it based on > the rules, and then pass it on if okay or drop it if not okay ... The > outside world wouldn't know that there was an extra hardware appliance > hop to their destination ... > > The assumption in using 3 NICs is that FreeBSD will run an IPLess > stateful packet filter on the 2 NIC bridge, the 3rd NIC's traffic will > eventually travel across that bridge as shown in the diagram I drew ... > This has to be possible, but there must be some trick to it that I > haven't grasped ... Not many setups or HOWTOs explain this sort of setup > or idea ... > > Maybe I should have asked one question at a time? I just thought this > was all encompassing ... the hardware setup supporting the PF machine ... > The assumption is correct. don't forget to add a rule pass for the 3rd interface like: pass quick from self keep state or pass quick from $3rd_nic keep state > David Pierron > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"