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 >
