From owner-freebsd-pf@FreeBSD.ORG Sun Dec 11 00:17:18 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 5ABE216A41F for ; Sun, 11 Dec 2005 00:17:18 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 7F34543D4C for ; Sun, 11 Dec 2005 00:17:17 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 92826 invoked by uid 89); 11 Dec 2005 00:16:57 -0000 Received: from link.warped.ro (HELO warped) (86.104.83.83) by warped.ro with SMTP; 11 Dec 2005 00:16:57 -0000 Message-ID: <005f01c5fde8$41c385e0$53536856@warped> From: "Robert" To: Date: Sun, 11 Dec 2005 02:17:22 +0200 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DIOCADDALTQ: Cannot allocate memory X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 00:17:18 -0000 this is my problem i have 80 clients in the home256 queue this is how my pf.conf looks i have 1GB RAM and 3Ghz P4 pfctl: DIOCADDALTQ: Cannot allocate memory cam asa arata pful altq on $int_if hfsc bandwidth 100Mb queue { default, manager, home256 } queue default bandwidth 8Kb hfsc(default) queue manager bandwidth 30Mb hfsc { 212.2_lp_cat, 212.5_tgvadm, = 213.66_cas, 212.4_laliv } queue home256 bandwidth 30Mb hfsc { mim_212.11, ri_212.12, ni_212.13, = sa_212.130, sb_212.131, bm ...... } queue 212.2_lp_cat bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 212.5_tgvadm bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 213.66_cas bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 212.4_laliv bandwidth 128Kb hfsc ( upperlimit 512Kb ) ## HOME queue queue mim_212.11 bandwidth 8Kb hfsc ( upperlimit 256Kb ) queue ri_212.12 bandwidth 8Kb hfsc ( upperlimit 256Kb ) queue ni_212.13 bandwidth 8Kb hfsc ( upperlimit 256Kb ) si passurile=20 pass out on $int_if from any to 86.107.212.11 queue mim_212.11 pass out on $int_if from any to 86.107.212.12 queue ri_212.12 pass out on $int_if from any to 86.107.212.13 queue ni_212.13 From owner-freebsd-pf@FreeBSD.ORG Sun Dec 11 00:20: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 31FC516A420 for ; Sun, 11 Dec 2005 00:20:57 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 2162043D5D for ; Sun, 11 Dec 2005 00:20:55 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 92921 invoked by uid 89); 11 Dec 2005 00:20:37 -0000 Received: from link.warped.ro (HELO warped) (86.104.83.83) by warped.ro with SMTP; 11 Dec 2005 00:20:37 -0000 Message-ID: <006601c5fde8$c4c10030$53536856@warped> From: "Robert" To: Date: Sun, 11 Dec 2005 02:21:02 +0200 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: DIOCADDALTQ: Cannot allocate memory X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 00:20:57 -0000 this is what i get when i try to start pf in the home256 queue i have 80 clients i have 1GB RAM and a 3Ghz processor pfctl: DIOCADDALTQ: Cannot allocate memory cam asa arata pful altq on $int_if hfsc bandwidth 100Mb queue { default, manager, home256 } queue default bandwidth 8Kb hfsc(default) queue manager bandwidth 30Mb hfsc { 212.2_lp_cat, 212.5_tgvadm, = 213.66_cas, 212.4_laliv } queue home256 bandwidth 30Mb hfsc { mim_212.11, ri_212.12, ni_212.13, = sa_212.130, sb_212.131, bm ...... } queue 212.2_lp_cat bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 212.5_tgvadm bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 213.66_cas bandwidth 128Kb hfsc ( upperlimit 512Kb ) queue 212.4_laliv bandwidth 128Kb hfsc ( upperlimit 512Kb ) ## HOME queue queue mim_212.11 bandwidth 8Kb hfsc ( upperlimit 256Kb ) queue ri_212.12 bandwidth 8Kb hfsc ( upperlimit 256Kb ) queue ni_212.13 bandwidth 8Kb hfsc ( upperlimit 256Kb ) si passurile=20 pass out on $int_if from any to 86.107.212.11 queue mim_212.11 pass out on $int_if from any to 86.107.212.12 queue ri_212.12 pass out on $int_if from any to 86.107.212.13 queue ni_212.13 From owner-freebsd-pf@FreeBSD.ORG Sun Dec 11 07:18:21 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 8F52A16A41F for ; Sun, 11 Dec 2005 07:18:21 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C6EE43D5D for ; Sun, 11 Dec 2005 07:18:20 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1535110wri for ; Sat, 10 Dec 2005 23:18:20 -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=YT7HgcXQRTwzN6y87IX6dECPWv+I8EXwdG4jnqbRGgvjJyv/xcYCIT54nRGjzRCIC3Zug0LHxVOYD4yaEAnFoNR/Hzmf7f7jlBuQ37bxyWf6RnW54f+nwdBUNoqGQR4W4mwlqu+kcIxSF42YDTDoBi+zqEMpZWpL0kR1MCAChL4= Received: by 10.54.139.13 with SMTP id m13mr7706782wrd; Sat, 10 Dec 2005 23:18:20 -0800 (PST) Received: by 10.54.78.20 with HTTP; Sat, 10 Dec 2005 23:18:20 -0800 (PST) Message-ID: Date: Sun, 11 Dec 2005 01:18:20 -0600 From: "Travis H." To: Greg Hennessy In-Reply-To: <000b01c5fd11$848a88b0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439A0048.3030106@forrie.com> <000b01c5fd11$848a88b0$0a00a8c0@thebeast> Cc: Forrest Aldrich , freebsd-pf@freebsd.org Subject: Re: Syntax errors in pf.conf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 07:18:21 -0000 > Yes, the BNF at the bottom of the pf.conf man page. Or "pfctl -n". -- http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus "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 Sun Dec 11 07:41:18 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 E1FA616A41F for ; Sun, 11 Dec 2005 07:41:17 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6ACFC43D58 for ; Sun, 11 Dec 2005 07:41:17 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id 67so1545345wri for ; Sat, 10 Dec 2005 23:41:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=DQ8uUiOMiMhovqe3dwAH1mUHe6rfzfjbQo1cv1NBKaCmiKfzyr2AigmD6gtkcKuvOCBMqRVeiVllMwm2Mpqdf6qQhCYQm5SYXJ1oazd4Z89IR0YFdPCVR61HchFqJdmFzC8d95spjMZQZ25ARIFQK3c6aDQuBwW6sIAE6u+RkeA= Received: by 10.54.119.3 with SMTP id r3mr7708651wrc; Sat, 10 Dec 2005 23:41:16 -0800 (PST) Received: by 10.54.78.20 with HTTP; Sat, 10 Dec 2005 23:41:16 -0800 (PST) Message-ID: Date: Sun, 11 Dec 2005 01:41:16 -0600 From: "Travis H." To: freebsd-pf@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Re: Firewall concepts X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 07:41:18 -0000 On 12/8/05, Marcus Franke wrote: > > A firewall on every pc will soon become a nightmare to manage as the > > network grows. Not necessarily. If the needs of the machines do not change, then there is no change to manage. Your pf rules, in theory, can be quite simple, and adjustments can be made on an as-needed basis. The main problem comes when they need to offer some kind of service that requires inbound connections, such as traditional servers, some multimedia and p2p protocols. The question is, are those changes going to be applied to all machines, or just one at a time? If the former, than having a global, shared ruleset is the way to go. If the latter, then having an independent per-machine configuration file is the way to go. You can even implement a middle ground by use of anchors or textual inclusion using some kind of preprocessor (email me if you want a copy of one). > Concerning the manageability I would say, yes, you are right. One > should invent a solution like the manageability of WinXP SP2 with > the help of the ActiveDirectory in a windows server domain. *shudders* I've never been exactly sure what problem "the registry" or "active directory" solves. The former is a hierarchical namespace containing configuration information, which sounds like a filesystem to me. What program variables are considered "configurable" seems somewhat arbitrary. Can you explain what problem ActiveDirectory solves? I'm willing to bet if you can tell me the requirements, I can point you to an open-source solution. There is something called OpenLDAP... > But, often you read that attacks against servers will be done from > the inside network. Indeed, a firewall on every machine is the only way to implement the "principle of least privilege" in many cases. Trying to centralize access control on one firewall machine is a useful idiom, but can become challenging as the links to "untrusted" networks increases, for example when some internal user installs a modem or WAP. Now the outside world has equivalent access to what was a trusted insider. Furthermore, having a single firewall provides a single point of failure; if it dies, no packets flow. And other issues can combine to make a centralized gateway impractical. For most users bandwidth of the firewall isn't an issue, but a single full-duplex gigiabit ethernet link can saturate a 32-bit 33MHz PCI bus to capacity. In reality you can start seeing dropped packets as low as 200-300Mbps, and without selective acknowledgements the performance of TCP really suffers in the face of dropped packets. If increasing bandwidth doesn't do it, end-to-end encryption with be the death knoll of a centralized firewall or NIDS system, as the ports used and application data will be unavailable to any system in the middle (unless of course all systems escrow their keys with the firewall or gateway, which is complex and problematic and defeats the purpose of end-to-end encryption). -- http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus "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 Sun Dec 11 07:47:18 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 0845416A41F for ; Sun, 11 Dec 2005 07:47:18 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C7A143D60 for ; Sun, 11 Dec 2005 07:47:17 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id i11so1543868wra for ; Sat, 10 Dec 2005 23:47:17 -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=fPztOEQJGadmCpk60fCZO7VIm5Uj788HExvxzzUzOVX1yMzGdCA0ODs9+bFyb10kuTllHYpA9L1V5f0cXYQ4FklfdO4uqgZk0JSeF4SC6J7w2mp24XOOyi8S3kuDIMQgalkPuAkIwVKJ1Neaxi4X6OOpMtRXT9xF9ZY+Jp8IrF0= Received: by 10.54.129.12 with SMTP id b12mr7747735wrd; Sat, 10 Dec 2005 23:47:16 -0800 (PST) Received: by 10.54.78.20 with HTTP; Sat, 10 Dec 2005 23:47:16 -0800 (PST) Message-ID: Date: Sun, 11 Dec 2005 01:47:16 -0600 From: "Travis H." To: =?ISO-8859-1?Q?Javier_Andr=E9s?= In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-pf@freebsd.org Subject: Re: Help 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: Sun, 11 Dec 2005 07:47:18 -0000 Please provide the output of "pfctl -s all" when the host is acting problematic and I'll do what I can to help. -- http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus "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 Sun Dec 11 11:18:54 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 E7EC616A41F for ; Sun, 11 Dec 2005 11:18:54 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48E4D43D8F for ; Sun, 11 Dec 2005 11:18:53 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id i14so1526604wra for ; Sun, 11 Dec 2005 03:18:52 -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=SzJ/0gbm1GSecBtfJwVUzzJAAnmikqWTDrOjLhzd8GNODpZJDnShTaani0oT5wo+GGXtjMqfn0ZYIcFF1Lf+llGKgSejBqZgoMo8h0mlhvqs/IKTBGLt0QOHCxE2BHFsZQkfzeSMuSDCs+GtKUvD0AMcV7jgXtfMSZGBM08dl2o= Received: by 10.54.133.7 with SMTP id g7mr1502167wrd; Sun, 11 Dec 2005 03:18:52 -0800 (PST) Received: by 10.54.78.20 with HTTP; Sun, 11 Dec 2005 03:18:52 -0800 (PST) Message-ID: Date: Sun, 11 Dec 2005 05:18:52 -0600 From: "Travis H." To: yayj In-Reply-To: <439A5545.1090308@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439A5545.1090308@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: My problem of pf rule X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 11:18:55 -0000 > let's put aside the subnet routing env.s the int are in and the routing > table of host is like this, if the dest IP of packet is in then > it's forwarded to em0, if is in then em1. I turn on NAT on em0. > > there are two questions left: > 1. I wanna employ a flow control for the two fxp int on em0 other than. > cuz NAT is applying on em0, I can't describe the flow of the two fxp int > using 'on em0' respectively. I describe them on their source int like thi= s: > > pass in on fxp0 inet from to queue queue0 > pass in on fxp0 inet from to queue queue1 What's "a flow control"? I don't see why you can't specify "on em0", even when NAT is in use. > 2. The host itself may also send data by em0 using the IP of em0, how > can I describe this flow? Using cbq(default) or whatever? How about: pass out on em0 from (em0) to any This notation for use with dynamic IPs is described in the FAQ: http://www.openbsd.org/faq/pf/ -- http://www.lightconsulting.com/~travis/ -><- Knight of the Lambda Calculus "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 Sun Dec 11 13:27: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 E848F16A41F for ; Sun, 11 Dec 2005 13:27:44 +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 1901943D81 for ; Sun, 11 Dec 2005 13:27:29 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 84834 invoked by uid 89); 11 Dec 2005 13:27:27 -0000 Received: by simscan 1.1.0 ppid: 84828, pid: 84830, t: 1.2825s 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; 11 Dec 2005 13:27:26 -0000 Message-ID: <439C293E.8050500@wombatsweb.com> Date: Sun, 11 Dec 2005 08:27:26 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <20051211.073952.74741466.yamamoto436@oki.com> In-Reply-To: <20051211.073952.74741466.yamamoto436@oki.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.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: Re: if_bridge + altq (CBQ) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 13:27:45 -0000 Hideki Yamamoto on 12/10/2005 5:39 PM wrote: >I am trying the packect shaping by CBQ of altq on FBSD6 box. The box is configured as bridge by if_bridge kernel configuration. The target packet is UDP on IPv6. Though I wrote output port number of the udp packet on /etc/services and wrote CBQ shaping rule on /etc/pf.conf, the shaping rule about each port number are not applied to the packet, so only default rule are applied. > >My question is: can pf especially altq work with bridge function? If so, which bridge function, BRIDGE, if_bridge, ng_brige, is OK? > I am running if_bridge on FBSD 6.0 and have successfully run CBQ and HFSC on the bridge ... Do you have: net.link.bridge.pfil_member=1 # enables packet filtering on in and out interfaces specified in /etc/sysctl.conf? It's quite possible this is necessary for ALTQ to access the "out" on the $xx_if of the bridge ... Keep in mind that if you use the queue on a "pass" rule, ALTQ will apply to the "out" of that rule ... HTH From owner-freebsd-pf@FreeBSD.ORG Sun Dec 11 14:31:16 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 1699916A422 for ; Sun, 11 Dec 2005 14:31:16 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 218A343D7C for ; Sun, 11 Dec 2005 14:31:05 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id XAA22893 for ; Sun, 11 Dec 2005 23:31:02 +0900 Received: (qmail 11732 invoked from network); 11 Dec 2005 23:31:02 +0900 Received: from tulip.bmc.oki.co.jp (172.19.236.119) by aoi.bmc.oki.co.jp with SMTP; 11 Dec 2005 23:31:02 +0900 Received: from localhost (tulip.bmc.oki.co.jp [172.19.236.119]) by tulip.bmc.oki.co.jp (8.13.4/8.13.3) with ESMTP id jBBEV1gp014248; Sun, 11 Dec 2005 23:31:01 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Sun, 11 Dec 2005 23:31:01 +0900 (JST) Message-Id: <20051211.233101.98871433.yamamoto436@oki.com> To: david@wombatsweb.com From: Hideki Yamamoto In-Reply-To: <439C293E.8050500@wombatsweb.com> References: <20051211.073952.74741466.yamamoto436@oki.com> <439C293E.8050500@wombatsweb.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: if_bridge + altq (CBQ) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 14:31:16 -0000 Dear David, Thank you for your reply. After sending my question to ML, I have found that I did not write "pass .... queue ... " on /etc/pf.conf. I had written the port definitions for queue in /etc/services instead of /etc/pf.conf. As it is Sunday today, I will try your suggestion tomorrow. Regards, Hideki Yamamoto From: David Pierron Subject: Re: if_bridge + altq (CBQ) Date: Sun, 11 Dec 2005 08:27:26 -0500 Message-ID: <439C293E.8050500@wombatsweb.com> > Hideki Yamamoto on 12/10/2005 5:39 PM wrote: > > >I am trying the packect shaping by CBQ of altq on FBSD6 box. The box is configured as bridge by if_bridge kernel configuration. The target packet is UDP on IPv6. Though I wrote output port number of the udp packet on /etc/services and wrote CBQ shaping rule on /etc/pf.conf, the shaping rule about each port number are not applied to the packet, so only default rule are applied. > > > >My question is: can pf especially altq work with bridge function? If so, which bridge function, BRIDGE, if_bridge, ng_brige, is OK? > > > I am running if_bridge on FBSD 6.0 and have successfully run CBQ and > HFSC on the bridge ... > > Do you have: > > net.link.bridge.pfil_member=1 # enables packet filtering on in and out interfaces > > specified in /etc/sysctl.conf? It's quite possible this is necessary for ALTQ to access the "out" on the $xx_if of the bridge ... > > Keep in mind that if you use the queue on a "pass" rule, ALTQ will apply to the "out" of that rule ... > > HTH > > > _______________________________________________ > 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 Sun Dec 11 18:28:56 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 EB7D216A41F for ; Sun, 11 Dec 2005 18:28:55 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18E0343D67 for ; Sun, 11 Dec 2005 18:28:54 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id DAA10127 for ; Mon, 12 Dec 2005 03:28:52 +0900 Received: (qmail 14527 invoked from network); 12 Dec 2005 03:28:51 +0900 Received: from tulip.bmc.oki.co.jp (172.19.236.119) by aoi.bmc.oki.co.jp with SMTP; 12 Dec 2005 03:28:51 +0900 Received: from localhost (tulip.bmc.oki.co.jp [172.19.236.119]) by tulip.bmc.oki.co.jp (8.13.4/8.13.3) with ESMTP id jBBISnYP014904; Mon, 12 Dec 2005 03:28:50 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Mon, 12 Dec 2005 03:28:49 +0900 (JST) Message-Id: <20051212.032849.74738118.yamamoto436@oki.com> To: david@wombatsweb.com From: Hideki Yamamoto In-Reply-To: <20051211.233101.98871433.yamamoto436@oki.com> References: <20051211.073952.74741466.yamamoto436@oki.com> <439C293E.8050500@wombatsweb.com> <20051211.233101.98871433.yamamoto436@oki.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: if_bridge + altq (CBQ) X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2005 18:28:56 -0000 Dear Davide and others, I have one question about PF for IPv6. On the manual page of pf.conf, the following sentence appears: Currently, only IPv4 fragments are supported and IPv6 fragments are blocked unconditionally. However in the source tree, it seems that IPv6 fragment may be supported. I wonder if anyone knows IPv6 fragment packet are supported or not. Regards, Hideki Yamamoto From: Hideki Yamamoto Subject: Re: if_bridge + altq (CBQ) Date: Sun, 11 Dec 2005 23:31:01 +0900 (JST) Message-ID: <20051211.233101.98871433.yamamoto436@oki.com> > > Dear David, > > Thank you for your reply. After sending my question to ML, I have > found that I did not write "pass .... queue ... " on /etc/pf.conf. > I had written the port definitions for queue in /etc/services instead > of /etc/pf.conf. As it is Sunday today, I will try your suggestion > tomorrow. > > Regards, > > Hideki Yamamoto > > > From: David Pierron > Subject: Re: if_bridge + altq (CBQ) > Date: Sun, 11 Dec 2005 08:27:26 -0500 > Message-ID: <439C293E.8050500@wombatsweb.com> > > > Hideki Yamamoto on 12/10/2005 5:39 PM wrote: > > > > >I am trying the packect shaping by CBQ of altq on FBSD6 box. The box is configured as bridge by if_bridge kernel configuration. The target packet is UDP on IPv6. Though I wrote output port number of the udp packet on /etc/services and wrote CBQ shaping rule on /etc/pf.conf, the shaping rule about each port number are not applied to the packet, so only default rule are applied. > > > > > >My question is: can pf especially altq work with bridge function? If so, which bridge function, BRIDGE, if_bridge, ng_brige, is OK? > > > > > I am running if_bridge on FBSD 6.0 and have successfully run CBQ and > > HFSC on the bridge ... > > > > Do you have: > > > > net.link.bridge.pfil_member=1 # enables packet filtering on in and out interfaces > > > > specified in /etc/sysctl.conf? It's quite possible this is necessary for ALTQ to access the "out" on the $xx_if of the bridge ... > > > > Keep in mind that if you use the queue on a "pass" rule, ALTQ will apply to the "out" of that rule ... > > > > HTH > > > > > > _______________________________________________ > > 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" > _______________________________________________ > 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 Mon Dec 12 03:59: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 DF0B716A41F for ; Mon, 12 Dec 2005 03:59:49 +0000 (GMT) (envelope-from yayjsir@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D644543D49 for ; Mon, 12 Dec 2005 03:59:48 +0000 (GMT) (envelope-from yayjsir@gmail.com) Received: by zproxy.gmail.com with SMTP id v1so1375590nzb for ; Sun, 11 Dec 2005 19:59:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S+7nmdloKklzYiK+0VIii7QFXUAbnPt6B/bOAetvJyLU/6VyOjHJ08XH9Ol4wZcqVgYZuNep+YunSgX7CxObUlZ8SNvML8UltQcTA6efwtwfw0xQAIj6bce0rMG24F0o77xSv3H6BvNlV9vOAhu8VmnO76zZgeuFRl2MB6ChXAA= Received: by 10.36.39.18 with SMTP id m18mr2481070nzm; Sun, 11 Dec 2005 19:59:48 -0800 (PST) Received: from ?211.83.98.3? ( [220.166.213.4]) by mx.gmail.com with ESMTP id j4sm3765897nzd.2005.12.11.19.59.44; Sun, 11 Dec 2005 19:59:48 -0800 (PST) Message-ID: <439CF5CB.6030207@gmail.com> Date: Mon, 12 Dec 2005 12:00:11 +0800 From: yayj User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: zh-cn,zh MIME-Version: 1.0 To: "Travis H." , freebsd-pf@freebsd.org References: <439A5545.1090308@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Subject: Re: My problem of pf rule 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, 12 Dec 2005 03:59:50 -0000 Travis H. 写道: >>let's put aside the subnet routing env.s the int are in and the routing >>table of host is like this, if the dest IP of packet is in then >>it's forwarded to em0, if is in then em1. I turn on NAT on em0. >> >>there are two questions left: >>1. I wanna employ a flow control for the two fxp int on em0 other than. >>cuz NAT is applying on em0, I can't describe the flow of the two fxp int >>using 'on em0' respectively. I describe them on their source int like this: >> >>pass in on fxp0 inet from to queue queue0 >>pass in on fxp0 inet from to queue queue1 >> > >What's "a flow control"? I don't see why you can't specify "on em0", >even when NAT is in use. > > sorry, I made a mistake here. that means "traffic shaping". the src ip of all packets outgoing em0 is (em0).pf_faq says that. >>2. The host itself may also send data by em0 using the IP of em0, how >>can I describe this flow? Using cbq(default) or whatever? >> > >How about: >pass out on em0 from (em0) to any > > you mean "pass out on em0 from (em0) to any queue qself"? that's not working. all packets attempting to go out via em0 have the same src ip, (em0), including these from and . From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 04:06:10 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 E6F3B16A41F for ; Mon, 12 Dec 2005 04:06:10 +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 5EACC43D49 for ; Mon, 12 Dec 2005 04:06:10 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id 58so2005307wri for ; Sun, 11 Dec 2005 20:06:09 -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=hdiF72+qWifcaMCEuohOXQ4u3BTlmgQ5hRl8vSwWclIyAp1YLPCTTgcDS9fAIscxYZGSK0tm1oG6A4N4nEqmQY9bd/dyWi1mNnK5sram+okzpFwITiak7DrQcUu6vUOXESplFXL9AQNLcUXAG6jq5vxy1rL8wRwjwFYSbnPA6mE= Received: by 10.54.91.3 with SMTP id o3mr224565wrb; Sun, 11 Dec 2005 20:06:06 -0800 (PST) Received: by 10.54.78.20 with HTTP; Sun, 11 Dec 2005 20:06:06 -0800 (PST) Message-ID: Date: Sun, 11 Dec 2005 22:06:06 -0600 From: "Travis H." To: yayj In-Reply-To: <439CF5CB.6030207@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <439A5545.1090308@gmail.com> <439CF5CB.6030207@gmail.com> Cc: freebsd-pf@freebsd.org Subject: Re: My problem of pf rule 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, 12 Dec 2005 04:06:11 -0000 On 12/11/05, yayj wrote: > all packets attempting to go out via em0 have the same src ip, (em0), > including these from and . Oh, I think I understand now. I believe this may be a case where you want to use policy-based routing; in this case you can tag packets from fxp0 and fxp1 to have "tag foo" and perhaps you might be able to say: pass in on { fxp0 fxp1} tag FOO pass out on em0 to any not tagged FOO queue BAR I'm not sure if you can say "not tagged FOO" though, and I cannot test that= . In any case, you are right, NAT occurs first and so all outbound packets will have an IP of (em0) when they are leaving. The only way that I know of to distinguish where they came from is with tags. -- http://www.lightconsulting.com/~travis/ -><- P=3DNP if (P=3D0 or N=3D1) "My love for mathematics is unto 1/x as x approaches 0." GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 06:48:17 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 EDFD216A41F for ; Mon, 12 Dec 2005 06:48:17 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 805B043D53 for ; Mon, 12 Dec 2005 06:48:15 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from weirdo by tehran.lain.pl with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1ElhTm-0003vG-8o for freebsd-pf@freebsd.org; Mon, 12 Dec 2005 07:48:10 +0100 Date: Mon, 12 Dec 2005 07:48:10 +0100 From: Stanislaw Halik To: freebsd-pf@freebsd.org Message-ID: <20051212064809.GA15058@tehran.lain.pl> References: <005f01c5fde8$41c385e0$53536856@warped> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Kj7319i9nmIyA2yE" Content-Disposition: inline In-Reply-To: <005f01c5fde8$41c385e0$53536856@warped> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Subject: Re: DIOCADDALTQ: Cannot allocate memory 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, 12 Dec 2005 06:48:18 -0000 --Kj7319i9nmIyA2yE Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Robert wrote: > this is my problem i have 80 clients in the home256 queue > this is how my pf.conf looks > i have 1GB RAM > and 3Ghz P4 queue limit is static, you have to change it in altq_hfsc.h: #define HFSC_MAX_CLASSES 64 just define it to a higher value and recompile your kernel. --=20 Stanis=B3aw Halik, http://tehran.lain.pl --Kj7319i9nmIyA2yE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDnR0padU+vjT62TERAg+YAJ90ma2De9FRdUNVGpxCOkGcUGbIfwCdFDMu bTLlQ5RnjXs4Jga/1k6i5FE= =y34Z -----END PGP SIGNATURE----- --Kj7319i9nmIyA2yE-- From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 07:10:09 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 44A6316A41F for ; Mon, 12 Dec 2005 07:10:09 +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 0AB3A43D45 for ; Mon, 12 Dec 2005 07:10:09 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBC7A6ug045786 for ; Mon, 12 Dec 2005 07:10:06 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBC7A6hH045785; Mon, 12 Dec 2005 07:10:06 GMT (envelope-from gnats) Date: Mon, 12 Dec 2005 07:10:06 GMT Message-Id: <200512120710.jBC7A6hH045785@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= Cc: Subject: Re: kern/90148: [pf] pf_enable="YES" -> Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= 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, 12 Dec 2005 07:10:09 -0000 The following reply was made to PR kern/90148; it has been noted by GNATS. From: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= To: bug-followup@FreeBSD.org, =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= Cc: Subject: Re: kern/90148: [pf] pf_enable="YES" -> Fatal trap 12: page fault while in kernel mode Date: Mon, 12 Dec 2005 08:08:47 +0100 OK, I was too fast: It is not pf, it IS if_bridge.ko That Machnine also Panics with ipfw loaded. I disabled if_bridge and enabled ng_bridge. Now everything ist fine =20 (I hope:-)) --=20 kommunity GmbH & Co.KG Tom M=FCller-Kortkamp Netzwerke & Internet Goseriede 4 D-30159 Hannover Phone +49 (0)5 11 - 80 72 58 0 Fax +49 (0)5 11 - 80 72 58 10 http://www.kommunity.net From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 08:20:09 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 3169916A41F for ; Mon, 12 Dec 2005 08:20:09 +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 8EFB243D5D for ; Mon, 12 Dec 2005 08:20:08 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBC8K7ov052217 for ; Mon, 12 Dec 2005 08:20:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBC8K7di052216; Mon, 12 Dec 2005 08:20:07 GMT (envelope-from gnats) Date: Mon, 12 Dec 2005 08:20:07 GMT Message-Id: <200512120820.jBC8K7di052216@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= Cc: Subject: Re: misc/90148: pf_enable="YES" -> Fatal trap 12: page fault while in kernel mode X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= 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, 12 Dec 2005 08:20:09 -0000 The following reply was made to PR kern/90148; it has been noted by GNATS. From: =?ISO-8859-1?Q?Tom_M=FCller-Kortkamp?= To: Kris Kennaway Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: misc/90148: pf_enable="YES" -> Fatal trap 12: page fault while in kernel mode Date: Mon, 12 Dec 2005 09:11:20 +0100 Am 09.12.2005 um 19:12 schrieb Kris Kennaway: > On Fri, Dec 09, 2005 at 04:07:03PM +0000, Tom Mller-Kortkamp wrote: >> >>> Number: 90148 >>> Category: misc >>> Synopsis: pf_enable=3D"YES" -> Fatal trap 12: page fault =20 >>> while in kernel mode >>> Confidential: no >>> Severity: non-critical >>> Priority: low >>> Responsible: freebsd-bugs >>> State: open >>> Quarter: >>> Keywords: >>> Date-Required: >>> Class: sw-bug >>> Submitter-Id: current-users >>> Arrival-Date: Fri Dec 09 16:10:03 GMT 2005 >>> Closed-Date: >>> Last-Modified: >>> Originator: Tom M=FCller-Kortkamp >>> Release: FreeBSD 6.0-RELEASE #0 >>> Organization: >> komm://unity >>> Environment: >> FreeBSD durandal.kommunity.net 6.0-RELEASE FreeBSD 6.0-RELEASE #0: =20= >> Thu Nov 3 09:36:13 UTC 2005 root@x64.samsco.home:/usr/obj/usr/=20= >> src/sys/GENERIC i386 >> >>> Description: >> When I enable "pf_enable=3D"YES"" in /etc/rc.conf (no matter if pf =20= >> Module is loaded in Kernel or not) > > It sounds like your pf module is out of sync with your kernel. Can > you confirm they were built from the same sources? > > Kris Hi Kis Sorry for going round this: This was a fresh install with "mini_boot" =20= CD-Image and one of the German mirrors (something like =20 ftp3.de.freebsd.org) I Used "minimal System" in sysinstall. --=20 kommunity GmbH & Co.KG Tom M=FCller-Kortkamp Netzwerke & Internet Goseriede 4 D-30159 Hannover Phone +49 (0)5 11 - 80 72 58 0 Fax +49 (0)5 11 - 80 72 58 10 http://www.kommunity.net From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 10:08: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 C91B316A41F for ; Mon, 12 Dec 2005 10:08:53 +0000 (GMT) (envelope-from thecoba@gmail.com) Received: from dragon.relcom.ru (relay1.relcom.ru [194.220.212.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id E32A343D60 for ; Mon, 12 Dec 2005 10:08:52 +0000 (GMT) (envelope-from thecoba@gmail.com) Received: from [192.168.20.52] (direct.severen.ru [195.95.201.5]) by dragon.relcom.ru with esmtpsa (encrypted) id 1Elkal-000Npm-7u for freebsd-pf@freebsd.org; (v1.249) (envelope-from ); Mon, 12 Dec 2005 13:07:35 +0300 Message-ID: <439D4C88.8070802@gmail.com> Date: Mon, 12 Dec 2005 13:10:16 +0300 From: thecoba@gmail.com User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051013) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: keep state rules on vlan? 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, 12 Dec 2005 10:08:53 -0000 hey i have weird problem with keep state outgoing connections on vlan interface. And im getting blocks for outgoing traffic on $eif2. If configure pf w/o keep state everything works nice. But with keep state rules it wont work. I also have keep states on parent interface of vlan maybe they kill vlan rules or have some strange effect with them? uname: FreeBSD XXX 6.0-RELEASE FreeBSD 6.0-RELEASE #0 pf.conf: # pf.conf # set loginterface none set optimization normal set block-policy return set require-order yes set fingerprints "/etc/pf.os" eif="fxp0" iif="em0" iif2="vlan1" eif2="vlan0" pfsyncif = "pfsync0" loopif = "lo0" set block-policy return scrub in on $eif all scrub in on $eif2 all pass out on $eif proto tcp from any to any flags S/SA keep state pass out on $eif proto { udp, icmp } from any to any keep state pass out on $eif2 proto tcp from any to any flags S/SA keep state pass out on $eif2 proto { udp, icmp } from any to any keep state pass out on $eif route-to ($eif2 gw1) from $eif2 to any pass out on $eif2 route-to ($eif gw2) from $eif to any From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 11:02:37 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 415AA16A445 for ; Mon, 12 Dec 2005 11:02:37 +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 D609043D81 for ; Mon, 12 Dec 2005 11:02:28 +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.4/8.13.4) with ESMTP id jBCB2LKT064718 for ; Mon, 12 Dec 2005 11:02:21 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBCB2JUN064712 for freebsd-pf@freebsd.org; Mon, 12 Dec 2005 11:02:19 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 12 Dec 2005 11:02:19 GMT Message-Id: <200512121102.jBCB2JUN064712@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, 12 Dec 2005 11:02:37 -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] kern/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 o [2005/12/09] kern/90148 pf [pf] pf_enable="YES" -> Fatal trap 12: pa 2 problems total. From owner-freebsd-pf@FreeBSD.ORG Mon Dec 12 17:44:55 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 9F15E16A420 for ; Mon, 12 Dec 2005 17:44:55 +0000 (GMT) (envelope-from MFranke@evendi.de) Received: from smtp.kliff.de (smtp.kliff.de [80.239.136.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4784B43D5F for ; Mon, 12 Dec 2005 17:44:47 +0000 (GMT) (envelope-from MFranke@evendi.de) X-ClientAddr: 85.183.128.34 Received: from DC-EX-001.evendi.local ([85.183.128.34]) by smtp.kliff.de (8.11.6/8.11.6) with ESMTP id jBCHifx03332 for ; Mon, 12 Dec 2005 18:44:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 12 Dec 2005 18:44:42 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Firewall concepts Thread-Index: AcX+Jtg+QXGEx1MzStyrt56zUtqW1gBGW/3Q From: "Marcus Franke" To: Subject: AW: Firewall concepts X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-pf@freebsd.org 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, 12 Dec 2005 17:44:55 -0000 >=20 > The main problem comes when they need to offer some kind of service > that requires inbound connections, such as traditional servers, some > multimedia and p2p protocols. > Ok, but normal client machines won't need such stuff, when I detect someone using file sharing on the company machines, that will make me really angry. =20 > shared ruleset is the way to go. If the latter, then having an > independent per-machine configuration file is the way to go. You can > even implement a middle ground by use of anchors or textual inclusion > using some kind of preprocessor (email me if you want a copy of one). > Sounds interesting, you have such a software that would compile the actual ruleset for the local machine depending from textfiles which could be stored on a single directory mounted from a controlling server? For example, this is the way Windows works and fetches their policy sets from domain controllers :) > I've never been exactly sure what problem "the registry" or "active > directory" solves. The former is a hierarchical namespace containing > configuration information, which sounds like a filesystem to me. What > program variables are considered "configurable" seems somewhat > arbitrary. Can you explain what problem ActiveDirectory solves? I'm > willing to bet if you can tell me the requirements, I can point you to > an open-source solution. There is something called OpenLDAP... The registry is just a configuration database for local software. Could be done in files in /etc/ or elsewhere. Different solutions for the=20 same thing. One could be scary about flat files, others about the registry. I fear neither the one solution nor the other. And OpenLDAP is just another directory server like the ActiveDirectoy is one. They are rather similar. Just, the integration of the client software Win2k and WinXP is very high? Sorry, missing the words to express it in English. You can control the clients in the domain with good working tools from a single point. In my eyes this is a powerful solution, even when=20 only few aspects of this solutions will be used. The problem, in my eyes, isn't to fear the solution instead one should try to use its power and learn to use it for something good. Sure, there are a lot of problems in software from Redmond :) But, a lot of problems I see in daily work with windows is software that isn't programmed very well. Like software that needs write access in its own directory.. brrrr And the easy way to solve it, is to give the user more rights than it is good for him/her. There are a lot of problems with software written in php, but do we say php is evil? Or Unix is evil because there are programms written in php that will enable some people to hack my servers? > Trying to centralize access control on one firewall machine is a > useful idiom, but can become challenging as the links to "untrusted" > networks increases, for example when some internal user installs a > modem or WAP. Now the outside world has equivalent access to what was Have seen this once, a modem directly connected to the server :) And everyone could try to dial into the box. There should be a dial back rule for this. Or a good VPN.. > If increasing bandwidth doesn't do it, end-to-end encryption with be > the death knoll of a centralized firewall or NIDS system, as the ports > used and application data will be unavailable to any system in the > middle (unless of course all systems escrow their keys with the > firewall or gateway, which is complex and problematic and defeats the > purpose of end-to-end encryption). Yeah, SSL proxying.. sounds evil to me, too. Regards, Marcus From owner-freebsd-pf@FreeBSD.ORG Tue Dec 13 10:13:29 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 65DFF16A41F for ; Tue, 13 Dec 2005 10:13:29 +0000 (GMT) (envelope-from solinym@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 905E643D5C for ; Tue, 13 Dec 2005 10:13:28 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by wproxy.gmail.com with SMTP id i3so86492wra for ; Tue, 13 Dec 2005 02:13:28 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=V8FtZIaGgP+0OTDKHf28DiNdWggNL4LmHMTT2YVUxwcNuGiklwOq7ctNDqAX6/Zk7TZ64xXHU4PcsgXr7V7jWWh70coLXx4Ry1PrUJwZESTIendJqVD5KZB6vnxUfRz4D3snIDl5qfXf2CXXkZunqz7vXh6YrqVxo/aniYalpa8= Received: by 10.54.149.3 with SMTP id w3mr624734wrd; Tue, 13 Dec 2005 02:13:27 -0800 (PST) Received: by 10.54.78.20 with HTTP; Tue, 13 Dec 2005 02:13:27 -0800 (PST) Message-ID: Date: Tue, 13 Dec 2005 04:13:27 -0600 From: "Travis H." To: freebsd-pf@freebsd.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Subject: Re: Firewall concepts 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, 13 Dec 2005 10:13:29 -0000 On 12/12/05, Marcus Franke wrote: > Sounds interesting, you have such a software that would compile > the actual ruleset for the local machine depending from textfiles > which could be stored on a single directory mounted from a controlling > server? > > For example, this is the way Windows works and fetches their policy > sets from domain controllers :) Yes, I have a general-purpose text preprocessor I can send you. Or you can use something like m4 although it is complicated. I would avoid using cpp because it has many C-specific assumptions last time I checked. If you "pull" the files from a central location, I recommend caching them locally in case that central location is unavailable.=20 Alternately, you can "push" the files to each computer using scp or rsync-over-ssh every time you make a change. There is a tradeoff between pull and push, mostly it depends on whether you want every client access *to* a server, or if you'd rather make every client allow connections *from* a single machine. -- http://www.lightconsulting.com/~travis/ -><- P=3DNP if (P=3D0 or N=3D1) "My love for mathematics is like 1/x as x approaches 0." GPG fingerprint: 50A1 15C5 A9DE 23B9 ED98 C93E 38E9 204A 94C2 641B From owner-freebsd-pf@FreeBSD.ORG Tue Dec 13 17:07:39 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 3A3FB16A41F for ; Tue, 13 Dec 2005 17:07:39 +0000 (GMT) (envelope-from michiel@nl-hrln-ptgrf.net) Received: from mail.nl-hrln-ptgrf.net (83-138.surfsnel.dsl.internl.net [145.99.138.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59CBB43D4C for ; Tue, 13 Dec 2005 17:07:27 +0000 (GMT) (envelope-from michiel@nl-hrln-ptgrf.net) Received: from ws01michiel (85-138.surfsnel.dsl.internl.net [145.99.138.85]) by mail.nl-hrln-ptgrf.net (Postfix) with ESMTP id 3CD41193631 for ; Tue, 13 Dec 2005 17:04:50 +0000 (UTC) From: "Michiel Kranenburg" To: Date: Tue, 13 Dec 2005 18:07:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 thread-index: AcYAB7zy8EQo/yWCS6qjAjuVgxqd7Q== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-Id: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> Subject: Possible bug in PF with if_bridge 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, 13 Dec 2005 17:07:39 -0000 Hello all, I may have found a bug in PF (in combination with if_bridge) for FreeBSD6.0-RELEASE. Let me explain my situation first: The xl1 and xl2 interfaces are connected together as a bridge (bridge0). The sysctl settings that are used: net.link.bridge.pfil_bridge=1 net.link.bridge.pfil_member=1 After applying these settings and configuring ifconfig, a new interface pops up. --------------------------------------------- bridge0: flags=8041 mtu 1500 ether ac:de:48:8c:58:62 priority 32768 hellotime 2 fwddelay 15 maxage 20 member: xl2 flags=3 member: xl1 flags=3 --------------------------------------------- The bridge is working fine, and passes al traffic as its supposed too. The weird thing occurs when using PF to filter the bridge. Let me post my pf.conf first: (I did not post the declaration of variables on top of the conf) --------------------------------------------- scrub in all block in log on bridge0 from any to $mynet block return-rst in log on bridge0 proto tcp from any to $mynet pass in on bridge0 proto {tcp,udp,icmp} from $mynet to $mynet keep state pass out on bridge0 proto {tcp,udp} from $mynet to any keep state pass on lo0 all ## ICMP Section ## pass in on bridge0 proto icmp from any to $mynet icmp-type { 0 3 8 11 } keep state pass out on bridge0 proto icmp from $mynet to any icmp-type { 0 3 8 11 } keep state ## DNS Replys ## pass in on bridge0 proto {tcp,udp} from {217.149.196.6,217.149.192.6} to $mynet port 53 keep state ## Router ## pass in on bridge0 proto {tcp,udp} from any to $router port 22 flags S/SA keep state ## Mail ## pass in on bridge0 proto {tcp,udp} from any to $mail port 25 flags S/SA keep state pass in on bridge0 proto {tcp,udp} from {$mynet} to $mail port 143 flags S/SA keep state ## Web ## pass in on bridge0 proto {tcp,udp} from any to $web port 80 flags S/SA keep state pass in on bridge0 proto {tcp,udp} from any to $web port 443 flags S/SA keep state --------------------------------------------- As you can see, I want to block every incoming packet (if not 'passed' later on the ruleset) to the bridge (to the network on the other side). Now comes the strange part: Behind $web and $mail are running SSH-servers. As defined by the rules, I don't want to allow any connection from the outside to the SSH-servers. BUT, some hosts/ip-addresses can _still_ connect to the SSH-servers(!), and some _dont_ (as it supposed to be). The connections that are accepted (in violation with the PF-rules) to the SSH-servers are logged in /var/log/pflog as denied. (So PF marks the packets as denied, but doesn't block them!). These faults don't apply to SSH-servers only! It happens to every service on the network. At least, the hosts that I have tested with are not in a specific ip-range. I just picked some random hosts with different ip-addresses and tried to telnet to the service-ports, with some hosts I got a nice 'return-rst' packet, telling me that the connection is refused. With others I got the service response. I hope some of you guys can help me out. Please CC me as i'm not subscribed to this list. With kind regards, Michiel Kranenburg From owner-freebsd-pf@FreeBSD.ORG Tue Dec 13 18:01: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 AADD016A41F for ; Tue, 13 Dec 2005 18:01:51 +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 069F143D95 for ; Tue, 13 Dec 2005 18:01:31 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 50561 invoked by uid 89); 13 Dec 2005 18:01:24 -0000 Received: by simscan 1.1.0 ppid: 50535, pid: 50537, t: 2.3798s 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; 13 Dec 2005 18:01:22 -0000 Message-ID: <439F0C72.5000009@wombatsweb.com> Date: Tue, 13 Dec 2005 13:01:22 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michiel Kranenburg References: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> In-Reply-To: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> 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.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Cc: freebsd-pf@freebsd.org Subject: Re: Possible bug in PF with if_bridge 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, 13 Dec 2005 18:01:51 -0000 Michiel Kranenburg on 12/13/2005 12:07 PM wrote: >I may have found a bug in PF (in combination with if_bridge) for >FreeBSD6.0-RELEASE. > > >Let me explain my situation first: > >The xl1 and xl2 interfaces are connected together as a bridge (bridge0). > >The sysctl settings that are used: >net.link.bridge.pfil_bridge=1 >net.link.bridge.pfil_member=1 > >After applying these settings and configuring ifconfig, a new interface pops >up. > >--------------------------------------------- >bridge0: flags=8041 mtu 1500 > ether ac:de:48:8c:58:62 > priority 32768 hellotime 2 fwddelay 15 maxage 20 > member: xl2 flags=3 > member: xl1 flags=3 >--------------------------------------------- > >The bridge is working fine, and passes al traffic as its supposed too. > > >The weird thing occurs when using PF to filter the bridge. >Let me post my pf.conf first: (I did not post the declaration of variables >on top of the conf) > >--------------------------------------------- >scrub in all > >block in log on bridge0 from any to $mynet >block return-rst in log on bridge0 proto tcp from any to $mynet > >pass in on bridge0 proto {tcp,udp,icmp} from $mynet to $mynet keep state >pass out on bridge0 proto {tcp,udp} from $mynet to any keep state > >pass on lo0 all > > >## ICMP Section ## >pass in on bridge0 proto icmp from any to $mynet icmp-type { 0 3 8 11 } keep >state >pass out on bridge0 proto icmp from $mynet to any icmp-type { 0 3 8 11 } >keep state > > >## DNS Replys ## >pass in on bridge0 proto {tcp,udp} from {217.149.196.6,217.149.192.6} to >$mynet port 53 keep state > > >## Router ## >pass in on bridge0 proto {tcp,udp} from any to $router port 22 flags S/SA >keep state > > >## Mail ## >pass in on bridge0 proto {tcp,udp} from any to $mail port 25 flags S/SA keep >state >pass in on bridge0 proto {tcp,udp} from {$mynet} to $mail port 143 flags >S/SA keep state > > >## Web ## >pass in on bridge0 proto {tcp,udp} from any to $web port 80 flags S/SA keep >state >pass in on bridge0 proto {tcp,udp} from any to $web port 443 flags S/SA keep >state >--------------------------------------------- > > >As you can see, I want to block every incoming packet (if not 'passed' later >on the ruleset) to the bridge (to the network on the other side). > > >Now comes the strange part: > >Behind $web and $mail are running SSH-servers. As defined by the rules, I >don't want to allow any connection from the outside to the SSH-servers. >BUT, some hosts/ip-addresses can _still_ connect to the SSH-servers(!), and >some _dont_ (as it supposed to be). > >The connections that are accepted (in violation with the PF-rules) to the >SSH-servers are logged in /var/log/pflog as denied. (So PF marks the packets >as denied, but doesn't block them!). > >These faults don't apply to SSH-servers only! It happens to every service on >the network. > >At least, the hosts that I have tested with are not in a specific ip-range. >I just picked some random hosts with different ip-addresses and tried to >telnet to the service-ports, with some >hosts I got a nice 'return-rst' packet, telling me that the connection is >refused. With others I got the service response. > > >I hope some of you guys can help me out. > >Please CC me as i'm not subscribed to this list. > I am new to PF and if_bridge ... so I am guessing here, but I do have first hand experience in just setting one up ... I am still playing with rulesets to get it just right ... ANYWAY ... Seems to me that if you want to just use "bridge0" that you should change your sysctl.conf net.link.bridge.pfil_member=1 to net.link.bridge.pfil_member=0 The way I have mine configured is to use the xl0 and xl1 in the rules (with pfil_member=1) ... I have seen that ftpsesame adds bridge0 rules dynamically though ... But, I don't think it's a bug ... From owner-freebsd-pf@FreeBSD.ORG Tue Dec 13 19:56:55 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 993B916A41F for ; Tue, 13 Dec 2005 19:56:55 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received: from dbmail-mx1.orcon.net.nz (loadbalancer1.orcon.net.nz [219.88.242.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46A2B43D99 for ; Tue, 13 Dec 2005 19:56:38 +0000 (GMT) (envelope-from thompsa@freebsd.org) Received-SPF: none Received: from heff.fud.org.nz (60-234-149-201.bitstream.orcon.net.nz [60.234.149.201]) by dbmail-mx1.orcon.net.nz (8.13.2/8.13.2/Debian-1) with ESMTP id jBDJv648011848; Wed, 14 Dec 2005 08:57:06 +1300 Received: by heff.fud.org.nz (Postfix, from userid 1001) id 3791B28432; Wed, 14 Dec 2005 08:56:24 +1300 (NZDT) Date: Wed, 14 Dec 2005 08:56:24 +1300 From: Andrew Thompson To: Michiel Kranenburg Message-ID: <20051213195624.GA5248@heff.fud.org.nz> References: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> User-Agent: Mutt/1.5.11 X-Virus-Scanned: ClamAV version 0.87.1, clamav-milter version 0.87 on dbmail-mx1.orcon.net.nz X-Virus-Status: Clean Cc: freebsd-pf@freebsd.org Subject: Re: Possible bug in PF with if_bridge 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, 13 Dec 2005 19:56:55 -0000 On Tue, Dec 13, 2005 at 06:07:46PM +0100, Michiel Kranenburg wrote: > Hello all, > > > I may have found a bug in PF (in combination with if_bridge) for > FreeBSD6.0-RELEASE. > > > The weird thing occurs when using PF to filter the bridge. > Let me post my pf.conf first: (I did not post the declaration of variables > on top of the conf) > > --------------------------------------------- > scrub in all > > block in log on bridge0 from any to $mynet > block return-rst in log on bridge0 proto tcp from any to $mynet > > pass in on bridge0 proto {tcp,udp,icmp} from $mynet to $mynet keep state > pass out on bridge0 proto {tcp,udp} from $mynet to any keep state > > pass on lo0 all [...] > > Now comes the strange part: > > Behind $web and $mail are running SSH-servers. As defined by the rules, I > don't want to allow any connection from the outside to the SSH-servers. > BUT, some hosts/ip-addresses can _still_ connect to the SSH-servers(!), and > some _dont_ (as it supposed to be). You should probably be filtering on the member interfaces rather than bridge0 if you are doing keep-state. bridge0 has no direction so packets travelling in one direction look the same a the reverse path, this may be tripping up with stateful rules. Can you try changing your pf rules to filter on xl1 and xl2 and see if you get the same behaviour. p.s 6.0-RELEASE has a mbuf leak with if_bridge(4)+pfil(9), you may want to go to RELENG_6 cheers, Andrew From owner-freebsd-pf@FreeBSD.ORG Thu Dec 15 01:42:25 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 1F95F16A41F for ; Thu, 15 Dec 2005 01:42:25 +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 AC34B43D73 for ; Thu, 15 Dec 2005 01:42:22 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 30628 invoked by uid 89); 15 Dec 2005 01:42:21 -0000 Received: by simscan 1.1.0 ppid: 30621, pid: 30623, t: 1.3397s 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; 15 Dec 2005 01:42:19 -0000 Message-ID: <43A0C9FD.8060006@wombatsweb.com> Date: Wed, 14 Dec 2005 20:42:21 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) 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.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: spamd logging 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, 15 Dec 2005 01:42:25 -0000 I am running FBSD 6.0 if_bridge PF firewall. cd /usr/ports/mail/spamd make install clean Seems to have installed "pfspamd" Anyway, I can't seem to get it to log to a logfile. Even running it non-daemonized "-d" I see no messaging ... /usr/local/libexec/spamd -v -b 127.0.0.1 -d rc.conf pfspamd_enable="YES" pfspamd_flags="-v -b 127.0.0.1" syslog.conf Tried as described in man page: !spamd daemon.err;daemon.warn;daemon.info also tried: !spamd *.* log file just shows that the service started ... I see the states created for it when running pftop[D, r] I don't know that spamd is actually doing any work to log ... From owner-freebsd-pf@FreeBSD.ORG Thu Dec 15 07:56:40 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 1039F16A41F for ; Thu, 15 Dec 2005 07:56:40 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 1906A43D60 for ; Thu, 15 Dec 2005 07:56:38 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 79255 invoked by uid 89); 15 Dec 2005 07:56:16 -0000 Received: from link.warped.ro (HELO warped) (86.104.83.83) by warped.ro with SMTP; 15 Dec 2005 07:56:16 -0000 Message-ID: <001101c6014d$13c82070$53536856@warped> From: "Robert" To: Date: Thu, 15 Dec 2005 09:56:38 +0200 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: pf on bridge 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, 15 Dec 2005 07:56:40 -0000 I am using pf on a bridge and=20 i want to know if i can limit the download=20 and upload because i read on the net that=20 it's impossible From owner-freebsd-pf@FreeBSD.ORG Thu Dec 15 11:16:00 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 9627316A41F for ; Thu, 15 Dec 2005 11:16:00 +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 E50FC43D5E for ; Thu, 15 Dec 2005 11:15:59 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 71366 invoked by uid 89); 15 Dec 2005 11:15:58 -0000 Received: by simscan 1.1.0 ppid: 71360, pid: 71362, t: 1.7467s 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; 15 Dec 2005 11:15:56 -0000 Message-ID: <43A1506E.8060802@wombatsweb.com> Date: Thu, 15 Dec 2005 06:15:58 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <43A0C9FD.8060006@wombatsweb.com> In-Reply-To: <43A0C9FD.8060006@wombatsweb.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.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: Re: spamd logging [ud: on bridge] 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, 15 Dec 2005 11:16:00 -0000 David Pierron on 12/14/2005 8:42 PM wrote: > I am running FBSD 6.0 if_bridge PF firewall. > > cd /usr/ports/mail/spamd > make install clean > > Seems to have installed "pfspamd" > > Anyway, I can't seem to get it to log to a logfile. Even running it > non-daemonized "-d" I see no messaging ... > /usr/local/libexec/spamd -v -b 127.0.0.1 -d > > rc.conf > pfspamd_enable="YES" > pfspamd_flags="-v -b 127.0.0.1" > > syslog.conf > Tried as described in man page: > !spamd > daemon.err;daemon.warn;daemon.info > > also tried: > !spamd > *.* > > log file just shows that the service started ... > I see the states created for it when running pftop[D, r] > > I don't know that spamd is actually doing any work to log ... UPDATE: Logging works ... Seems the issue is spamd running on a bridge ... I have been trying everything I've found on Google but so far nothing is making it work ... The issue is "rdr"ing the connection to an interface running spamd ... I am not running NAT ... I have tried tags, route-to and individual rules ... I tried rdr'ing to an interface besides localhost ... So far nothing is working ... What to do? From owner-freebsd-pf@FreeBSD.ORG Thu Dec 15 12:45:11 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 7CA2516A41F for ; Thu, 15 Dec 2005 12:45:11 +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 A0FC343D5F for ; Thu, 15 Dec 2005 12:45:10 +0000 (GMT) (envelope-from david@wombatsweb.com) Received: (qmail 77184 invoked by uid 89); 15 Dec 2005 12:45:07 -0000 Received: by simscan 1.1.0 ppid: 77174, pid: 77176, t: 1.8584s 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; 15 Dec 2005 12:45:05 -0000 Message-ID: <43A16553.4010503@wombatsweb.com> Date: Thu, 15 Dec 2005 07:45:07 -0500 From: David Pierron User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <43A0C9FD.8060006@wombatsweb.com> <43A1506E.8060802@wombatsweb.com> In-Reply-To: <43A1506E.8060802@wombatsweb.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.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.2 Subject: Re: spamd logging [ud: on bridge] 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, 15 Dec 2005 12:45:11 -0000 David Pierron on 12/15/2005 6:15 AM wrote: > David Pierron on 12/14/2005 8:42 PM wrote: > >> I am running FBSD 6.0 if_bridge PF firewall. >> >> cd /usr/ports/mail/spamd >> make install clean >> >> Seems to have installed "pfspamd" >> >> Anyway, I can't seem to get it to log to a logfile. Even running it >> non-daemonized "-d" I see no messaging ... >> /usr/local/libexec/spamd -v -b 127.0.0.1 -d >> >> rc.conf >> pfspamd_enable="YES" >> pfspamd_flags="-v -b 127.0.0.1" >> >> syslog.conf >> Tried as described in man page: >> !spamd >> daemon.err;daemon.warn;daemon.info >> >> also tried: >> !spamd >> *.* >> >> log file just shows that the service started ... >> I see the states created for it when running pftop[D, r] >> >> I don't know that spamd is actually doing any work to log ... > > > UPDATE: Logging works ... Seems the issue is spamd running on a > bridge ... I have been trying everything I've found on Google but so > far nothing is making it work ... The issue is "rdr"ing the > connection to an interface running spamd ... I am not running NAT > ... I have tried tags, route-to and individual rules ... I tried > rdr'ing to an interface besides localhost ... So far nothing is > working ... What to do? UPDATE: More searching (used AskJeeves) and found a message from May 2003: Daniel Hartmeier: Yes, a bridge operates on ethernet level. For an rdr, pf will only replace the destination IP address/port, it doesn't touch the destination MAC address. I assume that in your case, the TCP SYN is sent to the MAC address of the internal host (not the firewall). pf replaces the destination IP address/port and hands the packet back to the bridge, which forwards it based on its destination MAC address. You can use 'route-to lo0' to cause pf to route the incoming packets to the loopback interface (using 127.0.0.1 as replacement destination address) instead of handing it back to the bridge after translation: rdr on $ext_if inet proto tcp from $outside_system to any port smtp -> 127.0.0.1 port 8025 pass in on $ext_if route-to lo0 inet proto tcp from any to $ext_if port 8025 keep state Also, if the bridge is transparent (no IP addresses assigned to the interfaces), spamd won't work, as userland on the firewall is isolated from all networks. You need to assign an IP address to the external interface, otherwise there is no routing table entry which spamd needs to send replies to the external client. Many pf tricks work on bridges, but not all of them. Some require IP addresses assigned to the interfaces, for some you even need to enable IP forwarding. A bridge works very differently from a plain IP forwarder, you'll have to think in terms of ethernet frames, not IP packets. Don't use a bridge if you want the functionality of an IP forwarder. From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 13:41:40 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 69B4316A41F for ; Fri, 16 Dec 2005 13:41:40 +0000 (GMT) (envelope-from nikky@mnet.bg) Received: from home.mnet.bg (home.mnet.bg [193.110.223.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 972A343D53 for ; Fri, 16 Dec 2005 13:41:39 +0000 (GMT) (envelope-from nikky@mnet.bg) Received: from localhost (home [127.0.0.1]) by home.mnet.bg (Postfix) with ESMTP id 3DF963B302 for ; Fri, 16 Dec 2005 15:41:38 +0200 (EET) Received: from home.mnet.bg ([127.0.0.1]) by localhost (home [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16556-01-9 for ; Fri, 16 Dec 2005 15:41:37 +0200 (EET) Received: from orange.mnet.bg (orange.mnet.bg [193.110.223.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by home.mnet.bg (Postfix) with ESMTP id 84D413B2F7 for ; Fri, 16 Dec 2005 15:41:37 +0200 (EET) Date: Fri, 16 Dec 2005 15:41:33 +0200 From: Nickola Kolev To: freebsd-pf@freebsd.org Message-Id: <20051216154133.182bab4f.nikky@mnet.bg> Organization: MNET X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.9; i486-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="PGP-SHA1"; boundary="Signature=_Fri__16_Dec_2005_15_41_33_+0200_55.pIXSF4flscp/M" X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at mnet.bg Subject: altq and max number of classes on xBSD 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, 16 Dec 2005 13:41:40 -0000 --Signature=_Fri__16_Dec_2005_15_41_33_+0200_55.pIXSF4flscp/M Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Currently I have a GNU/Linux based router, which is serving as a traffic control gateway for a /19 network. Right now, there are about 6000 classes in a hierarchy, built upon the hierarchycal token bucket qdisc. I'd like to build a Free/Open/NetBSD router, utilizing ALTQ+pf, to replace the linux machine, but as far as I know, the maximum number of classes (at least in the FreeBSD implementation) is limited to 256 for CBQ and 64 for HSFC, which is absolutely insufficient for my needs. Finally, my question is is there a way to raise the maximum number of classes in a hierarchy (besides the artificial change in altq_hfsc.h and altq_cbq.h)? How stable would a system like that be? If you have any suggestions for a setup, which can do the job of traffic controlling /19 with a hierarchy of classes, each with different guaranteed and maximum rates, I'd be very grateful. Regards, Nickola --Signature=_Fri__16_Dec_2005_15_41_33_+0200_55.pIXSF4flscp/M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDosQQ/g+8nwXNejkRAjZfAJ4j6sNpoN0bHvG9xT6w38QPROZN+gCfckaA ynhNr3DZUbGgQ1H9ST974Y4= =GLqo -----END PGP SIGNATURE----- --Signature=_Fri__16_Dec_2005_15_41_33_+0200_55.pIXSF4flscp/M-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 14:42:15 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 8795816A423 for ; Fri, 16 Dec 2005 14:42:15 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 6D9A143D5D for ; Fri, 16 Dec 2005 14:42:14 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 1490 invoked by uid 89); 16 Dec 2005 14:41:54 -0000 Received: from unknown (HELO warped) (192.168.1.166) by warped.ro with SMTP; 16 Dec 2005 14:41:54 -0000 Message-ID: <001701c6024e$e8ea1f40$a601a8c0@warped> From: "Robert" To: Date: Fri, 16 Dec 2005 16:42:15 +0200 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: address mapping 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: Fri, 16 Dec 2005 14:42:15 -0000 can pf do address mapping ?=20 i hava a server with 5 ips on the ext_if and i want to map an ip to let's say 192.168.1.11 From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 14:47:15 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 F238F16A420 for ; Fri, 16 Dec 2005 14:47:14 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id C973B43D68 for ; Fri, 16 Dec 2005 14:47:04 +0000 (GMT) (envelope-from bill.marquette@gmail.com) Received: by xproxy.gmail.com with SMTP id s9so509286wxc for ; Fri, 16 Dec 2005 06:47:00 -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=TOEcvxxbK4aUYTaxe3hM2dBfLaY5hxqkOCLsIM34B9w+22E2oizwCZBy07UfU7ty82aqWbR65rPzwDYybRxZBbMUxlcmcoycmBKDMus59IjoB+OV6672fBcMjavTy5IRZMME1WkztlPXe5ScFUJjcQh0j8ty3KYIH3DEHMEJ5Tg= Received: by 10.70.109.14 with SMTP id h14mr991016wxc; Fri, 16 Dec 2005 06:47:00 -0800 (PST) Received: by 10.70.89.12 with HTTP; Fri, 16 Dec 2005 06:47:00 -0800 (PST) Message-ID: <55e8a96c0512160647k2ae18014se1d721cd201fab21@mail.gmail.com> Date: Fri, 16 Dec 2005 08:47:00 -0600 From: Bill Marquette To: Robert In-Reply-To: <001701c6024e$e8ea1f40$a601a8c0@warped> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <001701c6024e$e8ea1f40$a601a8c0@warped> Cc: freebsd-pf@freebsd.org Subject: Re: address mapping 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: Fri, 16 Dec 2005 14:47:15 -0000 binat is likely what you want. --Bill On 12/16/05, Robert wrote: > can pf do address mapping ? > > i hava a server with 5 ips on the ext_if > and i want to map an ip to let's say 192.168.1.11 > _______________________________________________ > 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 Fri Dec 16 16:09:18 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 E184D16A420 for ; Fri, 16 Dec 2005 16:09:18 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDC8643D5A for ; Fri, 16 Dec 2005 16:09:17 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from localhost (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id A317F1CC035 for ; Fri, 16 Dec 2005 10:09:16 -0600 (CST) Received: from mail.oitsec.umn.edu ([127.0.0.1]) by localhost (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67283-03 for ; Fri, 16 Dec 2005 10:09:16 -0600 (CST) Received: from shoggoth.oitsec.umn.edu (shoggoth.oitsec.umn.edu [160.94.247.195]) by mail.oitsec.umn.edu (Postfix) with ESMTP id 54F161CC01D for ; Fri, 16 Dec 2005 10:09:16 -0600 (CST) Date: Fri, 16 Dec 2005 10:09:15 -0600 From: Paul Dokas To: freebsd-pf@freebsd.org Message-Id: <20051216100915.73fef758.dokas@oitsec.umn.edu> Organization: OIT Security and Assurance, University of Minnesota X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) X-Discordia: fnord Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="Multipart=_Fri__16_Dec_2005_10_09_15_-0600_7xXQ.VoZgyfQT9PN" X-Virus-Scanned: by amavisd-new at oitsec.umn.edu Subject: very odd PF + FreeBSD6.0 problems X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Dokas 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, 16 Dec 2005 16:09:19 -0000 This is a multi-part message in MIME format. --Multipart=_Fri__16_Dec_2005_10_09_15_-0600_7xXQ.VoZgyfQT9PN Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit I recently upgrade to FreeBSD 6.0 via a full reinstall and I've run into a very strange problem with PF. First of all, I'm using the same PF ruleset that I used on 5.4. I know for a fact that it works correctly there. What's happening is that when I turn on PF, I'm able to make outbound connections, but if those connections go idle for more than 30 seconds, PF starts rejecting inbound packets. Furthermore, PF _does_ show an ESTABLISHED state in it's state table. With loud debugging turned on, it's giving me "pf_normalize_tcp_stateful: Timestamp failed 1" messages. The attached files show all of the details that I've collected about this. this.host.umn.edu (A.B.C.D) is the host that I'm having problems with. The first file shows tcpdump of 'telnet that.host.umn.edu 22' and the PF kernel messages generated by the loud debugging. The second file shows the output of `pfctl -vsa`. I'd greatly appreciate any help that anyone might have about this problem. Paul -- Paul Dokas dokas at oitsec.umn.edu ====================================================================== Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla." --Multipart=_Fri__16_Dec_2005_10_09_15_-0600_7xXQ.VoZgyfQT9PN Content-Type: application/octet-stream; name="pkts_and_dmesg" Content-Disposition: attachment; filename="pkts_and_dmesg" Content-Transfer-Encoding: base64 CnRoaXMuaG9zdC51bW4uZWR1ID09IEEuQi5DLkQKdGhhdC5ob3N0LnVtbi5lZHUgPT0gVy5YLlku WgoKCjA5OjEyOjAwLjUxNjE4MCBJUCB0aGlzLmhvc3QudW1uLmVkdS41NDc0NiA+IHRoYXQuaG9z dC51bW4uZWR1LnNzaDogUyAyODQzNDM5NDA1OjI4NDM0Mzk0MDUoMCkgd2luIDY1NTM1IDxtc3Mg MTQ2MCxub3Asd3NjYWxlIDEsbm9wLG5vcCx0aW1lc3RhbXAgMjM4MjIzMDgyMyAwLHNhY2tPSyxl b2w+CjA5OjEyOjAwLjUxNjU5NyBJUCB0aGF0Lmhvc3QudW1uLmVkdS5zc2ggPiB0aGlzLmhvc3Qu dW1uLmVkdS41NDc0NjogUyAxNzg2ODU3MTA0OjE3ODY4NTcxMDQoMCkgYWNrIDI4NDM0Mzk0MDYg d2luIDY1NTM1IDxtc3MgMTQ2MCxub3Asd3NjYWxlIDEsbm9wLG5vcCx0aW1lc3RhbXAgMTQyNDcx Mjk4OSAyMzgyMjMwODIzLG5vcCxub3Asc2Fja09LPgowOToxMjowMC41MTY2NjQgSVAgdGhpcy5o b3N0LnVtbi5lZHUuNTQ3NDYgPiB0aGF0Lmhvc3QudW1uLmVkdS5zc2g6IC4gYWNrIDEgd2luIDMz MzA0IDxub3Asbm9wLHRpbWVzdGFtcCAyMzgyMjMwODI0IDE0MjQ3MTI5ODk+CjA5OjEyOjAwLjUx ODUwNiBJUCB0aGF0Lmhvc3QudW1uLmVkdS5zc2ggPiB0aGlzLmhvc3QudW1uLmVkdS41NDc0Njog UCAxOjQyKDQxKSBhY2sgMSB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0YW1wIDE0MjQ3MTI5OTMg MjM4MjIzMDgyND4KMDk6MTI6MDAuNjE4MzMxIElQIHRoaXMuaG9zdC51bW4uZWR1LjU0NzQ2ID4g dGhhdC5ob3N0LnVtbi5lZHUuc3NoOiAuIGFjayA0MiB3aW4gMzMzMDQgPG5vcCxub3AsdGltZXN0 YW1wIDIzODIyMzEwMjggMTQyNDcxMjk5Mz4KMDk6MTQ6MDAuNjAxNDEzIElQIHRoYXQuaG9zdC51 bW4uZWR1LnNzaCA+IHRoaXMuaG9zdC51bW4uZWR1LjU0NzQ2OiBGIDQyOjQyKDApIGFjayAxIHdp biAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTQyNDk1Mjk5NCAyMzgyMjMxMDI4PgowOToxNDow MC45MTQ5OTEgSVAgdGhhdC5ob3N0LnVtbi5lZHUuc3NoID4gdGhpcy5ob3N0LnVtbi5lZHUuNTQ3 NDY6IEYgNDI6NDIoMCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVzdGFtcCAxNDI0OTUz NjIxIDIzODIyMzEwMjg+CjA5OjE0OjAxLjM0MjIxMiBJUCB0aGF0Lmhvc3QudW1uLmVkdS5zc2gg PiB0aGlzLmhvc3QudW1uLmVkdS41NDc0NjogRiA0Mjo0MigwKSBhY2sgMSB3aW4gMzMzMDQgPG5v cCxub3AsdGltZXN0YW1wIDE0MjQ5NTQ0NzUgMjM4MjIzMTAyOD4KMDk6MTQ6MDEuOTk2NjA1IElQ IHRoYXQuaG9zdC51bW4uZWR1LnNzaCA+IHRoaXMuaG9zdC51bW4uZWR1LjU0NzQ2OiBGIDQyOjQy KDApIGFjayAxIHdpbiAzMzMwNCA8bm9wLG5vcCx0aW1lc3RhbXAgMTQyNDk1NTc4MyAyMzgyMjMx MDI4PgowOToxNDowMy4xMDU0ODIgSVAgdGhhdC5ob3N0LnVtbi5lZHUuc3NoID4gdGhpcy5ob3N0 LnVtbi5lZHUuNTQ3NDY6IEYgNDI6NDIoMCkgYWNrIDEgd2luIDMzMzA0IDxub3Asbm9wLHRpbWVz dGFtcCAxNDI0OTU3OTk5IDIzODIyMzEwMjg+CgpEZWMgMTYgMDk6MTQ6MDAgdGhpcyBrZXJuZWw6 IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6IFRpbWVzdGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5 OjE0OjAwIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgdHN2YWw6IDE0 MjQ5NTI5OTQgIHRzZWNyOiAzMzY4NzcgICt0aWNrczogMTY1MDkxICBpZGxlOiAxMjBzIDgybXMK RGVjIDE2IDA5OjE0OjAwIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAg c3JjLT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6MDAgdGhp cyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4Nzcg IHRzZWNyOiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6MDAgdGhpcyBr ZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0 MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBb bG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2Fs ZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3Rj cF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJu ZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogMTQyNDk1MzYyMSAgdHNlY3I6 IDMzNjg3NyAgK3RpY2tzOiAxNjU0MzYgIGlkbGU6IDEyMHMgMzk2bXMKRGVjIDE2IDA5OjE0OjAx IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMTQy NDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25v cm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEy OTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IFRDUCBBLkIu Qy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4 NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBo aWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRl YyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGlt ZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6 ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogNTc3NDA5ICB0c2VjcjogMTQyNDcxMjk5MyAgK3RpY2tz OiAxNjUzMzUgIGlkbGU6IDEyMHMgMzA0bXMKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBw Zl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMzM2ODc3ICB0c2VjcjogMTQy NDcxMjk5MwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3Rh dGVmdWw6ICBkc3QtPnRzdmFsOiAxNDI0NzEyOTkzICB0c2VjcjogMzM2NjczICB0c3ZhbDA6IDE0 MjQ3MTI5ODkKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBUQ1AgQS5CLkMuRDo1NDc0NiBB LkIuQy5EOjU0NzQ2IFcuWC5ZLlo6MjIgW2xvPTI4NDM0Mzk0MDUgaGlnaD0yODQzNTA2MDE0IHdp bj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gW2xvPTE3ODY4NTcxNDYgaGlnaD0xNzg2OTIz NzU0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gNDo0IEZBCgpEZWMgMTYgMDk6MTQ6 MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6IFRpbWVzdGFtcCBmYWls ZWQgIDEKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRl ZnVsOiAgdHN2YWw6IDU3NzgxNSAgdHNlY3I6IDE0MjQ3MTI5OTMgICt0aWNrczogMTY1NTU4ICBp ZGxlOiAxMjBzIDUwOG1zCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXpl X3RjcF9zdGF0ZWZ1bDogIHNyYy0+dHN2YWw6IDMzNjg3NyAgdHNlY3I6IDE0MjQ3MTI5OTMKRGVj IDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgZHN0 LT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MyAgdHN2YWwwOiAxNDI0NzEyOTg5CkRl YyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogVENQIEEuQi5DLkQ6NTQ3NDYgQS5CLkMuRDo1NDc0 NiBXLlguWS5aOjIyIFtsbz0yODQzNDM5NDA1IGhpZ2g9Mjg0MzUwNjAxNCB3aW49MzMzMDQgbW9k dWxhdG9yPTAgd3NjYWxlPTFdIFtsbz0xNzg2ODU3MTQ2IGhpZ2g9MTc4NjkyMzc1NCB3aW49MzMz MDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIDQ6NCBGQQoKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2Vy bmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiBUaW1lc3RhbXAgZmFpbGVkICAxCkRlYyAx NiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHRzdmFs OiA1NzgyMjcgIHRzZWNyOiAxNDI0NzEyOTkzICArdGlja3M6IDE2NTc4NSAgaWRsZTogMTIwcyA3 MTRtcwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVm dWw6ICBzcmMtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEyOTkzCkRlYyAxNiAwOToxNDow MSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIGRzdC0+dHN2YWw6IDE0 MjQ3MTI5OTMgIHRzZWNyOiAzMzY2NzMgIHRzdmFsMDogMTQyNDcxMjk4OQpEZWMgMTYgMDk6MTQ6 MDEgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoy MiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdz Y2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRv cj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9y bWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDEg dGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogMTQyNDk1NDQ3 NSAgdHNlY3I6IDMzNjg3NyAgK3RpY2tzOiAxNjU5MDYgIGlkbGU6IDEyMHMgODI0bXMKRGVjIDE2 IDA5OjE0OjAxIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50 c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJu ZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNy OiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6 IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQw NSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4 Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0 OjQgRkEKCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0 ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBm X25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogNTc4NjUxICB0c2VjcjogMTQyNDcxMjk5 MyAgK3RpY2tzOiAxNjYwMTggIGlkbGU6IDEyMHMgOTI2bXMKRGVjIDE2IDA5OjE0OjAxIHRoaXMg a2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMzM2ODc3ICB0 c2VjcjogMTQyNDcxMjk5MwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6 ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAxNDI0NzEyOTkzICB0c2VjcjogMzM2NjczICB0 c3ZhbDA6IDE0MjQ3MTI5ODkKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBUQ1AgQS5CLkMu RDo1NDc0NiBBLkIuQy5EOjU0NzQ2IFcuWC5ZLlo6MjIgW2xvPTI4NDM0Mzk0MDUgaGlnaD0yODQz NTA2MDE0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gW2xvPTE3ODY4NTcxNDYgaGln aD0xNzg2OTIzNzU0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gNDo0IEZBCgpEZWMg MTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6IFRpbWVz dGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVf dGNwX3N0YXRlZnVsOiAgdHN2YWw6IDU3OTA5OSAgdHNlY3I6IDE0MjQ3MTI5OTMgICt0aWNrczog MTY2MjY1ICBpZGxlOiAxMjFzIDE1MG1zCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZf bm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHNyYy0+dHN2YWw6IDMzNjg3NyAgdHNlY3I6IDE0MjQ3 MTI5OTMKRGVjIDE2IDA5OjE0OjAxIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRl ZnVsOiAgZHN0LT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MyAgdHN2YWwwOiAxNDI0 NzEyOTg5CkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogVENQIEEuQi5DLkQ6NTQ3NDYgQS5C LkMuRDo1NDc0NiBXLlguWS5aOjIyIFtsbz0yODQzNDM5NDA1IGhpZ2g9Mjg0MzUwNjAxNCB3aW49 MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIFtsbz0xNzg2ODU3MTQ2IGhpZ2g9MTc4NjkyMzc1 NCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIDQ6NCBGQQoKRGVjIDE2IDA5OjE0OjAx IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiBUaW1lc3RhbXAgZmFpbGVk ICAxCkRlYyAxNiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1 bDogIHRzdmFsOiA1NzkwOTkgIHRzZWNyOiAxNDI0NzEyOTkzICArdGlja3M6IDE2NjI2NSAgaWRs ZTogMTIxcyAxNTBtcwpEZWMgMTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90 Y3Bfc3RhdGVmdWw6ICBzcmMtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEyOTkzCkRlYyAx NiAwOToxNDowMSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIGRzdC0+ dHN2YWw6IDE0MjQ3MTI5OTMgIHRzZWNyOiAzMzY2NzMgIHRzdmFsMDogMTQyNDcxMjk4OQpEZWMg MTYgMDk6MTQ6MDEgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYg Vy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVs YXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0 IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowMiB0aGlzIGtlcm5l bDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYg MDk6MTQ6MDIgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDog MTQyNDk1NTc4MyAgdHNlY3I6IDMzNjg3NyAgK3RpY2tzOiAxNjY2MjYgIGlkbGU6IDEyMXMgNDc4 bXMKRGVjIDE2IDA5OjE0OjAyIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVs OiAgc3JjLT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6MDIg dGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4 NzcgIHRzZWNyOiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6MDIgdGhp cyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89 Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0x XSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdz Y2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowMiB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXpl X3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDIgdGhpcyBr ZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogNTc5NTk1ICB0c2Vjcjog MTQyNDcxMjk5MyAgK3RpY2tzOiAxNjY1MzggIGlkbGU6IDEyMXMgMzk4bXMKRGVjIDE2IDA5OjE0 OjAyIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDog MzM2ODc3ICB0c2VjcjogMTQyNDcxMjk5MwpEZWMgMTYgMDk6MTQ6MDIgdGhpcyBrZXJuZWw6IHBm X25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAxNDI0NzEyOTkzICB0c2Vjcjog MzM2NjczICB0c3ZhbDA6IDE0MjQ3MTI5ODkKRGVjIDE2IDA5OjE0OjAyIHRoaXMga2VybmVsOiBU Q1AgQS5CLkMuRDo1NDc0NiBBLkIuQy5EOjU0NzQ2IFcuWC5ZLlo6MjIgW2xvPTI4NDM0Mzk0MDUg aGlnaD0yODQzNTA2MDE0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gW2xvPTE3ODY4 NTcxNDYgaGlnaD0xNzg2OTIzNzU0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gNDo0 IEZBCgpEZWMgMTYgMDk6MTQ6MDIgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVm dWw6IFRpbWVzdGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5OjE0OjAyIHRoaXMga2VybmVsOiBwZl9u b3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgdHN2YWw6IDU4MDEyMyAgdHNlY3I6IDE0MjQ3MTI5OTMg ICt0aWNrczogMTY2ODI5ICBpZGxlOiAxMjFzIDY2Mm1zCkRlYyAxNiAwOToxNDowMiB0aGlzIGtl cm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHNyYy0+dHN2YWw6IDMzNjg3NyAgdHNl Y3I6IDE0MjQ3MTI5OTMKRGVjIDE2IDA5OjE0OjAyIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVf dGNwX3N0YXRlZnVsOiAgZHN0LT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MyAgdHN2 YWwwOiAxNDI0NzEyOTg5CkRlYyAxNiAwOToxNDowMiB0aGlzIGtlcm5lbDogVENQIEEuQi5DLkQ6 NTQ3NDYgQS5CLkMuRDo1NDc0NiBXLlguWS5aOjIyIFtsbz0yODQzNDM5NDA1IGhpZ2g9Mjg0MzUw NjAxNCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIFtsbz0xNzg2ODU3MTQ2IGhpZ2g9 MTc4NjkyMzc1NCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIDQ6NCBGQQoKRGVjIDE2 IDA5OjE0OjAyIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiBUaW1lc3Rh bXAgZmFpbGVkICAxCkRlYyAxNiAwOToxNDowMiB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3Rj cF9zdGF0ZWZ1bDogIHRzdmFsOiA1ODA3NzkgIHRzZWNyOiAxNDI0NzEyOTkzICArdGlja3M6IDE2 NzE5MCAgaWRsZTogMTIxcyA5OTBtcwpEZWMgMTYgMDk6MTQ6MDIgdGhpcyBrZXJuZWw6IHBmX25v cm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBzcmMtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEy OTkzCkRlYyAxNiAwOToxNDowMiB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1 bDogIGRzdC0+dHN2YWw6IDE0MjQ3MTI5OTMgIHRzZWNyOiAzMzY2NzMgIHRzdmFsMDogMTQyNDcx Mjk4OQpEZWMgMTYgMDk6MTQ6MDIgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5D LkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMz MzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQg d2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowMyB0 aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAg MQpEZWMgMTYgMDk6MTQ6MDMgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6 ICB0c3ZhbDogNTgxNjkxICB0c2VjcjogMTQyNDcxMjk5MyAgK3RpY2tzOiAxNjc2OTEgIGlkbGU6 IDEyMnMgNDQ3bXMKRGVjIDE2IDA5OjE0OjAzIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNw X3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMzM2ODc3ICB0c2VjcjogMTQyNDcxMjk5MwpEZWMgMTYg MDk6MTQ6MDMgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRz dmFsOiAxNDI0NzEyOTkzICB0c2VjcjogMzM2NjczICB0c3ZhbDA6IDE0MjQ3MTI5ODkKRGVjIDE2 IDA5OjE0OjAzIHRoaXMga2VybmVsOiBUQ1AgQS5CLkMuRDo1NDc0NiBBLkIuQy5EOjU0NzQ2IFcu WC5ZLlo6MjIgW2xvPTI4NDM0Mzk0MDUgaGlnaD0yODQzNTA2MDE0IHdpbj0zMzMwNCBtb2R1bGF0 b3I9MCB3c2NhbGU9MV0gW2xvPTE3ODY4NTcxNDYgaGlnaD0xNzg2OTIzNzU0IHdpbj0zMzMwNCBt b2R1bGF0b3I9MCB3c2NhbGU9MV0gNDo0IEZBCgpEZWMgMTYgMDk6MTQ6MDMgdGhpcyBrZXJuZWw6 IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6IFRpbWVzdGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5 OjE0OjAzIHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgdHN2YWw6IDE0 MjQ5NTc5OTkgIHRzZWNyOiAzMzY4NzcgICt0aWNrczogMTY3ODQ1ICBpZGxlOiAxMjJzIDU4N21z CkRlYyAxNiAwOToxNDowMyB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDog IHNyYy0+dHN2YWw6IDE0MjQ3MTI5OTMgIHRzZWNyOiAzMzY2NzMKRGVjIDE2IDA5OjE0OjAzIHRo aXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgZHN0LT50c3ZhbDogMzM2ODc3 ICB0c2VjcjogMTQyNDcxMjk5MyAgdHN2YWwwOiAzMzY2NzIKRGVjIDE2IDA5OjE0OjAzIHRoaXMg a2VybmVsOiBUQ1AgQS5CLkMuRDo1NDc0NiBBLkIuQy5EOjU0NzQ2IFcuWC5ZLlo6MjIgW2xvPTI4 NDM0Mzk0MDUgaGlnaD0yODQzNTA2MDE0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0g W2xvPTE3ODY4NTcxNDYgaGlnaD0xNzg2OTIzNzU0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2Nh bGU9MV0gNDo0IEZBCgpEZWMgMTYgMDk6MTQ6MDMgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90 Y3Bfc3RhdGVmdWw6IFRpbWVzdGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5OjE0OjAzIHRoaXMga2Vy bmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgdHN2YWw6IDU4MzExNSAgdHNlY3I6IDE0 MjQ3MTI5OTMgICt0aWNrczogMTY4NDc1ICBpZGxlOiAxMjNzIDE1OW1zCkRlYyAxNiAwOToxNDow MyB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHNyYy0+dHN2YWw6IDMz Njg3NyAgdHNlY3I6IDE0MjQ3MTI5OTMKRGVjIDE2IDA5OjE0OjAzIHRoaXMga2VybmVsOiBwZl9u b3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgZHN0LT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMz NjY3MyAgdHN2YWwwOiAxNDI0NzEyOTg5CkRlYyAxNiAwOToxNDowMyB0aGlzIGtlcm5lbDogVENQ IEEuQi5DLkQ6NTQ3NDYgQS5CLkMuRDo1NDc0NiBXLlguWS5aOjIyIFtsbz0yODQzNDM5NDA1IGhp Z2g9Mjg0MzUwNjAxNCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIFtsbz0xNzg2ODU3 MTQ2IGhpZ2g9MTc4NjkyMzc1NCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIDQ6NCBG QQoKRGVjIDE2IDA5OjE0OjA1IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVs OiBUaW1lc3RhbXAgZmFpbGVkICAxCkRlYyAxNiAwOToxNDowNSB0aGlzIGtlcm5lbDogcGZfbm9y bWFsaXplX3RjcF9zdGF0ZWZ1bDogIHRzdmFsOiA1ODU1NjMgIHRzZWNyOiAxNDI0NzEyOTkzICAr dGlja3M6IDE2OTgyMSAgaWRsZTogMTI0cyAzODNtcwpEZWMgMTYgMDk6MTQ6MDUgdGhpcyBrZXJu ZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBzcmMtPnRzdmFsOiAzMzY4NzcgIHRzZWNy OiAxNDI0NzEyOTkzCkRlYyAxNiAwOToxNDowNSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3Rj cF9zdGF0ZWZ1bDogIGRzdC0+dHN2YWw6IDE0MjQ3MTI5OTMgIHRzZWNyOiAzMzY2NzMgIHRzdmFs MDogMTQyNDcxMjk4OQpEZWMgMTYgMDk6MTQ6MDUgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0 NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYw MTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3 ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAw OToxNDowNSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1w IGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MDUgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bf c3RhdGVmdWw6ICB0c3ZhbDogMTQyNDk2MjAzMSAgdHNlY3I6IDMzNjg3NyAgK3RpY2tzOiAxNzAw NjUgIGlkbGU6IDEyNHMgNjA0bXMKRGVjIDE2IDA5OjE0OjA1IHRoaXMga2VybmVsOiBwZl9ub3Jt YWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3 MwpEZWMgMTYgMDk6MTQ6MDUgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6 ICBkc3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpE ZWMgMTYgMDk6MTQ6MDUgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3 NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1v ZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMz MzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDowNiB0aGlzIGtl cm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMg MTYgMDk6MTQ6MDYgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3Zh bDogNTg4MDExICB0c2VjcjogMTQyNDcxMjk5MyAgK3RpY2tzOiAxNzExNjggIGlkbGU6IDEyNXMg NjA3bXMKRGVjIDE2IDA5OjE0OjA2IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRl ZnVsOiAgc3JjLT50c3ZhbDogMzM2ODc3ICB0c2VjcjogMTQyNDcxMjk5MwpEZWMgMTYgMDk6MTQ6 MDYgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAx NDI0NzEyOTkzICB0c2VjcjogMzM2NjczICB0c3ZhbDA6IDE0MjQ3MTI5ODkKRGVjIDE2IDA5OjE0 OjA2IHRoaXMga2VybmVsOiBUQ1AgQS5CLkMuRDo1NDc0NiBBLkIuQy5EOjU0NzQ2IFcuWC5ZLlo6 MjIgW2xvPTI4NDM0Mzk0MDUgaGlnaD0yODQzNTA2MDE0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3 c2NhbGU9MV0gW2xvPTE3ODY4NTcxNDYgaGlnaD0xNzg2OTIzNzU0IHdpbj0zMzMwNCBtb2R1bGF0 b3I9MCB3c2NhbGU9MV0gNDo0IEZBCgpEZWMgMTYgMDk6MTQ6MDcgdGhpcyBrZXJuZWw6IHBmX25v cm1hbGl6ZV90Y3Bfc3RhdGVmdWw6IFRpbWVzdGFtcCBmYWlsZWQgIDEKRGVjIDE2IDA5OjE0OjA3 IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgdHN2YWw6IDU5MDQ1OSAg dHNlY3I6IDE0MjQ3MTI5OTMgICt0aWNrczogMTcyNTE1ICBpZGxlOiAxMjZzIDgzMm1zCkRlYyAx NiAwOToxNDowNyB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHNyYy0+ dHN2YWw6IDMzNjg3NyAgdHNlY3I6IDE0MjQ3MTI5OTMKRGVjIDE2IDA5OjE0OjA3IHRoaXMga2Vy bmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgZHN0LT50c3ZhbDogMTQyNDcxMjk5MyAg dHNlY3I6IDMzNjY3MyAgdHN2YWwwOiAxNDI0NzEyOTg5CkRlYyAxNiAwOToxNDowNyB0aGlzIGtl cm5lbDogVENQIEEuQi5DLkQ6NTQ3NDYgQS5CLkMuRDo1NDc0NiBXLlguWS5aOjIyIFtsbz0yODQz NDM5NDA1IGhpZ2g9Mjg0MzUwNjAxNCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIFts bz0xNzg2ODU3MTQ2IGhpZ2g9MTc4NjkyMzc1NCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxl PTFdIDQ6NCBGQQoKRGVjIDE2IDA5OjE0OjA4IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNw X3N0YXRlZnVsOiBUaW1lc3RhbXAgZmFpbGVkICAxCkRlYyAxNiAwOToxNDowOCB0aGlzIGtlcm5l bDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogIHRzdmFsOiAxNDI0OTY5MDU1ICB0c2Vjcjog MzM2ODc3ICArdGlja3M6IDE3MzkzMSAgaWRsZTogMTI4cyAxMTltcwpEZWMgMTYgMDk6MTQ6MDgg dGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBzcmMtPnRzdmFsOiAxNDI0 NzEyOTkzICB0c2VjcjogMzM2NjczCkRlYyAxNiAwOToxNDowOCB0aGlzIGtlcm5lbDogcGZfbm9y bWFsaXplX3RjcF9zdGF0ZWZ1bDogIGRzdC0+dHN2YWw6IDMzNjg3NyAgdHNlY3I6IDE0MjQ3MTI5 OTMgIHRzdmFsMDogMzM2NjcyCkRlYyAxNiAwOToxNDowOCB0aGlzIGtlcm5lbDogVENQIEEuQi5D LkQ6NTQ3NDYgQS5CLkMuRDo1NDc0NiBXLlguWS5aOjIyIFtsbz0yODQzNDM5NDA1IGhpZ2g9Mjg0 MzUwNjAxNCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIFtsbz0xNzg2ODU3MTQ2IGhp Z2g9MTc4NjkyMzc1NCB3aW49MzMzMDQgbW9kdWxhdG9yPTAgd3NjYWxlPTFdIDQ6NCBGQQoKRGVj IDE2IDA5OjE0OjA4IHRoaXMga2VybmVsOiBwZjogQkFEIHN0YXRlOiBUQ1AgQS5CLkMuRDo1NDc0 NiBBLkIuQy5EOjU0NzQ2IFcuWC5ZLlo6MjIgW2xvPTI4NDM0Mzk0MDUgaGlnaD0yODQzNTA2MDE0 IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gW2xvPTE3ODY4NTcxNDYgaGlnaD0xNzg2 OTIzNzU0IHdpbj0zMzMwNCBtb2R1bGF0b3I9MCB3c2NhbGU9MV0gNDo0IFJBIHNlcT0yODQzNDM5 NDA1IGFjaz0xNzg2ODU3MTQ2IGxlbj0wIGFja3NrZXc9MCBwa3RzPTM6MiBkaXI9b3V0LGZ3ZApE ZWMgMTYgMDk6MTQ6MDggdGhpcyBrZXJuZWw6IHBmOiBTdGF0ZSBmYWlsdXJlIG9uOiAgICAgICAg IHwKCkRlYyAxNiAwOToxNDoxNSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1 bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTQ6MTUgdGhpcyBrZXJuZWw6IHBmX25v cm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogMTQyNDk4MjcwMyAgdHNlY3I6IDMzNjg3NyAg K3RpY2tzOiAxODE0NDIgIGlkbGU6IDEzNHMgOTQ3bXMKRGVjIDE2IDA5OjE0OjE1IHRoaXMga2Vy bmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMTQyNDcxMjk5MyAg dHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6MTUgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90 Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEyOTkzICB0c3Zh bDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6MTUgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2 IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQg d2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5 MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOTox NDoyOSB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZh aWxlZCAgMQpEZWMgMTYgMDk6MTQ6MjkgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3Rh dGVmdWw6ICB0c3ZhbDogMTQyNTAwOTU5OSAgdHNlY3I6IDMzNjg3NyAgK3RpY2tzOiAxOTYyNDUg IGlkbGU6IDE0OHMgNDA1bXMKRGVjIDE2IDA5OjE0OjI5IHRoaXMga2VybmVsOiBwZl9ub3JtYWxp emVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpE ZWMgMTYgMDk6MTQ6MjkgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBk c3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMg MTYgMDk6MTQ6MjkgdGhpcyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYg Vy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVs YXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0 IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNDo1NSB0aGlzIGtlcm5l bDogcGZfbm9ybWFsaXplX3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYg MDk6MTQ6NTUgdGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDog MTQyNTA2Mjk5MSAgdHNlY3I6IDMzNjg3NyAgK3RpY2tzOiAyMjU2MzAgIGlkbGU6IDE3NXMgMTE4 bXMKRGVjIDE2IDA5OjE0OjU1IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVs OiAgc3JjLT50c3ZhbDogMTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTQ6NTUg dGhpcyBrZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4 NzcgIHRzZWNyOiAxNDI0NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTQ6NTUgdGhp cyBrZXJuZWw6IFRDUCBBLkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89 Mjg0MzQzOTQwNSBoaWdoPTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0x XSBbbG89MTc4Njg1NzE0NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdz Y2FsZT0xXSA0OjQgRkEKCkRlYyAxNiAwOToxNTo0OCB0aGlzIGtlcm5lbDogcGZfbm9ybWFsaXpl X3RjcF9zdGF0ZWZ1bDogVGltZXN0YW1wIGZhaWxlZCAgMQpEZWMgMTYgMDk6MTU6NDggdGhpcyBr ZXJuZWw6IHBmX25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICB0c3ZhbDogMTQyNTE2OTM3NSAgdHNl Y3I6IDMzNjg3NyAgK3RpY2tzOiAyODQxODMgIGlkbGU6IDIyOHMgMzQ4bXMKRGVjIDE2IDA5OjE1 OjQ4IHRoaXMga2VybmVsOiBwZl9ub3JtYWxpemVfdGNwX3N0YXRlZnVsOiAgc3JjLT50c3ZhbDog MTQyNDcxMjk5MyAgdHNlY3I6IDMzNjY3MwpEZWMgMTYgMDk6MTU6NDggdGhpcyBrZXJuZWw6IHBm X25vcm1hbGl6ZV90Y3Bfc3RhdGVmdWw6ICBkc3QtPnRzdmFsOiAzMzY4NzcgIHRzZWNyOiAxNDI0 NzEyOTkzICB0c3ZhbDA6IDMzNjY3MgpEZWMgMTYgMDk6MTU6NDggdGhpcyBrZXJuZWw6IFRDUCBB LkIuQy5EOjU0NzQ2IEEuQi5DLkQ6NTQ3NDYgVy5YLlkuWjoyMiBbbG89Mjg0MzQzOTQwNSBoaWdo PTI4NDM1MDYwMTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSBbbG89MTc4Njg1NzE0 NiBoaWdoPTE3ODY5MjM3NTQgd2luPTMzMzA0IG1vZHVsYXRvcj0wIHdzY2FsZT0xXSA0OjQgRkEK --Multipart=_Fri__16_Dec_2005_10_09_15_-0600_7xXQ.VoZgyfQT9PN Content-Type: application/octet-stream; name="pfctl_-vsa" Content-Disposition: attachment; filename="pfctl_-vsa" Content-Transfer-Encoding: base64 RklMVEVSIFJVTEVTOgpzY3J1YiBhbGwgcmVhc3NlbWJsZSB0Y3AgZnJhZ21lbnQgcmVhc3NlbWJs ZQogIFsgRXZhbHVhdGlvbnM6IDI0NDQgICAgICBQYWNrZXRzOiAyNDQ0ICAgICAgQnl0ZXM6IDAg ICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIHF1aWNrIG9uIGxvMCBhbGwKICBbIEV2YWx1 YXRpb25zOiA3ODAgICAgICAgUGFja2V0czogMTgwICAgICAgIEJ5dGVzOiAxMzMyMCAgICAgICBT dGF0ZXM6IDAgICAgIF0KYmxvY2sgZHJvcCBpbiBsb2cgYWxsCiAgWyBFdmFsdWF0aW9uczogNzYw ICAgICAgIFBhY2tldHM6IDc3ICAgICAgICBCeXRlczogOTk1OSAgICAgICAgU3RhdGVzOiAwICAg ICBdCmJsb2NrIGRyb3AgaW4gbG9nIHF1aWNrIGZyb20gPEtOT1dOX0JBRF9IT1NUUz4gdG8gYW55 CiAgWyBFdmFsdWF0aW9uczogMzU5ICAgICAgIFBhY2tldHM6IDAgICAgICAgICBCeXRlczogMCAg ICAgICAgICAgU3RhdGVzOiAwICAgICBdCmJsb2NrIGRyb3Agb3V0IGxvZyBxdWljayBmcm9tIGFu eSB0byA8S05PV05fQkFEX0hPU1RTPgogIFsgRXZhbHVhdGlvbnM6IDc2MCAgICAgICBQYWNrZXRz OiAwICAgICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpibG9jayBkcm9w IGluIGxvZyBxdWljayBvbiAhIGxvMCBpbmV0NiBmcm9tIDo6MSB0byBhbnkKICBbIEV2YWx1YXRp b25zOiA3NjAgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0 ZXM6IDAgICAgIF0KYmxvY2sgZHJvcCBpbiBsb2cgcXVpY2sgb24gISBsbzAgaW5ldCBmcm9tIDEy Ny4wLjAuMC84IHRvIGFueQogIFsgRXZhbHVhdGlvbnM6IDM1OSAgICAgICBQYWNrZXRzOiAwICAg ICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpibG9jayBkcm9wIGluIGxv ZyBxdWljayBvbiAhIGJnZTAgaW5ldCBmcm9tIEEuQi5DLjE5Mi8yNiB0byBhbnkKICBbIEV2YWx1 YXRpb25zOiAzNTkgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBT dGF0ZXM6IDAgICAgIF0KYmxvY2sgZHJvcCBpbiBsb2cgcXVpY2sgb24gYmdlMCBpbmV0NiBmcm9t IGZlODA6OjIxMjozZmZmOmRlYWQ6YmVlZiB0byBhbnkKICBbIEV2YWx1YXRpb25zOiAzNTkgICAg ICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0K YmxvY2sgZHJvcCBpbiBsb2cgcXVpY2sgaW5ldCBmcm9tIEEuQi5DLkQgdG8gYW55CiAgWyBFdmFs dWF0aW9uczogMzU5ICAgICAgIFBhY2tldHM6IDAgICAgICAgICBCeXRlczogMCAgICAgICAgICAg U3RhdGVzOiAwICAgICBdCnBhc3MgaW4gb24gYmdlMCBpbmV0NiBwcm90byB0Y3AgZnJvbSA8TVlE T01BSU4+IHRvIGZlODA6OjIxMjozZmZmOmRlYWQ6YmVlZiBmbGFncyBTL1NBIGtlZXAgc3RhdGUK ICBbIEV2YWx1YXRpb25zOiAzNTkgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAg ICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBpbmV0IHByb3RvIHRjcCBmcm9tIDxNWURP TUFJTj4gdG8gQS5CLkMuRCBmbGFncyBTL1NBIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAz NTkgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAg ICAgIF0KcGFzcyBpbiBpbmV0NiBwcm90byB0Y3AgZnJvbSA8TVlET01BSU4+IHRvIDo6MSBmbGFn cyBTL1NBIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAwICAgICAgICAgUGFja2V0czogMCAg ICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBvbiBsbzAg aW5ldDYgcHJvdG8gdGNwIGZyb20gPE1ZRE9NQUlOPiB0byBmZTgwOjoxIGZsYWdzIFMvU0Ega2Vl cCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDAgICAgICAgICBQYWNrZXRzOiAwICAgICAgICAgQnl0 ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIGluIGluZXQgcHJvdG8gdGNwIGZy b20gPE1ZRE9NQUlOPiB0byAxMjcuMC4wLjEgZmxhZ3MgUy9TQSBrZWVwIHN0YXRlCiAgWyBFdmFs dWF0aW9uczogMCAgICAgICAgIFBhY2tldHM6IDAgICAgICAgICBCeXRlczogMCAgICAgICAgICAg U3RhdGVzOiAwICAgICBdCnBhc3MgaW4gb24gYmdlMCBpbmV0NiBwcm90byB1ZHAgZnJvbSA8TVlE T01BSU4+IHRvIGZlODA6OjIxMjozZmZmOmRlYWQ6YmVlZiBrZWVwIHN0YXRlCiAgWyBFdmFsdWF0 aW9uczogMzU5ICAgICAgIFBhY2tldHM6IDAgICAgICAgICBCeXRlczogMCAgICAgICAgICAgU3Rh dGVzOiAwICAgICBdCnBhc3MgaW4gaW5ldCBwcm90byB1ZHAgZnJvbSA8TVlET01BSU4+IHRvIEEu Qi5DLkQga2VlcCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDM1OSAgICAgICBQYWNrZXRzOiAwICAg ICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIGluIGluZXQ2IHBy b3RvIHVkcCBmcm9tIDxNWURPTUFJTj4gdG8gOjoxIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25z OiA3NyAgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6 IDAgICAgIF0KcGFzcyBpbiBvbiBsbzAgaW5ldDYgcHJvdG8gdWRwIGZyb20gPE1ZRE9NQUlOPiB0 byBmZTgwOjoxIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAwICAgICAgICAgUGFja2V0czog MCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBpbmV0 IHByb3RvIHVkcCBmcm9tIDxNWURPTUFJTj4gdG8gMTI3LjAuMC4xIGtlZXAgc3RhdGUKICBbIEV2 YWx1YXRpb25zOiA3NyAgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAg ICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBpbmV0IHByb3RvIGljbXAgZnJvbSA8TVlET01BSU4+ IHRvIEEuQi5DLkQga2VlcCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDM1OSAgICAgICBQYWNrZXRz OiAyODIgICAgICAgQnl0ZXM6IDE1NzkyICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIGluIGlu ZXQgcHJvdG8gaWNtcCBmcm9tIDxNWURPTUFJTj4gdG8gMTI3LjAuMC4xIGtlZXAgc3RhdGUKICBb IEV2YWx1YXRpb25zOiAyODIgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAg ICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBvbiBiZ2UwIGluZXQ2IHByb3RvIHRjcCBmcm9t IGFueSBwb3J0ID49IDEwMjQgdG8gZmU4MDo6MjEyOjNmZmY6ZGVhZDpiZWVmIHBvcnQgPSBzc2gg ZmxhZ3MgUy9TQSBrZWVwIHN0YXRlCiAgWyBFdmFsdWF0aW9uczogMzU5ICAgICAgIFBhY2tldHM6 IDAgICAgICAgICBCeXRlczogMCAgICAgICAgICAgU3RhdGVzOiAwICAgICBdCnBhc3MgaW4gaW5l dCBwcm90byB0Y3AgZnJvbSBhbnkgcG9ydCA+PSAxMDI0IHRvIEEuQi5DLkQgcG9ydCA9IHNzaCBm bGFncyBTL1NBIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAzNTkgICAgICAgUGFja2V0czog MCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBpbmV0 NiBwcm90byB0Y3AgZnJvbSBhbnkgcG9ydCA+PSAxMDI0IHRvIDo6MSBwb3J0ID0gc3NoIGZsYWdz IFMvU0Ega2VlcCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDAgICAgICAgICBQYWNrZXRzOiAwICAg ICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIGluIG9uIGxvMCBp bmV0NiBwcm90byB0Y3AgZnJvbSBhbnkgcG9ydCA+PSAxMDI0IHRvIGZlODA6OjEgcG9ydCA9IHNz aCBmbGFncyBTL1NBIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAwICAgICAgICAgUGFja2V0 czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBpbiBp bmV0IHByb3RvIHRjcCBmcm9tIGFueSBwb3J0ID49IDEwMjQgdG8gMTI3LjAuMC4xIHBvcnQgPSBz c2ggZmxhZ3MgUy9TQSBrZWVwIHN0YXRlCiAgWyBFdmFsdWF0aW9uczogMCAgICAgICAgIFBhY2tl dHM6IDAgICAgICAgICBCeXRlczogMCAgICAgICAgICAgU3RhdGVzOiAwICAgICBdCnBhc3MgaW4g aW5ldCBwcm90byBpY21wIGZyb20gYW55IHRvIEEuQi5DLkQgaWNtcC10eXBlIGVjaG9yZXEga2Vl cCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDM1OSAgICAgICBQYWNrZXRzOiAwICAgICAgICAgQnl0 ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIGluIGluZXQgcHJvdG8gaWNtcCBm cm9tIGFueSB0byAxMjcuMC4wLjEgaWNtcC10eXBlIGVjaG9yZXEga2VlcCBzdGF0ZQogIFsgRXZh bHVhdGlvbnM6IDI4MiAgICAgICBQYWNrZXRzOiAwICAgICAgICAgQnl0ZXM6IDAgICAgICAgICAg IFN0YXRlczogMCAgICAgXQpwYXNzIG91dCBvbiBiZ2UwIGluZXQ2IHByb3RvIHRjcCBmcm9tIGZl ODA6OjIxMjozZmZmOmRlYWQ6YmVlZiB0byBhbnkgZmxhZ3MgUy9TQSBrZWVwIHN0YXRlCiAgWyBF dmFsdWF0aW9uczogNzYwICAgICAgIFBhY2tldHM6IDAgICAgICAgICBCeXRlczogMCAgICAgICAg ICAgU3RhdGVzOiAwICAgICBdCnBhc3Mgb3V0IG9uIGJnZTAgaW5ldCBwcm90byB0Y3AgZnJvbSBB LkIuQy5EIHRvIGFueSBmbGFncyBTL1NBIGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAzOTcg ICAgICAgUGFja2V0czogMTkzICAgICAgIEJ5dGVzOiA1NzE0NCAgICAgICBTdGF0ZXM6IDEgICAg IF0KcGFzcyBvdXQgb24gYmdlMCBpbmV0NiBwcm90byB0Y3AgZnJvbSA6OjEgdG8gYW55IGZsYWdz IFMvU0Ega2VlcCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDggICAgICAgICBQYWNrZXRzOiAwICAg ICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIG91dCBvbiBiZ2Uw IGluZXQgcHJvdG8gdGNwIGZyb20gMTI3LjAuMC4xIHRvIGFueSBmbGFncyBTL1NBIGtlZXAgc3Rh dGUKICBbIEV2YWx1YXRpb25zOiA4ICAgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAw ICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBvdXQgb24gYmdlMCBpbmV0NiBwcm90byB1 ZHAgZnJvbSBmZTgwOjoyMTI6M2ZmZjpkZWFkOmJlZWYgdG8gYW55IGtlZXAgc3RhdGUKICBbIEV2 YWx1YXRpb25zOiA0MDEgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAg ICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBvdXQgb24gYmdlMCBpbmV0IHByb3RvIHVkcCBmcm9tIEEu Qi5DLkQgdG8gYW55IGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAzOTcgICAgICAgUGFja2V0 czogOTk4ICAgICAgIEJ5dGVzOiA5OTYxMiAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBvdXQg b24gYmdlMCBpbmV0NiBwcm90byB1ZHAgZnJvbSA6OjEgdG8gYW55IGtlZXAgc3RhdGUKICBbIEV2 YWx1YXRpb25zOiAxMDYgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAg ICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBvdXQgb24gYmdlMCBpbmV0IHByb3RvIHVkcCBmcm9tIDEy Ny4wLjAuMSB0byBhbnkga2VlcCBzdGF0ZQogIFsgRXZhbHVhdGlvbnM6IDEwNiAgICAgICBQYWNr ZXRzOiAwICAgICAgICAgQnl0ZXM6IDAgICAgICAgICAgIFN0YXRlczogMCAgICAgXQpwYXNzIG91 dCBvbiBiZ2UwIGluZXQgcHJvdG8gaWNtcCBmcm9tIEEuQi5DLkQgdG8gYW55IGtlZXAgc3RhdGUK ICBbIEV2YWx1YXRpb25zOiA0MDEgICAgICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAg ICAgICAgICBTdGF0ZXM6IDAgICAgIF0KcGFzcyBvdXQgb24gYmdlMCBpbmV0IHByb3RvIGljbXAg ZnJvbSAxMjcuMC4wLjEgdG8gYW55IGtlZXAgc3RhdGUKICBbIEV2YWx1YXRpb25zOiAwICAgICAg ICAgUGFja2V0czogMCAgICAgICAgIEJ5dGVzOiAwICAgICAgICAgICBTdGF0ZXM6IDAgICAgIF0K ClNUQVRFUzoKc2VsZiB0Y3AgQS5CLkMuRDo1NDc0NiAtPiBXLlguWS5aOjIyICAgICAgIEVTVEFC TElTSEVEOkVTVEFCTElTSEVECiAgIFsyODQzNDM5NDA1ICsgNjY2MDldIHdzY2FsZSAxICBbMTc4 Njg1NzE0NiArIDY2NjA4XSB3c2NhbGUgMQogICBhZ2UgMDA6Mjc6MDUsIGV4cGlyZXMgaW4gMjM6 MzI6NTUsIDM6MiBwa3RzLCAxNjg6MTU3IGJ5dGVzLCBydWxlIDM5CgpJTkZPOgpTdGF0dXM6IERp c2FibGVkIGZvciAwIGRheXMgMDA6MjE6MDUgICAgICAgICAgICBEZWJ1ZzogTG91ZAoKSG9zdGlk OiAweDA5MzBjM2E1CgpJbnRlcmZhY2UgU3RhdHMgZm9yIGJnZTAgICAgICAgICAgICAgIElQdjQg ICAgICAgICAgICAgSVB2NgogIEJ5dGVzIEluICAgICAgICAgICAgICAgICAgICAgICAgICAgODM0 NzUgICAgICAgICAgICAgICAgMAogIEJ5dGVzIE91dCAgICAgICAgICAgICAgICAgICAgICAgICAx ODQ3MjAgICAgICAgICAgICAgIDI4OAogIFBhY2tldHMgSW4KICAgIFBhc3NlZCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgNTE4ICAgICAgICAgICAgICAgIDAKICAgIEJsb2NrZWQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDkwICAgICAgICAgICAgICAgIDAKICBQYWNrZXRzIE91dAog ICAgUGFzc2VkICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEyMzggICAgICAgICAgICAgICAg NAogICAgQmxvY2tlZCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMTQgICAgICAgICAgICAg ICAgMAoKU3RhdGUgVGFibGUgICAgICAgICAgICAgICAgICAgICAgICAgIFRvdGFsICAgICAgICAg ICAgIFJhdGUKICBjdXJyZW50IGVudHJpZXMgICAgICAgICAgICAgICAgICAgICAgICAxICAgICAg ICAgICAgICAgCiAgc2VhcmNoZXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgMjA0NCAgICAg ICAgICAgIDEuNi9zCiAgaW5zZXJ0cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEzNCAg ICAgICAgICAgIDAuMS9zCiAgcmVtb3ZhbHMgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEz MyAgICAgICAgICAgIDAuMS9zClNvdXJjZSBUcmFja2luZyBUYWJsZQogIGN1cnJlbnQgZW50cmll cyAgICAgICAgICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAgICAKICBzZWFyY2hlcyAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBpbnNlcnRzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICByZW1vdmFs cyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKQ291bnRl cnMKICBtYXRjaCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNzgwICAgICAgICAgICAg MC42L3MKICBiYWQtb2Zmc2V0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAg ICAgMC4wL3MKICBmcmFnbWVudCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAg ICAgICAgMC4wL3MKICBzaG9ydCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAg ICAgICAgICAgMC4wL3MKICBub3JtYWxpemUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAw ICAgICAgICAgICAgMC4wL3MKICBtZW1vcnkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAwICAgICAgICAgICAgMC4wL3MKICBiYWQtdGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAg ICAgIDI2ICAgICAgICAgICAgMC4wL3MKICBjb25nZXN0aW9uICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBpcC1vcHRpb24gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBwcm90by1ja3N1bSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBzdGF0ZS1taXNtYXRjaCAgICAgICAg ICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgMC4wL3MKICBzdGF0ZS1pbnNlcnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBzdGF0ZS1saW1pdCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBzcmMtbGltaXQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKICBzeW5wcm94eSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAgICAgICAgMC4wL3MKTGltaXQgQ291 bnRlcnMKICBtYXggc3RhdGVzIHBlciBydWxlICAgICAgICAgICAgICAgICAgICAwICAgICAgICAg ICAgMC4wL3MKICBtYXgtc3JjLXN0YXRlcyAgICAgICAgICAgICAgICAgICAgICAgICAwICAgICAg ICAgICAgMC4wL3MKICBtYXgtc3JjLW5vZGVzICAgICAgICAgICAgICAgICAgICAgICAgICAwICAg ICAgICAgICAgMC4wL3MKICBtYXgtc3JjLWNvbm4gICAgICAgICAgICAgICAgICAgICAgICAgICAw ICAgICAgICAgICAgMC4wL3MKICBtYXgtc3JjLWNvbm4tcmF0ZSAgICAgICAgICAgICAgICAgICAg ICAwICAgICAgICAgICAgMC4wL3MKICBvdmVybG9hZCB0YWJsZSBpbnNlcnRpb24gICAgICAgICAg ICAgICAwICAgICAgICAgICAgMC4wL3MKICBvdmVybG9hZCBmbHVzaCBzdGF0ZXMgICAgICAgICAg ICAgICAgICAwICAgICAgICAgICAgMC4wL3MKClRJTUVPVVRTOgp0Y3AuZmlyc3QgICAgICAgICAg ICAgICAgICAgMTIwcwp0Y3Aub3BlbmluZyAgICAgICAgICAgICAgICAgIDMwcwp0Y3AuZXN0YWJs aXNoZWQgICAgICAgICAgIDg2NDAwcwp0Y3AuY2xvc2luZyAgICAgICAgICAgICAgICAgOTAwcwp0 Y3AuZmlud2FpdCAgICAgICAgICAgICAgICAgIDQ1cwp0Y3AuY2xvc2VkICAgICAgICAgICAgICAg ICAgIDkwcwp0Y3AudHNkaWZmICAgICAgICAgICAgICAgICAgIDMwcwp1ZHAuZmlyc3QgICAgICAg ICAgICAgICAgICAgIDYwcwp1ZHAuc2luZ2xlICAgICAgICAgICAgICAgICAgIDMwcwp1ZHAubXVs dGlwbGUgICAgICAgICAgICAgICAgIDYwcwppY21wLmZpcnN0ICAgICAgICAgICAgICAgICAgIDIw cwppY21wLmVycm9yICAgICAgICAgICAgICAgICAgIDEwcwpvdGhlci5maXJzdCAgICAgICAgICAg ICAgICAgIDYwcwpvdGhlci5zaW5nbGUgICAgICAgICAgICAgICAgIDMwcwpvdGhlci5tdWx0aXBs ZSAgICAgICAgICAgICAgIDYwcwpmcmFnICAgICAgICAgICAgICAgICAgICAgICAgIDMwcwppbnRl cnZhbCAgICAgICAgICAgICAgICAgICAgIDEwcwphZGFwdGl2ZS5zdGFydCAgICAgICAgICAgICAg ICAwIHN0YXRlcwphZGFwdGl2ZS5lbmQgICAgICAgICAgICAgICAgICAwIHN0YXRlcwpzcmMudHJh Y2sgICAgICAgICAgICAgICAgICAgICAwcwoKTElNSVRTOgpzdGF0ZXMgICAgIGhhcmQgbGltaXQg IDEwMDAwCnNyYy1ub2RlcyAgaGFyZCBsaW1pdCAgMTAwMDAKZnJhZ3MgICAgICBoYXJkIGxpbWl0 ICAgNTAwMAoKVEFCTEVTOgotcGEtci0JQ0xJRU5UUwotcGEtci0JS05PV05fQkFEX0hPU1RTCi1w YS1yLQlNWURPTUFJTgoKT1MgRklOR0VSUFJJTlRTOgozNDUgZmluZ2VycHJpbnRzIGxvYWRlZAo= --Multipart=_Fri__16_Dec_2005_10_09_15_-0600_7xXQ.VoZgyfQT9PN-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 16:17:11 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 CFD1C16A41F for ; Fri, 16 Dec 2005 16:17:11 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from tehran.lain.pl (tehran.lain.pl [85.221.230.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD17443D67 for ; Fri, 16 Dec 2005 16:17:10 +0000 (GMT) (envelope-from weirdo@tehran.lain.pl) Received: from weirdo by tehran.lain.pl with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1EnIGY-000FiD-Uq for freebsd-pf@freebsd.org; Fri, 16 Dec 2005 17:17:07 +0100 Date: Fri, 16 Dec 2005 17:17:06 +0100 From: Stanislaw Halik To: freebsd-pf@freebsd.org Message-ID: <20051216161706.GA60338@tehran.lain.pl> References: <20051216154133.182bab4f.nikky@mnet.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="82I3+IH0IqGh5yIs" Content-Disposition: inline In-Reply-To: <20051216154133.182bab4f.nikky@mnet.bg> X-PGP-Key: http://tehran.lain.pl/public.key User-Agent: Mutt/1.5.11 Subject: Re: altq and max number of classes on xBSD 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, 16 Dec 2005 16:17:11 -0000 --82I3+IH0IqGh5yIs Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Nickola Kolev wrote: > Finally, my question is is there a way to raise the maximum number of > classes in a hierarchy (besides the artificial change in altq_hfsc.h > and altq_cbq.h)? How stable would a system like that be? there are no stability issues involved. and you don't have to change the limit in schedulers which you don't use. > If you have any suggestions for a setup, which can do the job of > traffic controlling /19 with a hierarchy of classes, each with > different guaranteed and maximum rates, I'd be very grateful. i'd suggest using HFSC scheduler, with CBQ you have no control over bandwidth borrowing. i've also heard about large and unnessesary packet delay (not present in HSFC), but nothing i could confirm myself. --=20 Stanis=B3aw Halik, http://tehran.lain.pl --82I3+IH0IqGh5yIs Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDouiCadU+vjT62TERAgcGAJ40ld1IzNR5oKWZkJDn0nc6LiZ8qACeIU5C 3owo1lUWO1eKoENXPxeLE30= =rX9l -----END PGP SIGNATURE----- --82I3+IH0IqGh5yIs-- From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 16:26: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 8552316A433 for ; Fri, 16 Dec 2005 16:26:33 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 0394043DD0 for ; Fri, 16 Dec 2005 16:26:09 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 3397 invoked by uid 89); 16 Dec 2005 16:25:50 -0000 Received: from unknown (HELO warped) (192.168.1.166) by warped.ro with SMTP; 16 Dec 2005 16:25:50 -0000 Message-ID: <000f01c6025d$6decd710$a601a8c0@warped> From: "Robert" To: Date: Fri, 16 Dec 2005 18:26:12 +0200 MIME-Version: 1.0 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 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: mrtg 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, 16 Dec 2005 16:26:33 -0000 does anybody know a good guid to set up mrtg it's killing me From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 18:34:55 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 6409A16A43D for ; Fri, 16 Dec 2005 18:34:55 +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 6AF6F43D64 for ; Fri, 16 Dec 2005 18:34:52 +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 jBGIYmIY006327 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 19:34:48 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jBGIYm8E015224; Fri, 16 Dec 2005 19:34:48 +0100 (MET) Date: Fri, 16 Dec 2005 19:34:47 +0100 From: Daniel Hartmeier To: Paul Dokas Message-ID: <20051216183447.GA14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216100915.73fef758.dokas@oitsec.umn.edu> User-Agent: Mutt/1.5.10i Cc: frantzen@openbsd.org, freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems 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, 16 Dec 2005 18:34:55 -0000 On Fri, Dec 16, 2005 at 10:09:15AM -0600, Paul Dokas wrote: > I recently upgrade to FreeBSD 6.0 via a full reinstall and I've run into a very > strange problem with PF. First of all, I'm using the same PF ruleset that I > used on 5.4. I know for a fact that it works correctly there. This is related to TCP timestamp checks which were introduced in OpenBSD on May 5 2004 [1]. They were not part of FreeBSD 5.4 [2], because that branched from OpenBSD 3.6 (before the change), but got merged later, making it into FreeBSD 6.0. The additional checks are automatically enabled when using "reassemble tcp", which explains why the same ruleset didn't block the packets on 5.4 but now does on 6.0. You can disable "reassemble tcp" and the new (and old) TCP checks won't run. See the updated pf.conf(5) man page for a full list of checks that this feature enables/disables. The question now is whether your traffic is valid (and the timestamp checks are wrong), or whether the traffic is invalid and the checks rightfully block the packets. Let's see. 09:12:00.516180 IP this.host.umn.edu.54746 > that.host.umn.edu.ssh: S 2843439405:2843439405(0) win 65535 09:12:00.516597 IP that.host.umn.edu.ssh > this.host.umn.edu.54746: S 1786857104:1786857104(0) ack 2843439406 win 65535 09:12:00.516664 IP this.host.umn.edu.54746 > that.host.umn.edu.ssh: . ack 1 win 33304 09:12:00.518506 IP that.host.umn.edu.ssh > this.host.umn.edu.54746: P 1:42(41) ack 1 win 33304 09:12:00.618331 IP this.host.umn.edu.54746 > that.host.umn.edu.ssh: . ack 42 win 33304 09:14:00.601413 IP that.host.umn.edu.ssh > this.host.umn.edu.54746: F 42:42(0) ack 1 win 33304 The last packet above is blocked by pf, which gives the following reason: pf_normalize_tcp_stateful: Timestamp failed 1 pf_normalize_tcp_stateful: tsval: 1424952994 tsecr: 336877 +ticks: 165091 idle: 120s 82ms pf_normalize_tcp_stateful: src->tsval: 1424712993 tsecr: 336673 pf_normalize_tcp_stateful: dst->tsval: 336877 tsecr: 1424712993 tsval0: 336672 TCP A.B.C.D:54746 A.B.C.D:54746 W.X.Y.Z:22 [lo=2843439405 high=2843506014 win=33304 modulator=0 wscale=1] [lo=1786857146 high=1786923754 win=33304 modulator=0 wscale=1] 4:4 FA Which means the following condition was violated: SEQ_GT(tsval, src->scrub->pfss_tsval + tsval_from_last) because 1424952994 > 1424712993 + 165091 (== 1424878084) >From the logged values and the source code we can deduce that the last two packets from the SSH server (that.host) to the client (this.host) were seen (by pf, in the kernel) exactly delta_ts.tv_sec == 120 delta_ts.tv_usec == 82719 apart. This approximately matches the difference in the bpf log, too. So, between those two subsequent packets, the server incremented its timestamp by delta_tsval == 1424952994 - 1424712993 == 240001 within the timespan of delta_usec == 120 * 1000000 + 82719 == 2082719 which means it incremented its timestamp with a frequency of about ts_freq == 240001 / 2082719 usec ~= 115 kHz This is much higher than what pf allows, because RFC1323 [3] (section 4.2.2) says the maximum clock rate is 10 kHz. Even with some fudge applied (pf allows 10% clock skew plus 30s for routing delays), the frequency seen is too high. If you have this problem with only specific hosts, try to find out what OS they are using. If you feel that their timestamp implementation is really RFC1323 conformant and pf is at fault, please argue about it with Mike Frantzen , who wrote these checks :) If you don't care who's right, and just want connections to work to these hosts (even if they're at fault), exclude them from the 'scrub reassemble tcp' rule. If you can't pin down the set of peers that might fall in this category, disable 'reassemble tcp' completely. If you would have liked to enable just the check that 'reassemble tcp' enabled in 5.4, but not the new timestamp checks in 6.0, you're out of luck. HTH, Daniel [1] http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/pf_norm.c (revision 1.85) [2] http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf_norm.c (revision 1.10) [3] http://www.faqs.org/rfcs/rfc1323.html From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:05: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 22D6516A42B for ; Fri, 16 Dec 2005 19:05:05 +0000 (GMT) (envelope-from frantzen@openbsd.org) Received: from vorlon.w4g.org (vorlon.w4g.org [144.202.240.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 83D8C43D4C for ; Fri, 16 Dec 2005 19:05:04 +0000 (GMT) (envelope-from frantzen@openbsd.org) Received: from valen.localhost (localhost.w4g.org [127.0.0.1]) by vorlon.w4g.org (8.13.0/8.12.11) with ESMTP id jBGJ4t7H029650; Fri, 16 Dec 2005 14:04:55 -0500 (EST) Received: by valen.localhost (Postfix, from userid 501) id 21D271CD34E; Fri, 16 Dec 2005 14:04:55 -0500 (EST) Date: Fri, 16 Dec 2005 14:04:54 -0500 From: Mike Frantzen To: Daniel Hartmeier Message-ID: <20051216190454.GF474@w4g.org> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216183447.GA14269@insomnia.benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems 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, 16 Dec 2005 19:05:05 -0000 > >From the logged values and the source code we can deduce that the last > two packets from the SSH server (that.host) to the client (this.host) > were seen (by pf, in the kernel) exactly > delta_ts.tv_sec == 120 > delta_ts.tv_usec == 82719 > apart. This approximately matches the difference in the bpf log, too. > So, between those two subsequent packets, the server incremented its > timestamp by > delta_tsval == 1424952994 - 1424712993 == 240001 > within the timespan of > delta_usec == 120 * 1000000 + 82719 == 2082719 > which means it incremented its timestamp with a frequency of about > ts_freq == 240001 / 2082719 usec ~= 115 kHz If I was to see this in the wild I would conclude it's a blind hijacking attempt. If a spoofer gets a packet inside the sequence window with a significantly higher timestamp then the victim will start ignoring the packets from the original host with the smaller timestamps. That lets the blind spoofer take over the TCP connection without the ACK storm that typically results from out-of-line hjiacking. .mike frantzen@(nfr.com | cvs.openbsd.org | w4g.org) PGP: CC A4 E2 E8 0C F8 42 F0 BC 26 85 5B 6F 9E ED 28 From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:18:39 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 D87F716A41F for ; Fri, 16 Dec 2005 19:18:39 +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 0A08843D5F for ; Fri, 16 Dec 2005 19:18:33 +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 jBGJIWtT008971 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 20:18:32 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jBGJIWvD014619; Fri, 16 Dec 2005 20:18:32 +0100 (MET) Date: Fri, 16 Dec 2005 20:18:31 +0100 From: Daniel Hartmeier To: Mike Frantzen Message-ID: <20051216191831.GB14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> <20051216190454.GF474@w4g.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216190454.GF474@w4g.org> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems 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, 16 Dec 2005 19:18:40 -0000 On Fri, Dec 16, 2005 at 02:04:54PM -0500, Mike Frantzen wrote: > > So, between those two subsequent packets, the server incremented its > > timestamp by > > delta_tsval == 1424952994 - 1424712993 == 240001 > > within the timespan of > > delta_usec == 120 * 1000000 + 82719 == 2082719 Wait, that's wrong. 120 * 1000000 + 82719 == 120082719, giving a frequency of a mere 200 Hz. What other mistake did I make? :) Daniel From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:18: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 8CF1E16A41F for ; Fri, 16 Dec 2005 19:18:57 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 9A94A43D45 for ; Fri, 16 Dec 2005 19:18:56 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 6418 invoked by uid 89); 16 Dec 2005 19:18:37 -0000 Received: from localhost (HELO warped.ro) (127.0.0.1) by warped.ro with SMTP; 16 Dec 2005 19:18:37 -0000 Received: from 192.168.1.166 (SquirrelMail authenticated user link@warped.ro) by warped.ro with HTTP; Fri, 16 Dec 2005 21:18:37 +0200 (EET) Message-ID: <64433.192.168.1.166.1134760717.squirrel@warped.ro> In-Reply-To: <43A304E3.8080207@gmail.com> References: <000f01c6025d$6decd710$a601a8c0@warped> <43A304E3.8080207@gmail.com> Date: Fri, 16 Dec 2005 21:18:37 +0200 (EET) From: link@warped.ro To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: mrtg 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, 16 Dec 2005 19:18:57 -0000 > Robert rta: > >>does anybody know a good guid to set up mrtg >>it's killing me >>_______________________________________________ >>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" >> >> >> > what do you want to monitor? > > i want to monitor network traffic for 4 ips the snmp documentation is hard to get for me as i never worked with snmp i am not asking for a full solution.. but only for clear documentation 10x From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:34:30 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 CD8EC16A41F for ; Fri, 16 Dec 2005 19:34:30 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2DC943D77 for ; Fri, 16 Dec 2005 19:34:23 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from localhost (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id E947C1CC02F; Fri, 16 Dec 2005 13:34:20 -0600 (CST) Received: from mail.oitsec.umn.edu ([127.0.0.1]) by localhost (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73995-01; Fri, 16 Dec 2005 13:34:20 -0600 (CST) Received: from shoggoth.oitsec.umn.edu (shoggoth.oitsec.umn.edu [160.94.247.195]) by mail.oitsec.umn.edu (Postfix) with ESMTP id A4FE11CC027; Fri, 16 Dec 2005 13:34:20 -0600 (CST) Date: Fri, 16 Dec 2005 13:34:17 -0600 From: Paul Dokas To: Daniel Hartmeier Message-Id: <20051216133417.2d8dee1a.dokas@oitsec.umn.edu> In-Reply-To: <20051216183447.GA14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> Organization: OIT Security and Assurance, University of Minnesota X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) X-Discordia: fnord Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at oitsec.umn.edu Cc: freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dokas@oitsec.umn.edu 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, 16 Dec 2005 19:34:31 -0000 On Fri, 16 Dec 2005 19:34:47 +0100 Daniel Hartmeier wrote: > The additional checks are automatically enabled when using "reassemble > tcp", which explains why the same ruleset didn't block the packets on > 5.4 but now does on 6.0. You can disable "reassemble tcp" and the new > (and old) TCP checks won't run. See the updated pf.conf(5) man page for > a full list of checks that this feature enables/disables. I can confirm this. I'm now running with PF enable and the following scrub rule: scrub all fragment reassemble The previous rule was 'scrub all reassemble tcp' and was the source(?) of the problem. I'm still digging to find where the problem is located. It's rather slow going as we have a fairly diverse and complex network installation. The one place that I'm currently looking at is the FreeBSd 5.4 machine acting as a bridging firewall that is immediately upstream from me. Paul -- Paul Dokas dokas at oitsec.umn.edu ====================================================================== Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla." From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:38:40 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 2602516A41F for ; Fri, 16 Dec 2005 19:38:40 +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 0597A43D82 for ; Fri, 16 Dec 2005 19:38:31 +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 jBGJcVYu024580 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 20:38:31 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jBGJcVUq019300; Fri, 16 Dec 2005 20:38:31 +0100 (MET) Date: Fri, 16 Dec 2005 20:38:30 +0100 From: Daniel Hartmeier To: Mike Frantzen Message-ID: <20051216193830.GC14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> <20051216190454.GF474@w4g.org> <20051216191831.GB14269@insomnia.benzedrine.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216191831.GB14269@insomnia.benzedrine.cx> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems 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, 16 Dec 2005 19:38:40 -0000 Doh. delta_tsval == 1424952994 - 1424712993 == 240001 delta_time == 120082719 us (120.082719 s) freq == delta_tsval / delta_time == 240001 / 120.082719 == 240001 * 1000000 / 120082719 == 1998 Hz (> 1000 Hz) So it's not that far off, the server seems to increment timestamps at 0.5 ms per tick (2 kHz), instead of the RFC mandated 1 ms (1 kHz). Daniel From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 19:48: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 9023E16A41F for ; Fri, 16 Dec 2005 19:48:08 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from mail.oitsec.umn.edu (mail.oitsec.umn.edu [128.101.238.120]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6528743D7C for ; Fri, 16 Dec 2005 19:48:06 +0000 (GMT) (envelope-from dokas@oitsec.umn.edu) Received: from localhost (localhost [127.0.0.1]) by mail.oitsec.umn.edu (Postfix) with ESMTP id 4BECD1CC02F; Fri, 16 Dec 2005 13:48:00 -0600 (CST) Received: from mail.oitsec.umn.edu ([127.0.0.1]) by localhost (mail.oitsec.umn.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74627-04; Fri, 16 Dec 2005 13:47:59 -0600 (CST) Received: from shoggoth.oitsec.umn.edu (shoggoth.oitsec.umn.edu [160.94.247.195]) by mail.oitsec.umn.edu (Postfix) with ESMTP id E40791CC027; Fri, 16 Dec 2005 13:47:59 -0600 (CST) Date: Fri, 16 Dec 2005 13:47:59 -0600 From: Paul Dokas To: Daniel Hartmeier Message-Id: <20051216134759.795206f3.dokas@oitsec.umn.edu> In-Reply-To: <20051216193830.GC14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> <20051216190454.GF474@w4g.org> <20051216191831.GB14269@insomnia.benzedrine.cx> <20051216193830.GC14269@insomnia.benzedrine.cx> Organization: OIT Security and Assurance, University of Minnesota X-Mailer: Sylpheed version 2.0.4 (GTK+ 2.8.7; i386-portbld-freebsd6.0) X-Discordia: fnord Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at oitsec.umn.edu Cc: frantzen@openbsd.org, freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dokas@oitsec.umn.edu 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, 16 Dec 2005 19:48:08 -0000 On Fri, 16 Dec 2005 20:38:30 +0100 Daniel Hartmeier wrote: > Doh. > > delta_tsval == 1424952994 - 1424712993 == 240001 > delta_time == 120082719 us (120.082719 s) > > freq == delta_tsval / delta_time > == 240001 / 120.082719 > == 240001 * 1000000 / 120082719 > == 1998 Hz (> 1000 Hz) > > So it's not that far off, the server seems to increment timestamps at > 0.5 ms per tick (2 kHz), instead of the RFC mandated 1 ms (1 kHz). > > Daniel Bingo (I think). I found the following in the firewall's kernel config: options HZ=2000 I'm going to get than changed and see if the problem goes away. I really appreciate the help! Paul -- Paul Dokas dokas at oitsec.umn.edu ====================================================================== Don Juan Matus: "an enigma wrapped in mystery wrapped in a tortilla." From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 20:18:58 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 5006B16A41F for ; Fri, 16 Dec 2005 20:18:58 +0000 (GMT) (envelope-from link@warped.ro) Received: from warped.ro (warped.ro [86.104.85.254]) by mx1.FreeBSD.org (Postfix) with SMTP id 6451F43D58 for ; Fri, 16 Dec 2005 20:18:57 +0000 (GMT) (envelope-from link@warped.ro) Received: (qmail 17136 invoked by uid 89); 16 Dec 2005 20:18:35 -0000 Received: from localhost (HELO warped.ro) (127.0.0.1) by warped.ro with SMTP; 16 Dec 2005 20:18:35 -0000 Received: from 192.168.1.166 (SquirrelMail authenticated user link@warped.ro) by warped.ro with HTTP; Fri, 16 Dec 2005 22:18:35 +0200 (EET) Message-ID: <55348.192.168.1.166.1134764315.squirrel@warped.ro> In-Reply-To: <43A31B30.4040601@gmail.com> References: <000f01c6025d$6decd710$a601a8c0@warped> <43A304E3.8080207@gmail.com> <64433.192.168.1.166.1134760717.squirrel@warped.ro> <43A31B30.4040601@gmail.com> Date: Fri, 16 Dec 2005 22:18:35 +0200 (EET) From: link@warped.ro To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: Re: mrtg 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, 16 Dec 2005 20:18:58 -0000 > http://mrtg.dawntempo.net/rrd/ > > like this? > > > > link@warped.ro rta: > >>>Robert rta: >>> >>> >>> >>>>does anybody know a good guid to set up mrtg >>>>it's killing me >>>>_______________________________________________ >>>>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" >>>> >>>> >>>> >>>> >>>> >>>what do you want to monitor? >>> >>> >>> >>> >>i want to monitor network traffic for 4 ips >>the snmp documentation is hard to get for me >>as i never worked with snmp >>i am not asking for a full solution.. but only >>for clear documentation >>10x >> >>_______________________________________________ >>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" >> >> >> > > yes. that would be great From owner-freebsd-pf@FreeBSD.ORG Fri Dec 16 21:17:58 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 BD9D316A420 for ; Fri, 16 Dec 2005 21:17:58 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6630D43D55 for ; Fri, 16 Dec 2005 21:17:58 +0000 (GMT) (envelope-from Greg.Hennessy@nviz.net) Received: from gw2.local.net (unknown [62.3.210.253]) by smtp.nildram.co.uk (Postfix) with ESMTP id 72F4526A582 for ; Fri, 16 Dec 2005 21:17:46 +0000 (GMT) From: "Greg Hennessy" To: "'Robert'" Date: Fri, 16 Dec 2005 21:17:47 -0000 Message-ID: <000001c60286$29d5f9c0$0a00a8c0@thebeast> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYCcxaV+lzRdjnJQlaQkGmYip2aKgAEueog In-Reply-To: <000f01c6025d$6decd710$a601a8c0@warped> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Cc: freebsd-pf@freebsd.org Subject: RE: mrtg 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, 16 Dec 2005 21:17:58 -0000 > does anybody know a good guid to set up mrtg it's killing me I would strongly counsel against using MRTG, http://www.cacti.net/ Is trivial to setup and far easier to manage. Greg From owner-freebsd-pf@FreeBSD.ORG Sat Dec 17 06:00: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 11C5B16A41F for ; Sat, 17 Dec 2005 06:00:31 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from ms-smtp-03-eri0.ohiordc.rr.com (ms-smtp-03-smtplb.ohiordc.rr.com [65.24.5.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8903143D5E for ; Sat, 17 Dec 2005 06:00:30 +0000 (GMT) (envelope-from dmehler26@woh.rr.com) Received: from satellite (cpe-65-185-179-246.woh.res.rr.com [65.185.179.246]) by ms-smtp-03-eri0.ohiordc.rr.com (8.12.10/8.12.7) with SMTP id jBH60QYF009029; Sat, 17 Dec 2005 01:00:27 -0500 (EST) Message-ID: <003001c602ce$0c8a3320$6409a8c0@satellite> From: "Dave" To: Date: Sat, 17 Dec 2005 00:52:21 -0500 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.2670 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: openvpn-users@lists.sourceforge.net Subject: freebsd openvpn and firewall protocols X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dave 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, 17 Dec 2005 06:00:31 -0000 Hello, I'm running openvpn via ports on a freebsd6 machine. This box is natted behind another freebsd6 box which uses pf as it's firewall. I've got windows clients that are outside the firewall with openvpn windows client. I was getting an error about tls parameters failed to be negotiated within 60 seconds and the connections kept failing. This was with udp. I'm wondering if this is a nat issue, if the connection can not be natted. I changed proto udp to proto tcp in both the client and server, restarted the server, and this time it connected. I checked ipconfig on the client and it did have two ip addresses, a 192.168.2.0/24 address for the wired nic connected to the network the box is on, and a 192.168.9.0/24 ip for the vpn_tap adapter. My second issue is i can not do anything with the remote network, pinging the remote server via ip or dns name failed, and windows file sharing also did not work. I'm wondering if this is an issue with nat or routing? I've got ethernet bridging set up. Thanks. Dave. From owner-freebsd-pf@FreeBSD.ORG Sat Dec 17 08:01:20 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 A893516A41F for ; Sat, 17 Dec 2005 08:01:20 +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 D6EB243D5D for ; Sat, 17 Dec 2005 08:01:19 +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 jBH80qtw015776 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sat, 17 Dec 2005 09:00:53 +0100 (MET) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id jBH80p9O014583; Sat, 17 Dec 2005 09:00:51 +0100 (MET) Date: Sat, 17 Dec 2005 09:00:48 +0100 From: Daniel Hartmeier To: Paul Dokas Message-ID: <20051217080048.GE14269@insomnia.benzedrine.cx> References: <20051216100915.73fef758.dokas@oitsec.umn.edu> <20051216183447.GA14269@insomnia.benzedrine.cx> <20051216190454.GF474@w4g.org> <20051216191831.GB14269@insomnia.benzedrine.cx> <20051216193830.GC14269@insomnia.benzedrine.cx> <20051216134759.795206f3.dokas@oitsec.umn.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051216134759.795206f3.dokas@oitsec.umn.edu> User-Agent: Mutt/1.5.10i Cc: frantzen@openbsd.org, freebsd-pf@freebsd.org Subject: Re: very odd PF + FreeBSD6.0 problems 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, 17 Dec 2005 08:01:20 -0000 On Fri, Dec 16, 2005 at 01:47:59PM -0600, Paul Dokas wrote: > Bingo (I think). I found the following in the firewall's kernel config: > > options HZ=2000 > > I'm going to get than changed and see if the problem goes away. I just discovered that this seems to be a know problem with setting HZ, if only I had searched earlier ;) Subject: 6-STABLE: HZ>1000, RFC1323 non-compliance, and PF http://marc.theaimsgroup.com/?t=113476573600004&r=1&w=2 Problem Report kern/61404 : RFC1323 timestamps with HZ > 1000 http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/61404 It appears that this is related to the HZ setting on your SSH server (i.e. one of the TCP endpoints) not any HZ setting on the kernel pf runs on itself (so it requires a fix in the generic TCP code, not within pf). Daniel From owner-freebsd-pf@FreeBSD.ORG Sat Dec 17 15:10:11 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 D726416A41F for ; Sat, 17 Dec 2005 15:10:11 +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 9C57A43D55 for ; Sat, 17 Dec 2005 15:10:11 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id jBHFAB0M055419 for ; Sat, 17 Dec 2005 15:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id jBHFABIb055418; Sat, 17 Dec 2005 15:10:11 GMT (envelope-from gnats) Date: Sat, 17 Dec 2005 15:10:11 GMT Message-Id: <200512171510.jBHFABIb055418@freefall.freebsd.org> To: freebsd-pf@FreeBSD.org From: "Ricardo A. Reis" Cc: Subject: Re: kern/84370: [modules] Unload pf.ko cause page fault X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Ricardo A. Reis" 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, 17 Dec 2005 15:10:12 -0000 The following reply was made to PR kern/84370; it has been noted by GNATS. From: "Ricardo A. Reis" To: bug-followup@FreeBSD.org, ricardo_bsd@yahoo.com.br Cc: Subject: Re: kern/84370: [modules] Unload pf.ko cause page fault Date: Sat, 17 Dec 2005 13:09:01 -0200 ------=_Part_1006_20357404.1134832141611 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, After severals stress test with this pr in RELENG_6, the status of this pr can be changed for closed. Thanks -- Ricardo A. Reis UNIFESP Unix and Network Admin ------=_Part_1006_20357404.1134832141611 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi,

   After severals stress test with this pr in RELENG_6, the statu= s of this pr can be changed for closed.
 

