mike,
that's normal. ipf is waiting for TCP FIN+ACK's to go past, indicating that the state can be torn down. but in the case you note below, since the connection is interrupted and ip's changed, ipf will never see the FIN+ACK's. but don't worry, ipf's internal timers will eventually kill off these states; so you don't have to manually stand guard for this situation.
if you look at the output of "ipfstat -t" you will note that for these "abandoned" states, the ttl is decrementing towards zero. when the ttl reaches zero the connection will in fact be deleted from ipf's state table, preventing the table from ending up full of "stale" entries.
IIRC the default ipf timeout for TCP states is 7 days. you don't mention what OS you are running but you can change this timeout at compile or boot time. param is "tcpidletimeout".
see the solaris /etc/system example in http://www.phildev.net/ipf/IPFsolaris.html#10
in *bsd land you can do the same in sysctrl.conf or some such.
i use tcpidletimeout = 24 hours without ill effects. but if you have applications that sit idle for longer than that you may want to adjust accordingly.
regards, jim
Michael Grant wrote:
I use ipnat on my dynamic dialup ip connection. I basically leave the connection up all the time but from time to time my isp bumps me off and it dials right back up.
I have noticed that my connections which are still up when the line
bounced keep the old ip address in the nat table. I have to manually
execute 'ipnat -F' to flush the entries. Is this a known problem?
I'm using ipfilter 3.4.31.
Michael Grant
