On Thu, Nov 27, 2008 at 9:32 AM, Can Erkin Acar <[EMAIL PROTECTED]> wrote: > "Damian Higgins" wrote: >> >> Hi Stuart, >> >> First off, thank you for the feedback you provided. Unfortunately, you >> misunderstood the issue I'm encountering because you haven't read my >> entire post. So, I'll try to make a brief post of the previous >> message, to make it easier to read, and hope you will have the >> patience to read it this time :). >
Hi Can, > Perhaps you are misunderstanding how pf works. I sure do, that is why I started this thread :-) > Instead of trying to solve > *your* problem, I will try to describe how pf+altq works, and it will be up > to you to figure out how to accomplish what you want to do. > > >> First, some concepts of queueing/policing I learned from my previous >> experience in other environments(correct me if I'm wrong) : > > First forget about other environments, especially Linux. I have deleted the > rest of your post, since it does not really matter what you or other > environments think about how traffic shaping should be done. If you are > using OpenBSD, try to understand how it is done with pf+altq. > > > Here are the basic rules for pf. You may already know some of them, but > please bear with me. You may learn something new: > > # Filtering is stateful in pf, and it is strongly recommended to keep it > that way (ie. use 'no state' only if you really know what you are doing). > The S/SA flags being default also have strong reasons. > > # Think of 'state' as a 'connection'. This is especially true for TCP. Use > systat(1) or pftop (from ports) to see the states. A state *sees* packets in > *both* directions that belong to a particular traffic. > ># If a packet matches a state, no rules are evaluated *hint* This is where it all starts to make sense :-) > > # If a packet does not match an existing state but matches a rule, a state > is created. Further packets of this 'connection' will just match the state, > and bypass ruleset evaluation. > > # Loading pf rules with 'pfctl -f pf.conf' does not clear existing states > (unless you also use the proper flush command line switch) *hint* > > # A connection that traverses an OpenBSD router usually enters pf twice (at > inbound and outbound interface) and provided there are appropriate pass > rules, it will create states on both interfaces. That is, every packet of a > connection both inbound and outbound will have two states associated with > it. > > # A connection that originates from or terminates on an OpenBSD box will > have a single state associated with it. > > # NAT/RDR rules are evaluated before filter rules, and address translation > happens *before* rules are evaluated, so rules are always checked against > translated packets (NAT on incoming, RDR on outgoing). > > > And the basic rules for altq: > > # altq *only* filters *outbound* packets on an interface. This is usually > not related to the direction of the connection itself. > > ## Example: if you want to restrict internal hosts HTTP downloads from > outside servers, these *incoming* HTTP payloads have to be filtered at the > interface facing the hosts. This also means there is no way to apply altq to > limit downloads that are initiated from the OpenBSD gateway itself. > > ## Example: if you want to increase the priority of the e-mails that your > mail server sends, use the interface facing your ISP. > > # Each packet, as it passes through the network stack can be assigned a > 'queue-id'. This queue id determines which queue the packet is placed as it > *leaves* the box. If a packet has no queue-id, then it is assigned to the > default queue. > > # The queue ids are mapped to queue names, that is, queues that carry the > same name have the same id. > > > And this is how PF assigns packets to queues: > > # Each rule has two queue ids, one for normal one for high-priority packets > as specified by the rule definition (see pf.conf for details). If you > specified a single queue in your rule definition, that means both ids are > equal. > > # By default the packet has no queue-id assigned. > > # If a packet matches a rule, and that rule specifies a queue, the packet > queue-id is replaced by the queue id specified by the rule. If the rule has > no queue specified, the packet queue-id is not changed (does not revert back > to default). > > # If a packet matches a state, the rule that created the state is consulted > (as above). > > # Since a packet can match up to two rules/states as it traverses a router, > the last assigned queue wins (as the queues only take effect as the packet > exits the router). > > # Note that, since a state matches packets in both directions, packets in > both directions will be assigned queue ids by a given state. That makes it > possible to create a state with a rule on one interface, and have the reply > packets assigned to the same queue specified by that rule on a different > interface. > > > Finally, here are some additional things to think about or investigate: > > # You can do a lot of creative and flexible stuff with 'tag' and 'tagged' > keywords in your ruleset. Assigning queues by 'pass quick tagged XYZZY queue > MAGIC' type of rules is much easier to keep track of. > > # What happens if you change the ruleset while traffic is flowing? Hint: > existing states will point to a default 'empty' rule. > > # What happens when states are synchronized by pfsync(4) between two > carp(4)'ed firewalls? Hint: The mapping used to get lost, so if the > firewall failed over queues would not work for 'synced' states although they > would work nor new states. How this is handled now in -current is left as an > exercise. > > > Now, armed with the above, you should be able to explain the behaviour you > see, and design a filter that does what you want. > > Have fun ... Very well explained, this is very valuable info! Thank you for your feedback. I am now able to explain the behavior I saw in my tests. Stuart was right. Because the traffic I made in the lan was active ftp, the ftp server connected back to the client and because this was a separate state, no packets matched the client. That's why I couldn't find any similarities between my lan tests and the outside ftp tests and couldn't figure any sense of the way PF+ALTQ works. Today I made the tests in my lan again in passive mode and got the results I expected. I have also found a packet flow diagram for PF : http://homepage.mac.com/quension/pf/flow.png, I don't know how up-to-date this is, but I find it very usefull. I think the readers of this thread will do as well. Thank you all who helped with explanations. Best regards. > > Can > > > > PS: pflog, tcpdump and pftop/systat are your friends. > > PPS: You can always look at the source code to see how things work. > > PPPS: When asking questions, give as much context information as possible. > > PPPPS: Some of the above rules may have changed slightly after the recent > overhaul of pf state handling. There may also be bugs and/or regressions, so > a good bug report really helps a lot. A report that says "it works with 4.3 > but not with 4.4 or -current" goes a long way to point out a regression.