Thanks

--
Ricardo A. Reis
UNIFESP
Unix and Network Admin
------=_Part_1006_20357404.1134832141611-- From owner-freebsd-pf@FreeBSD.ORG Sat Dec 17 15:20:22 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 3F95C16A41F for ; Sat, 17 Dec 2005 15:20:22 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from iscan1.intra.oki.co.jp (okigate.oki.co.jp [202.226.91.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id BF43743D5C for ; Sat, 17 Dec 2005 15:20:16 +0000 (GMT) (envelope-from yamamoto436@oki.com) Received: from aoi.bmc.oki.co.jp (localhost.localdomain [127.0.0.1]) by iscan1.intra.oki.co.jp (8.9.3/8.9.3) with SMTP id AAA18844 for ; Sun, 18 Dec 2005 00:20:14 +0900 Received: (qmail 26574 invoked from network); 18 Dec 2005 00:20:14 +0900 Received: from tulip.bmc.oki.co.jp (172.19.236.119) by aoi.bmc.oki.co.jp with SMTP; 18 Dec 2005 00:20:14 +0900 Received: from localhost (tulip.bmc.oki.co.jp [172.19.236.119]) by tulip.bmc.oki.co.jp (8.13.4/8.13.3) with ESMTP id jBHFKDP0033316; Sun, 18 Dec 2005 00:20:13 +0900 (JST) (envelope-from yamamoto436@oki.com) Date: Sun, 18 Dec 2005 00:20:12 +0900 (JST) Message-Id: <20051218.002012.74721675.yamamoto436@oki.com> To: thompsa@freebsd.org From: Hideki Yamamoto In-Reply-To: <20051213195624.GA5248@heff.fud.org.nz> References: <20051213170450.3CD41193631@mail.nl-hrln-ptgrf.net> <20051213195624.GA5248@heff.fud.org.nz> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: michiel@nl-hrln-ptgrf.net, freebsd-pf@freebsd.org Subject: Re: Possible bug in PF with if_bridge 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, 17 Dec 2005 15:20:22 -0000 Hi, I am also struggling with pf with if_bridge for RTP on ipv6. I have found a pointer of pf+bridge by searching google. That is http://lists.freebsd.org/pipermail/freebsd-pf/2005-January/000762.html. I have not tried it yet. I hope you will respond your result to share the experience. Best regards, Hideki Yamamoto From: Andrew Thompson Subject: Re: Possible bug in PF with if_bridge Date: Wed, 14 Dec 2005 08:56:24 +1300 Message-ID: <20051213195624.GA5248@heff.fud.org.nz> > On Tue, Dec 13, 2005 at 06:07:46PM +0100, Michiel Kranenburg wrote: > > Hello all, > > > > > > I may have found a bug in PF (in combination with if_bridge) for > > FreeBSD6.0-RELEASE. > > > > > > The weird thing occurs when using PF to filter the bridge. > > Let me post my pf.conf first: (I did not post the declaration of variables > > on top of the conf) > > > > --------------------------------------------- > > scrub in all > > > > block in log on bridge0 from any to $mynet > > block return-rst in log on bridge0 proto tcp from any to $mynet > > > > pass in on bridge0 proto {tcp,udp,icmp} from $mynet to $mynet keep state > > pass out on bridge0 proto {tcp,udp} from $mynet to any keep state > > > > pass on lo0 all > [...] > > > > Now comes the strange part: > > > > Behind $web and $mail are running SSH-servers. As defined by the rules, I > > don't want to allow any connection from the outside to the SSH-servers. > > BUT, some hosts/ip-addresses can _still_ connect to the SSH-servers(!), and > > some _dont_ (as it supposed to be). > > You should probably be filtering on the member interfaces rather than > bridge0 if you are doing keep-state. > > bridge0 has no direction so packets travelling in one direction look the > same a the reverse path, this may be tripping up with stateful rules. > > Can you try changing your pf rules to filter on xl1 and xl2 and see if > you get the same behaviour. > > > p.s 6.0-RELEASE has a mbuf leak with if_bridge(4)+pfil(9), you may want > to go to RELENG_6 > > > cheers, > Andrew > _______________________________________________ > 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"