From owner-freebsd-pf@FreeBSD.ORG Sun Apr 8 18:12:46 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F3F316A408 for ; Sun, 8 Apr 2007 18:12:46 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: from qsmtp1.mc.surewest.net (qsmtp.mc.surewest.net [66.60.130.145]) by mx1.freebsd.org (Postfix) with SMTP id 0535913C455 for ; Sun, 8 Apr 2007 18:12:45 +0000 (UTC) (envelope-from drew@mykitchentable.net) Received: (qmail 32669 invoked from network); 8 Apr 2007 11:12:45 -0700 Received: by simscan 1.1.0 ppid: 32658, pid: 32660, t: 4.2256s scanners: regex: 1.1.0 attach: 1.1.0 clamav: 0.84/m:42/d:2665 spam: 3.0.3 Received: from unknown (HELO blacklamb.mykitchentable.net) (66.205.146.210) by qsmtp1 with SMTP; 8 Apr 2007 11:12:41 -0700 Received: from [192.168.1.3] (bigdaddy.mykitchentable.net [192.168.1.3]) by blacklamb.mykitchentable.net (Postfix) with ESMTP id D017E16495E for ; Sun, 8 Apr 2007 11:12:40 -0700 (PDT) Message-ID: <46193097.2040303@mykitchentable.net> Date: Sun, 08 Apr 2007 11:12:39 -0700 From: Drew Tomlinson 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: <4619226E.1030105@mykitchentable.net> In-Reply-To: <4619226E.1030105@mykitchentable.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on qsmtp1.surewest.net X-Spam-Level: X-Spam-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_00, RCVD_IN_SORBS_DUL autolearn=no version=3.0.3 Subject: Re: pf and ALTQ - I Don't Understand 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, 08 Apr 2007 18:12:46 -0000 On 4/8/2007 10:12 AM Drew Tomlinson said the following: > I am struggling to get pf set up correctly. Specifically I don't > understand why I don't see any packets in the "pfctl -vs queue" output > for a queue I named "voip_out". I see the packets matching rule 61 & > rule 62 when viewing the log with "tcpdump -netttti pflog0": > > 2007-04-08 09:54:25.392552 rule 61/0(match): pass in on dc0: > 192.168.1.7.5060 > 72.165.163.9.5060: SIP, length: 394 > 2007-04-08 09:54:54.580693 rule 62/0(match): pass in on dc0: > 192.168.1.7 > 192.168.1.2: ICMP echo request, id 16724, seq 43514, > length 40 > 2007-04-08 09:55:13.532744 rule 61/0(match): pass in on dc0: > 192.168.1.7.5060 > 72.165.163.9.5060: SIP, length: 394 > > Rules 61 & 62 are: > > @61 pass log quick inet proto udp from 192.168.1.7 to any keep state > queue voip_out > [ Evaluations: 7237 Packets: 44 Bytes: 18502 > States: 1 ] > @62 pass log quick inet proto icmp from 192.168.1.7 to any keep state > queue voip_out > [ Evaluations: 331 Packets: 142 Bytes: 8520 > States: 1 ] > > Yet here is the "pfctl -vs queue" output: > > queue voip_out bandwidth 175Kb priority 6 hfsc( realtime 140Kb ) > [ pkts: 0 bytes: 0 dropped pkts: 0 > bytes: 0 ] > [ qlength: 0/ 50 ] > [ measured: 0.0 packets/s, 0 b/s ] > > I have rules to prioritize http traffic and queuing works as expected > there. Can anyone please explain to me why I am seeing this > behavior? And is there some way to actually watch traffic passing > through the queues? OK, I've done some more digging and maybe I understand now. I was missing the fact that NAT occurs BEFORE filtering (yes, now I see where it's written in the OpenBSD PF FAQ). :) So with this in mind, is there a way to write a rule to put traffic from a node on the internal network in a specific queue? For example, I want my VoIP phone (192.168.1.7) device to have outbound priority over all other traffic. My network is configured like this: internal network ----- dc0 - FBSD router - dc1 ----- Internet So what's happening is that the traffic from the VoIP device enters the router via dc0 and matches rule 61 as listed above. But then NAT occurs and now the packet is no longer from 192.168.1.7 but my public IP and thus it doesn't match rule 61. It matches rule 75 which is: @75 pass log-all quick inet proto udp from 66.205.146.210 to any keep state queue(std_out, ack_out) I can also see via tcpdump that the destination ports are either 5060 or 5200 so I guess I could filter on that. But I really don't want to prioritize traffic to 5060 or 5200 from ALL nodes on my internal network, just from 192.168.1.7. Plus what about the case where a destination port might be random? Then how would one filter? Thanks, Drew -- Be a Great Magician! Visit The Alchemist's Warehouse http://www.alchemistswarehouse.com