pf(4) using inapropriate timeout values, 6.2-R

Jan Srzednicki w at
Mon Nov 19 12:37:14 PST 2007


I'm running pf(4) on a 6.2-RELEASE system.

The problem occurs when on a TCP connection, one side sends a FIN (by issuing
shutdown(SHUT_WR) on the socket), which is then ACK-ed properly. According to
pf.conf(5), the connection should then be subject to tcp.closing timeout:

                 The state after the first FIN has been sent.

But, after testing, I have discovered that the connection is timeouted
after tcp.finwait value:

                 The state after both FINs have been exchanged and the connec-
                 tion is closed.  Some hosts (notably web servers on Solaris)
                 send TCP packets even after closing the connection.  Increas-
                 ing tcp.finwait (and possibly tcp.closing) can prevent block-
                 ing of such packets.

I'm positively sure it's precisely this value that timeouts this
conection (which later on get state mismatches).

Default tcp.closing value is quite big (15 minutes), while tcp.finwait
ain't, and I have tuned tcp.finwait to a small value due to excesive
number of short-lived connections I have running.

This happens both with "keep state" and "modulate state".

Is it some kind of a known issue? Is there any fix avalaible?
I didn't test it on any other system than 6.2-R.

  Jan Srzednicki  ::
  "Remember, remember, the fifth of November"
                                     -- V for Vendetta

More information about the freebsd-pf mailing list