Re: Creating rules without the /sbin/iptables command?

["John A. Sullivan III" <john.sullivan@nexusmgmt.com>]

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