iptable rules not being hit
in [Linux Networking]
|
Prev: Ubuntu Hardy and "Printer Sharing" -- securiry question
Next: Share clipboard and map network drive on rDesktop
From: R C V on 11 Apr 2008 12:53 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
From: Moe Trin on 11 Apr 2008 16:10 On Fri, 11 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in article <bda3c7c0-422b-4bec-8617-1e733be781c4(a)q27g2000prf.googlegroups.com>, 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
From: Andrew Gideon on 13 Apr 2008 12:17 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
From: Moe Trin on 14 Apr 2008 16:12 On Sun, 13 Apr 2008, in the Usenet newsgroup comp.os.linux.networking, in article <fttbnb$uiq$2(a)taco.int.tagonline.com>, 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
From: Andrew Gideon on 15 Apr 2008 08:22
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 |