From owner-freebsd-pf@FreeBSD.ORG Tue Oct 25 01:24: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 E726716A41F for ; Tue, 25 Oct 2005 01:24:39 +0000 (GMT) (envelope-from montarotech@optusnet.com.au) Received: from mail26.syd.optusnet.com.au (mail26.syd.optusnet.com.au [211.29.133.167]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8B9D43D4C for ; Tue, 25 Oct 2005 01:24:37 +0000 (GMT) (envelope-from montarotech@optusnet.com.au) Received: from delta (d220-236-173-176.dsl.nsw.optusnet.com.au [220.236.173.176]) by mail26.syd.optusnet.com.au (8.12.11/8.12.11) with SMTP id j9P1ORw3021995; Tue, 25 Oct 2005 11:24:28 +1000 Message-ID: <001301c5d902$db39d6d0$0132a8c0@delta> From: "Josh Finlay" To: "Bruno Afonso" 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> <435D85A6.7020106@dequim.ist.utl.pt> Date: Tue, 25 Oct 2005 11:24:32 +1000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 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:24:40 -0000 Looking forward to 6.0 :) Any idea on a release date? It will certainly make my life so much easier. ----- Original Message ----- From: "Bruno Afonso" To: "Josh Finlay" Cc: Sent: Tuesday, October 25, 2005 11:08 AM Subject: Re: FreeBSD + MPD + PF + ALTQ > 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/