Bidirectional queueing in post-ALTQ era

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Bidirectional queueing in post-ALTQ era

Charleroi Vogt

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?

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"?

Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Bidirectional queueing in post-ALTQ era

Stuart Henderson-6
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.
Reply | Threaded
Open this post in threaded view
|

Re: Bidirectional queueing in post-ALTQ era

Charleroi Vogt
Thank you for the reply!  A question related to the last part...

---- On Wed, 03 Feb 2016 05:36:31 -0500 Stuart Henderson <[hidden email]>wrote ----

On 2016/02/03 00:26, Charleroi Vogt wrote:

> 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.

If this is a typical NAT gateway type setup without general traffic being allowed inbound unless it's part of a TCP connection initiated from the inbound side, since the ext_if makes its state entry based on the connection initiation, then only the last line would need the sloppy state tracking, correct?  I.e.,

pass out on $int_if keep state sloppy set queue an_inbound_queue

The pass out on $ext_if should work, for that use-case as is, shouldn't it?