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 20:30:00 -0500 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <1079573400.2112.13.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 20:15, Henrik Nordstrom wrote: > On Wed, 17 Mar 2004, John A. Sullivan III wrote: > > > 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. > > If this is the case then it is a bug somewhere, most likely in libiptc.. > > seems to work fine here however.. tested with > > *filter > -A INPUT -p tcp --dport 45 -j ACCEPT > COMMIT > *nat > -A PREROUTING -p tcp --dport 45 -j ACCEPT > COMMIT > *filter > -A OUTPUT -j ACCEPT > COMMIT > > and all three rules was added just fine. > > also I do not see any reason why it should not work. The libiptc handle is > completely closed on COMMIT so there should not be any memory of you > already have used this table when the new *tablename is reached. > > Note: when doing this you MUST use the --noflush (-n) option. If not the > second reference to the table will clear the rules added by the first.. > > > 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 > > Works fine here without.. and considering that the exact same iptables.c > is used in both commands for parsing the commands I don't see why it > should not work in any version of iptables-restore.. > > The fact that iptables-save prints the protocol match is only due to the > fact that this is actually what the rules looks like if you are protocol > match options.. there is some heavy duty "magics" in iptables command > parsing if a protocol is specified but no protocol match. There is an > interesting comment in iptables.c which summarises this magic protocol > match function quite well ;-) > > /* If you listen carefully, you can > actually hear this code suck. */ > > > Regards > Henrik Interesting. Thanks for the update. I know the last time I tested was with a pretty old iptables - I don't know the version number as I have long since upgraded. Perhaps I was braincramping but I'm almost certain it choked if I didn't use the explicit match. Thanks again - John -- John A. Sullivan III Chief Technology Officer Nexus Management +1 207-985-7880 john.sullivan@nexusmgmt.com