iptable rules not being hit

Hi,
I had a working system with iptable rules which were working fine
till the time I hit on these updates button which was prompting me to
load some 277 new updates. I am running Fedora Core 6. Is it
possible that these updates would have reset some setting due to which
iptables has become non functional...

I ran wireshark on the remote systems and I saw that my NAT rules are
being completely bypassed, whereas those very rules were working
before I applied those updates.

I am looking for some help in figuring if there is some setting/value
which can explain the above behaviour.

Thanks,
R C


R C V

On Fri, 11 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <bda3c7c0-422b-4bec-8617-(E-Mail Removed)>,
R C V wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

> I had a working system with iptable rules which were working fine
>till the time I hit on these updates button which was prompting me to
>load some 277 new updates. I am running Fedora Core 6.

That's getting a bit on the old side - I'm told that FC 9 will be out
in the next few weeks. "277 new updates" - that's a lot. Did you
look to see what they were?

>Is it possible that these updates would have reset some setting due
>to which iptables has become non functional...

Anything is possible - but it's awfully hard to see your system from
here, so we can't tell what you have configured, how, and so on.

>I ran wireshark on the remote systems and I saw that my NAT rules are
>being completely bypassed, whereas those very rules were working
>before I applied those updates.

I'd start by looking at the boot scripts to see HOW the firewall is
being started. I'd also look at the network configuration - which
interface is which, and so on. What run-level? How did you set up
the firewall? Then look in /var/log/messages to see what messages
are there from your last re-boot. If you are running a text based
login (runlevel 3), BEFORE YOU LOG IN after a re-boot, hit the shift
and page-up keys to scroll back through the boot error messages.

Old guy

On Fri, 11 Apr 2008 15:10:26 -0500, Moe Trin wrote:

> I'd start by looking at the boot scripts to see HOW the firewall is
> being started.

Why? I'd start by checking the rules to see why the matches the OP
presumes should be occurring might not be occurring. If iptables -nL
reports the presence of the rules he expects, what could be in the boot
log that would explain the described symptoms?

I'd guess that either his rules were modified by the upgrade (or
something else at around the same time; perhaps he'd previously made a
change that he'd never tested until now) or some semantic altered enough
to bite him.

I've an old desktop that I've yet to upgrade from FC6 (though I know that
I should {8^). I've played with NAT using iptables on it, and I've never
noticed a problem.

- Andrew

On Sun, 13 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <fttbnb$uiq$(E-Mail Removed)>, Andrew Gideon wrote:

>Moe Trin wrote:

>> I'd start by looking at the boot scripts to see HOW the firewall is
>> being started.
>
>Why? I'd start by checking the rules to see why the matches the OP
>presumes should be occurring might not be occurring. If iptables -nL
>reports the presence of the rules he expects, what could be in the boot
>log that would explain the described symptoms?

I'm pretty sure you'll find '/sbin/iptables -nL' isn't going to show
any rules.

>I'd guess that either his rules were modified by the upgrade

If some distribution updated messed with the local configuration files,
that's the last time I'd be using that distribution. The programmers
at the distribution don't know ANYTHING about how my LAN might be
configured, never mind which network interface leads where. Therefore
they should not be altering those configurations. This is why most
distributions make you put "local" stuff into locally administered
files with "standard" names. Can you imagine the chaos if an update
replaced /etc/sysconfig/network-scripts/ifcfg-eth0 with a "new" (and
most likely generic) file?

>(or something else at around the same time; perhaps he'd previously
>made a change that he'd never tested until now) or some semantic
>altered enough to bite him.

What I'd expect is a network configuration issue - such that the
networks were not functional at the time the firewall scripts were run.
An example might be a slow DHCP process. I had a provider who was slow
to assign IP addresses, and had to put in a sixty second delay in the
scripts to provide enough time for their crappy DHCP server to pull
it's finger out and assign an address that I could then include in
the firewall NAT rules.

>I've an old desktop that I've yet to upgrade from FC6 (though I know
>that I should {8^).

#include <std.lecture.keeping.OS.up.to.date.h>

>I've played with NAT using iptables on it, and I've never noticed a
>problem.

Depends on how complex your ruleset is. I also had a case long ago of
an update changing the order of which NIC was assigned eth0 verses eth1
and so one. That one took more than a few minutes to find at Bleary-o-clock
in the morning.

Old guy

On Mon, 14 Apr 2008 15:12:34 -0500, Moe Trin wrote:

> I'm pretty sure you'll find '/sbin/iptables -nL' isn't going to show any
> rules.

Oh. I'd just assumed that the OP would have checked this before posting
"rules not being hit" instead of "rules getting lost" or some such
thing.

[...]
> I also had a case long ago of
> an update changing the order of which NIC was assigned eth0 verses eth1

Ouch! That would be ugly.

- Andrew