Re: Pf questions for larger implementation
On Thu, 23 Feb 2006, Ryan McBride wrote: SNIP > 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. I "help" a friend out with the FW in front of their company webservers. I agree with Ryan's observation, one because I'm pretty sure he knows what he's doing, two because I have direct experience in attempting to protect Windows systems. On more than one occasion the owner of the business has called me up to say there's a problem with the FW, everytime they've said that it was related to one of their Windows systems getting tilted. > Things to think about (roughly in order of aggressiveness): > > - 'set limit states' > - adaptive timeouts > - 'set optimization' SNIP > -Ryan diana Past hissy-fits are not a predictor of future hissy-fits. Nick Holland(06 Dec 2005)
Re: Pf questions for larger implementation
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
Re: Pf questions for larger implementation
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. For comparison: we have ~850 people, hiding behind a CARP'd pair of machines -- primary is a Celeron 600, 384M RAM. Failover box is a PIII-750, 512M RAM, in an otherwise identical box. Hooked to a 45Mbps DS3. We aren't exercising the system much at this point (neither the box nor the DS3). I suspect some day, we'll start seeing some limits hit on this thing, we'll worry about it then...assuming these boxes haven't died of old age by the time that happens. :) Nick. Nick, Thanks for the info. That's what I was looking for. I'm going to be dropping this into production and I don't want things to grind to a halt in 30 seconds. What kind of thruput are you seeing on the box? The only tweaks I was wondering about were in the pf runtime options (limit states etc.). Thanks again, Steve
Re: Pf questions for larger implementation
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. For comparison: we have ~850 people, hiding behind a CARP'd pair of machines -- primary is a Celeron 600, 384M RAM. Failover box is a PIII-750, 512M RAM, in an otherwise identical box. Hooked to a 45Mbps DS3. We aren't exercising the system much at this point (neither the box nor the DS3). I suspect some day, we'll start seeing some limits hit on this thing, we'll worry about it then...assuming these boxes haven't died of old age by the time that happens. :) Nick.
Re: Pf questions for larger implementation
On 2/23/06, Steve D. <[EMAIL PROTECTED]> wrote: > 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. > > Nat statement: ($src_nat is a public /25) > nat on $public_if inet from to any -> $src_nat source-hash > > Binat statement: (which isn't working for some reason but I'll figure > that out) > binat-anchor one2ones > load anchor one2ones from "/etc/one2ones" > > If anyone has some experience with a similar sized setup, I'd really > appreciate hearing from you. If there's any other adjustments I can > make to keep the performance up, I'd be interested in those also. try it, deploy it. your cpu/mem should handle it easily. the only thing I can imagine is running into the default state limit. see man pf.conf the part about "set limit". --knitti
Pf questions for larger implementation
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. Nat statement: ($src_nat is a public /25) nat on $public_if inet from to any -> $src_nat source-hash Binat statement: (which isn't working for some reason but I'll figure that out) binat-anchor one2ones load anchor one2ones from "/etc/one2ones" If anyone has some experience with a similar sized setup, I'd really appreciate hearing from you. If there's any other adjustments I can make to keep the performance up, I'd be interested in those also. Thanks, Steve
