From owner-freebsd-pf@FreeBSD.ORG Tue Oct 25 01:08:47 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 C650716A41F for ; Tue, 25 Oct 2005 01:08:47 +0000 (GMT) (envelope-from brunomiguel@dequim.ist.utl.pt) Received: from gecea.ist.utl.pt (gecea.ist.utl.pt [193.136.140.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id 267BC43D46 for ; Tue, 25 Oct 2005 01:08:46 +0000 (GMT) (envelope-from brunomiguel@dequim.ist.utl.pt) Received: from [66.30.10.101] (c-66-30-10-101.hsd1.ma.comcast.net [66.30.10.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gecea.ist.utl.pt (Postfix) with ESMTP id 3D2C040CE; Tue, 25 Oct 2005 02:08:44 +0100 (WEST) Message-ID: <435D85A6.7020106@dequim.ist.utl.pt> Date: Mon, 24 Oct 2005 21:08:54 -0400 From: Bruno Afonso User-Agent: Thunderbird 1.4 (Windows/20050908) MIME-Version: 1.0 To: Josh Finlay References: <000b01c5d644$54527f20$0132a8c0@delta><4359ED5B.7010303@dequim.ist.utl.pt><55e8a96c0510220651t47fa063ayefd1dcffd63950a6@mail.gmail.com><435A6025.5060602@dequim.ist.utl.pt><55e8a96c0510221659g7ac457b1gc696f392a249fee3@mail.gmail.com> <010001c5d7e0$8669bd50$6200a8c0@delta> <008f01c5d8e3$308c15f0$0132a8c0@delta> In-Reply-To: <008f01c5d8e3$308c15f0$0132a8c0@delta> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: FreeBSD + MPD + PF + ALTQ X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Oct 2005 01:08:48 -0000 Josh Finlay wrote: > Just giving this message a bit of a bump. > > I've looked into: > > route add -net 192.168.0.0/24 192.168.1.1 > in an attempt to route between the two interfaces > but i just get "file exists" errors, even if i "route flush" before hand. > > like I said earlier, routing is -not- my forte. Do yourself a favour, use current or wait for 6.0 to come out or ask for patches :-) BA > > ----- Original Message ----- From: "Josh Finlay" > > To: "Bill Marquette" > Cc: > Sent: Monday, October 24, 2005 12:46 AM > Subject: Re: FreeBSD + MPD + PF + ALTQ > > >> Ok I've tried to study the PF FAQ on OpenBSD.org and learn a few >> things from some of the rules you've given. >> >> Here is my current pf.conf to date: >> (note: de0 goes to my lan, vr0 goes to my modem, mpd still uses ng0 >> but the traffic is still essentially coming in/out on vr0 right?) >> >> ExtIF="vr0" >> IntIF="de0" >> >> set loginterface $ExtIF >> scrub in all >> scrub out all random-id max-mss 1440 >> >> altq on $ExtIF priq bandwidth 128Kb queue { std_out, ssh_im_out, >> dns_out, tcp_ack_out } >> queue std_out priq(default) >> queue ssh_im_out priority 4 priq(red) >> queue dns_out priority 5 >> queue tcp_ack_out priority 6 >> >> altq on $IntIF cbq bandwidth 512Kb queue { std_in, ssh_im_in, dns_in } >> queue std_in bandwidth 384Kb cbq(default) >> queue ssh_im_in bandwidth 64Kb priority 4 >> queue dns_in bandwidth 64Kb priority 5 >> >> local_net = "192.168.0.0/24" >> ssh_ports = "{ 22 }" >> im_ports = "{ 1863 5190 5222 }" >> >> nat on $IntIF from $local_net to any -> ($ExtIF) >> pass in quick on lo0 all >> pass out quick on lo0 all >> >> pass out on $ExtIF inet proto tcp from ($ExtIF) to any flags S/SA \ >> keep state queue(std_out, tcp_ack_out) >> pass out on $ExtIF inet proto { udp icmp } from ($ExtIF) to any keep >> state >> pass out on $ExtIF inet proto { tcp udp } from ($ExtIF) to any port >> domain \ >> keep state queue dns_out >> pass out on $ExtIF inet proto tcp from ($ExtIF) to any port $ssh_ports \ >> flags S/SA keep state queue(std_out, ssh_im_out) >> pass out on $ExtIF inet proto tcp from ($ExtIF) to any port $im_ports \ >> flags S/SA keep state queue(ssh_im_out, tcp_ack_out) >> >> pass in on $IntIF from $local_net >> pass out on $IntIF proto { tcp udp } from any port domain to >> $local_net \ >> queue dns_in >> pass out on $IntIF proto tcp from any port $ssh_ports to $local_net \ >> queue(std_in, ssh_im_in) >> pass out on $IntIF proto tcp from any port $im_ports to $local_net \ >> queue ssh_im_in >> >> --end >> >> I have also only just installed the second nic in the machine >> before that, de0 was doing all the work. >> i am stuck with a small problem, which ive had no experience with, >> once i tell mpd to connect via vr0, i get connectivity on the router >> but not on any other machines on the network. >> they are still using de0's ip (192.168.0.101) as their gateway, but >> its not able to do any internet traffic. >> this is the same if i bind a ping to 192.168.0.101 (ie. ping -S >> 192.168.0.101 host.name) i get no response while mpd is using vr0, but >> if its using de0 like before it works fine. >> >> is this something in pf i need to fix? or do I need to somehow route >> traffic from de0 to vr0, im in the dark about this, like I said ive >> had no experience with a second nic. >> >> this rules apply fine. but with the above problem on hand, i havent >> been able to see if they actually work yet. let me know if I messed it >> all up or not ;) >> >> ----- Original Message ----- From: "Bill Marquette" >> >> To: "Bruno Afonso" >> Cc: >> Sent: Sunday, October 23, 2005 9:59 AM >> Subject: Re: FreeBSD + MPD + PF + ALTQ >> >> >>> On 10/22/05, Bruno Afonso wrote: >>>> Bill Marquette wrote: >>>> > On 10/22/05, Bruno Afonso wrote: >>>> >> The download part is the problematic one IF they're not all >>>> connected >> to >>>> >> the same network interface. Why ? Because altq only works PER >> >>>> interface >>>> >> and tun0, tun1, tun2, etc are each and single one, one interface >>>> on >> its own. >>>> >> >>>> >> You basically have to >>>> >> >>>> >> altq on tun0 >>>> >> >>>> >> altq on tun1, etc.. >>>> >> >>>> >> What we would need in this case would be a meta-interface that altq >>>> >> would work on, but that is not available. Bottom line: you can't >>>> >> control >>>> >> with PF global bw over an interface-span. This is probably >>>> necessary >> for >>>> >> a full commercial deployment. Don't know of any plans to >>>> implement >> this... >>>> >> >>>> >> meta_if {tun0, tun1} >>>> >> >>>> >> altq on meta_1 ... >>>> >> >>>> >> would be nice. :-) >>>> > >>>> > You mean something like: >>>> > altq on { fxp0 fxp1 } bandwidth 100Mb hfsc queue { a b } >>>> > queue a bandwidth 50Mb hfsc(default) >>>> > queue b bandwidth 50Mb hfsc >>>> > This works today :) >>>> >>>> Yes, I have now tried and verified that it works, but not as we would >>>> like to in the sense of a meta interface, eg: >>>> >>>> altq on { tun0 tun1 tun2 } cbq bandwidth 1Mb queue { a b } >>>> queue a bandwidth 700Kb cbq(default) >>>> queue b bandwidth 300Kb >>>> >>>> >>>> which turns itself into... (from pfctl -sq) >>>> >>>> >>>> queue root_tun0 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b} >>>> queue a bandwidth 700Kb cbq( default ) >>>> queue b bandwidth 300Kb >>>> queue root_tun1 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b} >>>> queue a bandwidth 700Kb cbq( default ) >>>> queue b bandwidth 300Kb >>>> queue root_tun2 bandwidth 1Mb priority 0 cbq( wrr root ) {a, b} >>>> queue a bandwidth 700Kb cbq( default ) >>>> queue b bandwidth 300Kb >>>> >>>> >>>> What would I want with this? To create a queue that is shared by every >>>> interface, so limiting globally every interface to a maximum of 1Mb >>>> each >>>> and all of them to 1Mb each too, in a cqb borrowing shared way. For >>>> examply, I'd like a to never exceed 700Kb taking into account every >>>> interface. This makes perfect sense if I have a limited ammount of >>>> bw to >>>> share among each client, which, in a real world, happens 99,9% of the >>>> time because resources are limited. >>>> >>>> So, the syntax works, but it does achieve what I mentioned before, the >>>> meta interface concept. The example you give is only useful for >>>> simplifying rulesets, although it's more difficult for humans to >>>> understand. >>> >>> >>>> From what I understand, that binds queue 'a' to every interface. The >>> queue definition still limits the queue itself to 700Kb, but allows >>> you to assign traffic to that queue on each interface that queue is >>> bound to. I can't find the email that I read that suggests it now >>> (machine having recently been wiped and google not being terribly >>> forthcoming with the answer). >>> >>> Have you verified this not working with real traffic, or just the >>> pfctl -sq output? At this time I don't have a multi-interface box at >>> my disposal, so I can't easily test this. >>> >>> --Bill >>> _______________________________________________ >>> 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" > > _______________________________________________ > 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" -- Bruno Afonso, Biological Engineer Dana-Farber Cancer Institute 1 Jimmy Fund Way Smith Building Boston, MA 02115 phone: (617)-632-5105 GABBA Graduate Student (http://gabba.up.pt) Homepage @ http://brunoafonso.net/