It's used very often for logging, so that the logging doesn't swamp the firewall's disk. Imagine you're dropping 100 packet/s and want to log what's going on. You'd want to have the logging rule limited to something like 1/s or whatever. On Tue, 25 Jan 2005 13:56:25 -0600 (CST), Tib <tib@xxxxxxxxxxxxxxx> wrote: > > You're kidding o_O > > I guess it makes sense.. the connections will trip that rule until it is > satisfied and then move onto the next. That's.. bizarre. > > <EOL> > Tib > > On Tue, 25 Jan 2005, Mark Moseley wrote: > > > Heh, forgot to CC the list on my original reply, sorry. > > > > Makes sense on the --limit-burst. :) > > > > As far as adding the DROP/REJECT after that, once the connection limit > > in the --limit rule has been reached, it will simply just fall through > > the next rule (i.e. it doesn't do any implicit DROP'ing on its own). > > So the rule with the --limit just matches up to the rate in --limit > > and then doesn't match. Without a rule later on (or a policy to > > DROP/REJECT), any overflow will just get accepted. > > > > > > > > > Yup - once I saw an example of someone USING the limit options it made > > > sense :] > > > > > > The only thing --limit-burst does is say 'you have x many free tries > > > before you fall under the rate limit of Y/time restrictions'. > > > > > > So on mine, you can effectively connect twice in short succession before > > > you are cut back to once every 10 minutes (6 per hour). > > > > > > > Be sure to add a DROP or REJECT on the same match (unless the default > > > > policy is already that). > > > > > > I don't follow why to do this - explain? > > > > > > <EOL> > > > Tib > > > > > >
