PF Traffic Shaping question.

[MarcRiv]

Alright this is probably an easy question. The wording in the PF handbook kind of confuses me a little bit.

"When using the queue keyword with rules that keep state such as:

pass in on fxp0 proto tcp from any to any port 22 flags S/SA \
keep state queue ssh

PF will record the queue in the state table entry so that packets traveling back out fxp0 that match the stateful connection will end up in the ssh queue. Note that even though the queue keyword is being used on a rule filtering incoming traffic, the goal is to specify a queue for the corresponding outgoing traffic; the above rule does not queue incoming packets."

Does this mean when the traffic enters fxp0 and talks to the server and it sends information back that the information would get put into a download queue on fxp0? Or does it mean that the fxp0 will queue the traffic on the next outgoing interface in an upload fashion?

[jggimi]

Things to keep in mind:

1. Queing is on -outgoing- traffic only. There is no way to queue incoming traffic; by the time PF sees it, it has already arrived.
2. The queue label you put on any pass rule applies to -state table- entries. In the case of your example, the inbound TCP traffic that matches that rule will have its state table entry flagged with the queue name "ssh".
3. When -outbound- traffic associated with that state table entry is seen, PF will place it in its appropriate queue.

Specific to your question, I think you may be confusing direction with upload/download.

Consider that most uses of PF are on machines acting as routers. These machines have multiple NICs. PF doesn't know which NIC is used for what purpose. All it knows is traffic comes in on NICs, and goes out on NICs. You set up the queue assignments on any stateful connection, but you queue outbound traffic, whether heading out to the Internet, or heading out to your LAN.

Think of this example: A dual NIC simple router for a small network, and you, as an admin, wish to set up queues to control traffic. You can do so, both ways: outbound on your externally facing NIC, and outbound on your internally facing NIC. You can set up the state tables, however, based on any pass rule that allows state to be maintained.

Let us pretend you wish to limit incoming HTTP traffic on your local LAN, and decide to use a queue for this purpose. Outgoing HTTP traffic is any destined for the Internet, with a destination port 80. So the queue is described on the outbound pass rule on the external network. But your queue is set up on the internal network, as the traffic goes -out- from the router to workstations on your local LAN.

[jggimi]

I've pulled in a real example -- my son's Torrent use on our home network. We have a 100Mbit LAN, and our Internet service is 12Mb/2Mb. Here is the queue definition, I give him no more than 50% of the Internet connection, if bandwidth needs to be constrained. Note I limit him to 6Mb on the outbound traffic to the internal network:

####################################
### traffic shaping

altq on $external_nic cbq bandwidth 2Mb queue {std-out, torrent-out}
queue std-out on $external_nic bandwidth 1Mb cbq (borrow, default)
queue torrent-out on $external_nic bandwidth 1Mb cbq (borrow,ecn)
altq on $internal_nic cbq bandwidth 100Mb queue {std-in, torrent-in}
queue std-in on $internal_nic bandwidth 94Mb cbq (borrow, default)
queue torrent-in on $internal_nic bandwidth 6Mb cbq (borrow, ecn)

My applicable pass and match rules are next. I'm using -current, so the rules are a little different than PF for -release, as but you should be able to get the drift of this -- there are four match rules that assign queues, and two pass rules that allow the traffic and conduct redirection to his workstation. (Recent changes to PF altered how packet forwarding "rdr" commands are used):

match in proto {tcp udp} from any to any port $tor-low queue torrent-in
match out proto {tcp udp} from any port $tor-low to any queue torrent-out
match in proto {tcp udp} from any to any port $tor-high queue torrent-in
match out proto {tcp udp} from any port $tor-high to any queue torrent-out
pass in log quick on $external_nic proto {tcp udp} from any to any port $tor-low \
    rdr-to 192.168.1.42 port $tor-low
pass in log quick on $external_nic proto {tcp udp} from any to any port $tor-high \
    rdr-to 192.168.1.42 port $tor-high

[MarcRiv]

So the rule really means

pass out on fxp0 proto tcp from any to any port 22 flags S/SA \
keep state queue ssh

for the return state traffic?

[jggimi]

Return? All it does is -flag the state-, so that packets, in -any- direction, are assigned to the "ssh" queue. It is up to your altq rules to determine what to do with that queue.

See my example in post #3, above, where I limit my kid to 6Mb worth of -inbound- $external_nic inbound use, by limiting what goes -outbound- to his workstation on the $internal_nic.

As Michael Lucas so eloquently described in his book, Absolute OpenBSD, think of PF as sitting on the CPU. Packets come in to the computer, through a NIC, and are given to PF to manage. PF can only shape traffic then goes outbound, through a NIC. The same NIC, or a different NIC, and where those packets are going make no difference.

[MarcRiv]

Ok, now that makes sense I don't know why I couldn't grasp that from that little snippet.

Thank for helping me understand that!

[jggimi]

No worries, stateful packet management can be confusing to understand. As can the definition of "state" for stateless traffic.