On 2008-11-25, Damian Higgins <[EMAIL PROTECTED]> wrote: > According to what pf logged, it permits traffic incoming on em1 to > 86.55.8.30 and outgoing trafic on em0 to 86.55.8.30. So I modified > my designation rule to : > > "pass out quick on em0 to 86.55.8.30 queue ftp" > > And traffic started hitting the first rule :
Good. > So it seems http://www.openbsd.org/faq/pf/queueing.html is outdated > since it says queue designation should take place on a different > interface than the one where queueing policy is applied. do you mean this, "Note that queue designation /can/ happen on an interface other than the one defined in the altq on directive"? (my emphasis).. > The result of the above queue designation rules was a constantly 1mbit > download rate for the initiator (192.168.110.2). So my understanding > is that ALTQ is per flow/session connection oriented rather than per > source/destination. the rules assign traffic to a queue, the bandwidth available for the queue is shared between all traffic assigned to it. if you're looking to limit each individual user to 1Mb/s, but not impose a total limit, altq can't really help. I didn't read everything of the rest of your post but hopefully the things I mention will help understanding: > "pass in quick on em0 from 86.55.8.30 queue ftp" and "pass out quick > on em1 from 86.55.8.30 queue ftp" matched nothing > > "pass out quick on em0 to 86.55.8.30 queue ftp" , "pass in quick on > em1 to 86.55.8.30 queue ftp" (which looks more like ingress rate > limiting to me) matched trafic and it is the trafic back to the > initiator that got queued. with altq, queueing happens when packets exit an interface, the only thing you can do at ingress is create state with a queue name attached so that any later traffic matching that state uses that queue. for traffic you are passing to other hosts, you can "fake up" ingress rate limiting by controlling the rate you feed those packets out, so for protocols which have rate control (like TCP) it will indirectly affect the sender's rate. > So for 192.168.6.216(initiator)'s downstream queueing I set up the > following pf rules : > > ~# grep -v \# /etc/pf.conf | grep -v ^$ > altq on em0 cbq bandwidth 100Mb queue { ftp,other } > queue ftp on em0 bandwidth 2Mb priority 0 cbq(ecn) > queue other on em0 bandwidth 98Mb priority 1 cbq(ecn,default) > altq on em1 cbq bandwidth 100Mb queue { ftp,other } > queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn) > queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default) > nat on em0 from 192.168.110.2 to <test> -> 192.168.100.233 > table <test> { any , !192.168.0.0/16 } > pass in quick on em0 to 192.168.110.2 queue ftp > pass log all > > Then started a ftp session from 192.168.6.216 with 192.168.110.2 on > port 2121 but nothing got matched, it was only a few packets at > beginning of the session : look into how the protocol works and you'll see you have to handle the FTP _data_ connections as well as the control connections, these are potentially made in either direction (for passive mode, the client makes a second connection to the server, for active mode the server connects back to the client). if you haven't seen it before, look at the actual packet contents on the interface (tcpdump -niem0 -s1500 -X host some.ftp.server) while connecting to an FTP server and listing a directory (which, like transferring a file, also opens an extra connection). note where new connections are opened (the letter S after the destination port) and in which direction. if you think you've got it, it can be educational to manually carry out an ftp transfer, you can do passive mode just with the telnet command in two windows, for active mode you also need something like netcat (/usr/bin/nc) which can listen for an incoming connection. > ~# tcpdump -nettipflog0 | grep -E 192.168.110.2\|192.168.6.216 using grep on tcpdump output will catch you out. you could use line-buffered mode (-l) but better to use tcpdump expressions to select the traffic you're interested in. at least on OpenBSD, this works fine on pflog0. on other OS, YMMV. [also note, on pflog, by default only packets _creating state_ are logged, you can log the others if you use "log (all)"]
