> > > That will not help you to solve the problem. It will only cause some > > > troubles to valid connection states. > > Nope. The point of the adaptive limits was to only start penalizing > > things when the firewall is overloaded. Read-on > When the firewall is overloaded someone trying to start a valid connection > will be penalized exactly like a box 0wned by some worm/virus...
I like math, do you like math? Say his firewall has an upper limit of 50k states. set limit states 50000 set timeout adaptive.end 55000 set timeout adaptive.start 25000 Below 25k states, the timeouts will not be affected. At 30k states they will time out in 83% of the time. At 40k states they will time out in 50% of the time. At 50k states (saturation), they will time out in 17% of the time. At saturation, the TCP timeouts will drop from, to: tcp.first 120s 20s tcp.opening 30s 5s tcp.established 86400s 14688s tcp.closing 900s 153s tcp.finwait 45s 7s tcp.closed 90s 15s You're arguing that 20s is too long to expect a SYN/ACK, and 5s is too long to expect the last ACK in the 3whs. And that's just bullshit. Assume the PF box protecting the p2p junkies and infected hosts have 90% of its connections in the finwait and closed state for which there are no consequences to expiring early. The above adaptive limits will yield a theoretical effective state table size of: 50000 * 10% + (50000 * 90%) / ((55000 - 50000) / (55000 - 25000)) that's 270k. neat huh? > I prefer a deterministic setup than a unforeseeable one. There we'll agree to disagree. I prefer Amdahl's law which tells me to optimize for the common case instead of degrading everything to the pathological case. > You can lower some specific timeout limits and you'll always know what your > firewall is doing. You can do the math when setting up adaptive timeouts and you'll always know what your firewall is doing. .mike
