Weird problems with 'pf' (on both 5.x and 6.x)

[Garance A Drosihn]

At 9:30 PM +0200 7/28/06, Stefan Bethke wrote:
>Am 28.07.2006 um 03:57 schrieb Garance A Drosihn:
>
>>It occurred to me that it might be more informative to
>>see the transaction from the *freebsd* side of things,
>>since that's the machine running pf!   So, here is a
>>similar set of two lpq's, as seen from the print-server
>>side of the connection.  It seems to be telling the
>>same basic story, as far as I can tell.
>
>It's just showing that no ACKs come back.  Can you see
>if anything showing pflog0 with tcpdump?

Thanks for the reply.  I'll check that when I get a chance
to turn the machine back on.  (the air-conditioning for
our offices just died -- AGAIN -- so I had to shut down
most of my machines today).

>That output should also tell you which rule forced the
>rejection.

There is only one rule.  The config file I'm testing with
has three comment lines, and:

    pass out quick proto { tcp, udp } all keep state

That's it.  That's the entire /etc/pf.conf file.

>What I do find curious is that the client keeps using
>port 1023 consistently.  I was under the impression that
>reusing the same port number (thus having the same
>src-ip/port+dst-ip/port tuple) shouldn't work, because
>"old" packets could arrive after the original connection
>was closed; that's what the CLOSE_WAIT state in netstat is.

Hmm.  Well, I did wait a few seconds between the two lpq's,
just so it would be easier tell them apart in the packet dumps.

Perhaps solaris is quicker to reuse ports, while 'pf'
remembers that  src-ip/port+dst-ip/port  tuple for a
longer stretch of time?

But if so, there were seven seconds between the end of the
first 'lpq' and the first attempt to start a connection for
the second one.  The 'pf' side didn't start returning ACK's
until 111 seconds after the first connection had closed.
That seems like a pretty long time to wait.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu