Question about TCP ACK queuing in PF - BSD

This is a discussion on Question about TCP ACK queuing in PF - BSD ; I have a newbie question about the PF packet queueing example in the OpenBSD PF FAQ. The example shows that if you want to queue TCP ACK packets you should use a rule like: pass in on fxp0 proto tcp ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: Question about TCP ACK queuing in PF

  1. Question about TCP ACK queuing in PF

    I have a newbie question about the PF packet queueing example in the
    OpenBSD PF FAQ.

    The example shows that if you want to queue TCP ACK packets you should
    use a rule like:
    pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep
    state queue ssh

    I'm a little confused by this, though, because according to the packet
    filtering section of the FAQ, this will match SYN packets and not ACK
    packets.

    Could someone clear this up for me?

    Thanks.
    Ian.

  2. Re: Question about TCP ACK queuing in PF

    boisvert.ian@gmail.com wrote:
    > I have a newbie question about the PF packet queueing example in the
    > OpenBSD PF FAQ.
    >
    > The example shows that if you want to queue TCP ACK packets you should
    > use a rule like:
    > pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep
    > state queue ssh
    >
    > I'm a little confused by this, though, because according to the packet
    > filtering section of the FAQ, this will match SYN packets and not ACK
    > packets.
    >
    > Could someone clear this up for me?


    I can see why you'd think that, but I don't think the FAQ intends to say
    that. Prioritizing ACK is somewhat useful, and assigning traffic to
    queues using states is the way to go, but that particular command isn't
    really related to ACK.

    In short, you're completely right.

    Joachim

  3. Re: Question about TCP ACK queuing in PF

    Joachim, thanks very much for your reply.

    I reread the section in the FAQ, and I think you are right--it doesn't
    intend to say what I had thought it said...

    If one wanted to prioritize ACK packets, though, would the following
    be on the right track?

    pass out on fxp0 proto tcp from any to any flags A/SA keep state queue
    higher_priority

    Thanks.
    Ian.

  4. Re: Question about TCP ACK queuing in PF

    boisvert.ian@gmail.com wrote:
    > If one wanted to prioritize ACK packets, though, would the following
    > be on the right track?
    >
    > pass out on fxp0 proto tcp from any to any flags A/SA keep state queue
    > higher_priority


    That should work. (Should - I haven't tried this recently.)

    Joachim

  5. Re: Question about TCP ACK queuing in PF

    wrote:
    > The example shows that if you want to queue TCP ACK packets you should
    > use a rule like:
    > pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep
    > state queue ssh
    >
    > I'm a little confused by this, though, because according to the packet
    > filtering section of the FAQ, this will match SYN packets and not ACK
    > packets.


    This rule creates a state due to "keep state" and matches the following
    ACK-packets to the state, not to a rule. The state "knows" which queue its
    packets belong to. There can be two different queues a state assigns its
    packets to. The first queue is used for bulk traffic, the other for packets
    with TOS bit for low delay set and empty ACK packets.

    pass in on fxp0 proto tcp from any to any port 22 flags S/SA keep state
    queue (bulk, lowdelay)

    This rule would assign traffic to two different queues, empty ACKs and low
    delay packets to "lowdelay" and the rest to "bulk". Yet, interactive ssh
    connections usually have the low delay bit set, so all traffic would be
    assigned to the "lowdelay" queue. sftp-connections would be distributed on
    the two queues, since low delay is not set there.

    Your next question regarding "flags A/SA": I'd advise against creating a
    state for a tcp-connection in the middle of that connection. Several
    parameters are negotiated during the S/SA SA/SA phase. It should simply not
    work reliably. Furthermore if you already have a "flags S/SA keep state"
    rule, no valid packets could arrive at your A/SA rule.



+ Reply to Thread