Stateful IPFW - too many connections in FIN_WAIT_2 or LAST_ACK states

[Dmitry S. Kasterin]

Kevin, Michael, hi

> a real problem with IPFW.

Well, someone who can confirm or disprove my guesswork is much desirable )

> But I do have to ask why you find statefull rules for outgoing TCP
> connections desirable? Why not:
> 00101 allow tcp from me to any established

> It appears to do the same thing for TCP and is much faster to process
> plus it does not leave you open to trivial DOS (often of yourself) by
> filling the dynamic rule tables.

The host in question is my workstation running FreeBSD. I have no reason
to distrust its users. Workstation doesn't host services.

So I've decided to keep ruleset short and clean:

00001 allow ip from any to any via lo0
00002 deny ip from any to 127.0.0.0/8
00003 deny ip from 127.0.0.0/8 to any
00004 deny ip6 from any to any
00010 check-state
00101 allow tcp from me to any out setup keep-state
00201 allow udp from me to any out keep-state
00301 allow icmp from me to any out keep-state
00302 allow icmp from any to me in icmptypes 3,4,8,11,12
65534 deny ip from any to any
65535 deny ip from any to any

Yes, I'm aware of possible DOS. But I have direct access to the workstation;
if something goes wrong, I always can examine it.

Thank you for the "allow tcp from me to any established" rule,
I'll give it a try later.

> Generally, for client systems, stateful UDP makes sense, but I
> generally don't understand why people choose the more complex, slower,
> and potentially disruptive stateful rules for TCP.

Hmm, http://undeadly.org/cgi?action=article&sid=20060927091645  says:

"For specific connections like DNS lookups, where each connection only
consists of two packets (one request and one reply), the overhead of
state creation might be worse than two ruleset evaluations.
Connections that consist of more than a handful of packets, like most
TCP connections, will benefit from the created state entry."

But it doesn't matter - both stateless and stateful rules for UPD will
work in my case.

> Look at the kernel tunables:
> ...

# sysctl net.inet.ip.fw | grep _lifetime
net.inet.ip.fw.dyn_short_lifetime: 5
net.inet.ip.fw.dyn_udp_lifetime: 10
net.inet.ip.fw.dyn_rst_lifetime: 1
net.inet.ip.fw.dyn_fin_lifetime: 1
net.inet.ip.fw.dyn_syn_lifetime: 20
net.inet.ip.fw.dyn_ack_lifetime: 300

I didn't change anything. Quite possible dyn_fin_lifetime is too
small. I'll try to raise it.