We're using IPfilter v4.1.9 on Solaris 10 amd64 (installed as part of the Solaris OS package for ipfilter). IPfilter has been working really well for us, it's fast and easy to use!

We have a rule setup like:

pass in quick proto tcp from 172.25.0.0/16 to any port = 2049 keep state

TCP port 2049 is the NFSv4 port. Under normal circumstances, this passes traffic just fine. We have some Linux computers (3.2.x kernel) connecting to the Solaris box mounting some NFSv4 shares hosted on the Solaris box.

If the TCP connection between the Linux machine and the Solaris machine gets interrupted, the Linux machine will try to reconnect to the Solaris box by opening a new TCP connection with destination port 2049.

However, here's the interesting part: Linux will re-use the same TCP *source* port when trying to reconnect. So what we see is that the Solaris box running ipfilter will have the existing TCP connection timeout. The linux box will then attempt to re-connect. However, because Linux is re-using the same source port the entry in the TCP state table for the prior connection has not yet expired. ipfilter thus ignores the new SYN packet from the Linux machine, and the new TCP connection does not get re-established (we can see the TCP connection on linux in the "SYN_SENT" state, and no record of a new TCP connection on the Solaris box, yet establishing a new TCP connection with telnet to 2049 from Linux works just fine (because the source port is different).

From what we understand (we've read the man/howto), we could remove the "keep state" rule option and it would pass all traffic to port 2049 (including SYN packets sent from the same source port as a recently closed TCP connection)? (is this the case?) However, keep state does have some nice security properties to not allow meddling with established TCP connections in progress. Also it has been mentioned that performance can be better when you're keeping state because it avoids a check on the inbound/outbound rule table

Is there any way to adjust the timeouts of the TCP state table so that it forgets the previously established connection more quickly? Ideally we could adjust the timeout only for connections that match this rule (e.g., something like "keep state lifetime-timeout 60"). If not, unless we can tell Linux to always use a different source port for the TCP connection, we probably will just have to avoid using "keep state" for that rule?

Thanks,
Kevin