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 > > >
