From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Moseley Subject: Re: use of the limiting options Date: Tue, 25 Jan 2005 11:51:59 -0800 Message-ID: <294d5daa05012511513465fcc1@mail.gmail.com> References: <294d5daa0501251137328fa4ff@mail.gmail.com> Reply-To: Mark Moseley Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: netfilter-bounces@lists.netfilter.org Errors-To: netfilter-bounces@lists.netfilter.org Content-Type: text/plain; charset="us-ascii" To: Tib Cc: netfilter@lists.netfilter.org 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? > > > Tib >