From mboxrd@z Thu Jan 1 00:00:00 1970 From: "John A. Sullivan III" Subject: Re: Creating rules without the /sbin/iptables command? Date: Wed, 17 Mar 2004 18:59:43 -0500 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <1079567983.2115.10.camel@localhost> References: Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Victor Julien , Netfilter Developers List Return-path: To: Henrik Nordstrom In-Reply-To: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: List-Id: netfilter-devel.vger.kernel.org On Wed, 2004-03-17 at 18:45, Henrik Nordstrom wrote: > On Wed, 17 Mar 2004, Victor Julien wrote: > > > This might be a big improvement, but it leaves me with one possible > > problem. When adding and removing rules on-the-fly i can't use this > > method, right? > > You can. There is a --noflush option to iptables-restore to not flush the > existing rules, allowing you to use iptables-restore to add/modify/delete > existing rules without having to specify the whole ruleset. > > > Wouldn't it be nice if there was an c function which i could call, which > > would do all the checking and other stuff the commandline iptables does, > > but, because its a c-function, way faster? Would it be easy (or even > > possible) to implement such a function? > > Such C function would only be marginally faster than having a pipe to > iptables-restore. > > iptables-restore has the exact same capabilities as iptables, only > difference is that iptables-restore is batch oriented compiling all your > changes and then uploading them into the kernel in one single call while > iptables makes one modification to the table per call. > > iptables-restore accepts the exact same set of commands as iptables with > only some minor syntactical sugar differences > > Syntax for iptables-restore input is > > *tablename > start working on rules in table "tablename". Equivalent to the -t option > to iptables. > > :chainname policy > specifies the default policy for chain "chainname". Equivalent to the > iptables -P command. Probably also works just fine to use the -P command > but I have not tried. > > COMMIT > Uploads the current table (specified by *tablename) to the kernel. > > #.... > Input lines starting with # are assumed to be comments and are ignored > > Any other lines are assumed to be iptables commands per the iptables > syntax specification. > > iptables commands may be prefixed by [packetcnt:bytecnt] which gets > automatically translated into --set-counters packetcnt bytecnt before the > command is executed within iptables-restore. The two syntaxes are > equivalent. > > > Don't be fooled by the fact that iptables-save only uses the -A command or > by the name iptables-restore. What iptables-restore is is a batch version > of iptables with all the capabilities of iptables, not just a tool to > restore complete tables saved by iptables-save. > > Regards > Henrik I found that there were a few other differences. As far as I can tell, you can only have one table section per file, in other words if I have a file such as *nat some rules COMMIT *filter some more rules COMMIT *nat some more rules COMMIT only the first set of NAT rules commits. I also found that I needed to use an explicit declaration of implicit matches, e.g., *filter -A FORWARD -p 6 --dport 80 -j ACCEPT - does not work -A FORWARD -p 6 -m tcp --dport 80 -j ACCEPT - does work COMMIT I did find that the performance difference for even small rule sets was noticeable and, for large rule sets, it was absolutely stunning - John -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com