FreeBSD + MPD + PF + ALTQ
Josh Finlay
montarotech at optusnet.com.au
Mon Oct 24 14:37:58 PDT 2005
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.
----- Original Message -----
From: "Josh Finlay" <montarotech at optusnet.com.au>
To: "Bill Marquette" <bill.marquette at gmail.com>
Cc: <freebsd-pf at freebsd.org>
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" <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"
>>
>
> _______________________________________________
> 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