I am not familiar with FC so I can't advise you with how it does things. Maybe another poster can. If you feel comfortable reading bash scripts, you can take a look at the script FC uses to start the firewall and use man pages to aid you in interpreting the contents of iptables-config. The script is probably called /etc/init.d/iptables.

Another alternative is turn off Fedora Core's normal iptables script and have it run your custom script at startup instead. This is done by changing a symlink in /etc/rc3.d (assuming you are at runlevel 3). I can advise you how to do this manually. There is probably a tool designed to aid you with that, but I can't advise you about that.

I am glad you got the zeroconf problem solved. That seems really strange to me. I will have to research that sometime. Well, I do expect to learn some things posting here!

just curious: i've always been under the impression that, on red hat distros, doing this would take care of saving your iptables config without the need to edit any files manually:please let me know if i've misunderstood how that command works...

as for the iptables-config file, i too am not familiar with that, but i read the name of those parameters and i think i understand what they do judging by their names... those settings it has sound fine to me in that regard... the only weird thing i saw was that the name of the iptable_nat module had a space in it, like:not sure if that was a typo during post or what... and in any case, modules like that get loaded automatically as needed... but still, if it's written like that in the file i would correct it...

Yup. At least they used to do it that way. From the RH8.0 /etc/init.d/iptables file (omitting most of the file):

When I was looking at this earlier, I apparently didn't scroll down far enough in the file and missed it:o! The start() and stop() are functions at the top of the file , while the rest is inline. But RH 8.0 did not have the iptables-config file. So they've obviously changed something.

I am sorry for the long silence. I have been too busy this week and newton seems not to be causing any noticeable problems.
Thank you very much for your comments. I am sorry for my ignorance. You are completely right:
will do exactly the same I did manually.
Regarding
what happened was that I copied that from a terminal window and iptab was right at end of the screen. The noncomment nonblank lines from the file actually are
crontab runs daily a script called logwatch. As an example, I received today an email which, among other things gives me the following information, about yesterday
Regarding the last two lines I am sorting this out. There are people using public IPs linked to the internal switch. I find it odd that packets to the http, proxy and DNS ports are being dropped. As I said earlier, this is not noticeable.
I have listed below all the FORWARD drops form yesterday, which again I don’t understand.

I don't know what is going on either, but I do have some observations about the dropped packets on the FORWARD chain.

There were two packets which both entered and exited on eth0 when the address would indicate it should come in on eth1:

Of the others, most have the ACK and FIN flags set, and except for three packets, all of the rest have the RST (reset) flag set, either with or without the ACK flag set.

The three that don't meet any of the above criteria are:

Win32sux and I previously debated a situation with the FIN and ACK flags set. I don't think we came to any definitive decision. But both the FIN flag and RST flag have to do with a connection shutting down one way or the other. Maybe somebody else viewing this thread can come up with an explanation.

Also, heberrdacruz, I don't know how much you know about the tools in the Unix world, so forgive me if you already know this, but the grep command can come in quite handy in sorting through data like this.

EDIT: ipchains had the ability to adjust the timing parameters used in MASQueraded connections. I am unaware of any such ability in iptables to adjust the timing parameters for MASQUERADEd or SNATed connections. Does anybody know if there is a way to do that and whether it might have any bearing on the situation described here?