Re: Bidirectional queueing in post-ALTQ era
Charleroi Vogt <[email protected]> Wed, 03 Feb 2016 07:54:29 -0500
| Newsgroups | gmane.os.openbsd.pf |
|---|---|
| Message-ID | <[email protected]> |
------=_Part_934_1776457359.1454504069946 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Thank you for the reply! A question related to the last part... ---- On Wed, 03 Feb 2016 05:36:31 -0500 Stuart Henderson <[email protected]>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? ------=_Part_934_1776457359.1454504069946 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body ><div style='font-size:10pt;font-family:Verdana,Arial,Helvetica,sans-serif;'><div>Thank you for the reply! A question related to the last part...<br></div><div><br></div><div class="zmail_extra"><div id="1"><div>---- On Wed, 03 Feb 2016 05:36:31 -0500 <b>Stuart Henderson <[email protected]></b>wrote ---- <br></div></div><div><br></div><blockquote style="border-left: 1px solid #cccccc; padding-left: 6px; margin:0 0 0 5px"><div>On 2016/02/03 00:26, Charleroi Vogt wrote: <br></div><div><br></div><div>> 2) If the desired inbound queue classification doesn't line up 1-to-1 <br></div><div>> with the outbound classification, then can making the state policy <br></div><div>> if-bound be used? E.g., <br></div><div>> <br></div><div>> # queue and macro definitions not shown <br></div><div>> # trivial illustrative example only, no real filtering/classification <br></div><div>> shown <br></div><div>> set state-policy if-bound <br></div><div>> pass in on $int_if no state <br></div><div>> pass out on $ext_if keep state set queue some_outbound_queue <br></div><div>> pass out on $int_if keep state set queue an_inbound_queue <br></div><div>> <br></div><div>> If this makes sense, I presume once the state entry on $int_if is <br></div><div>> created by the session return packets flowing in the direction of the <br></div><div>> internal network(s), that subsequent outbound packets belonging to the <br></div><div>> same session will match the state entry as they cross $int_if despite <br></div><div>> the first rule indicating "no state"? <br></div><div> <br></div><div>PF normally does TCP sequence number tracking. With non-ancient <br></div><div>clients this can only be done if a state was created with knowledge <br></div><div>of wscale from the SYN which I think will be lost with your if-bound <br></div><div>states; if you run into problems with connections stalling then <br></div><div>consider whether using "sloppy" might be acceptable. <br></div></blockquote></div><div><br></div><div>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.,<br></div><div><br></div><div>pass out on $int_if keep state sloppy set queue an_inbound_queue<br></div><div><br></div><div>The pass out on $ext_if should work, for that use-case as is, shouldn't it?<br></div><div><br></div></div></body></html> ------=_Part_934_1776457359.1454504069946--