FreeBSD + MPD + PF + ALTQ
Josh Finlay
montarotech at optusnet.com.au
Sun Oct 23 07:46:23 PDT 2005
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" <bill.marquette at gmail.com>
To: "Bruno Afonso" <brunomiguel at dequim.ist.utl.pt>
Cc: <freebsd-pf at freebsd.org>
Sent: Sunday, October 23, 2005 9:59 AM
Subject: Re: FreeBSD + MPD + PF + ALTQ
> On 10/22/05, Bruno Afonso <brunomiguel at dequim.ist.utl.pt> wrote:
>> Bill Marquette wrote:
>> > On 10/22/05, Bruno Afonso <brunomiguel at dequim.ist.utl.pt> 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 <meta_1> {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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>
More information about the freebsd-pf
mailing list