Re: Bidirectional queueing in post-ALTQ era

On 2016/02/03 00:26, Charleroi Vogt wrote:
> 
> Regarding bi-directional queueing through a single gateway/firewall
> machine...
> 
> 1) One method discussed previously was to attach queues of the same
> name to the internal if and external if, and the state entry would be
> associated with queues of the same name regardless of interface.  If a
> 1-to-1 mapping of outbound queue to inbound queue was acceptable, then
> as of 2011 this method was suggested:
> 
> http://marc.info/?t=129472965800001&r=1&w=2
> 
> Is this still true as of OpenBSD 5.8?

Yes.

> 2) If the desired inbound queue classification doesn't line up 1-to-1
> with the outbound classification, then can making the state policy
> if-bound be used?  E.g.,
> 
> # queue and macro definitions not shown
> # trivial illustrative example only, no real filtering/classification
> shown
> set state-policy if-bound
> pass in on $int_if no state
> pass out on $ext_if keep state set queue some_outbound_queue
> pass out on $int_if keep state set queue an_inbound_queue
> 
> If this makes sense, I presume once the state entry on $int_if is
> created by the session return packets flowing in the direction of the
> internal network(s), that subsequent outbound packets belonging to the
> same session will match the state entry as they cross $int_if despite
> the first rule indicating "no state"?

PF normally does TCP sequence number tracking. With non-ancient
clients this can only be done if a state was created with knowledge
of wscale from the SYN which I think will be lost with your if-bound
states; if you run into problems with connections stalling then
consider whether using "sloppy" might be acceptable.