On Wed, Feb 22, 2006 at 08:39:36PM -0500, Nick Holland wrote: > Steve D. wrote: > >Hi, > > > >I'm setting up a gateway (1.7 Ghz machine with 1 Gig of ram) for 700+ > >users using pf with NAT and BINAT's (90% NAT). I would like to know > >if anyone has any recommendations on tweaking the runtime options in > >PF. This box will pretty much just be handling the natting with a bare > >minimum of filtering, just enough to keep the box secure. > > Yes: > DON'T TOUCH ANYTHING UNTIL YOU KNOW WHAT THE GOAL IS. > > Apparently, there are some OSs people are used to that ship in a nearly > useless state, at least judging by the queries like this. With OpenBSD, > you aren't supposed to have to tweak things..it should Just Work. > > See if you run into a problem. Don't start twisting knobs until you see > if there is a reason to do so, and until you know what the desired > outcome is. The defaults are set pretty darned well to start with -- > you are much more likely to break something by "tweaking" than you are > to improve anything.
Normally, I would agree with this. And you're right as far as non-pf tweaking. But he's already stated that he's going to be running this system in a "please rape my client systems" configuration, not as a firewall with a sane default deny ruleset. Go ahead and deploy it with the basic defaults, but when the first worm hits those client systems and you find yourself wondering why existing connections still work but new connections fail, check first to see if your state table is full. In my opinion if you're talking about NATing 750 Windows boxes doing regular Windows-type things, you're going to want to at least at crank the limits on states and turn on adaptive timeouts; I wouldn't go any further than that unless you run into actual problems, but you can also think about using some of the other connection limiting features to prevent trojaned systems from filling the state table and impacting other users. Things to think about (roughly in order of aggressiveness): - 'set limit states' - adaptive timeouts - 'set optimization' I would consider these three "Normal" tuning for a firewall deployment like this. The default configuration is constrained somewhat by the fact that we want it to work well on systems with limited memory, so they don't totally reflect reality for a more serious firewall. We've talked about turning adaptive timeouts on by default, though. Maybe I'll get around to that after 3.9. - 'max-src-states' on outgoing connections - 'max-src-conn-rate' on outgoing connections These are tweaky. You need to understand exactly what problems you're trying to solve, and what the side-effects are going to be. -Ryan
