|
Bugzilla – Full Text Bug Listing |
| Summary: | SuSEFirewall2 leaves crippled iptables entries behind | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Helmut Cossmann <helmut.cossmann> |
| Component: | YaST2 | Assignee: | Ludwig Nussel <lnussel> |
| Status: | VERIFIED WORKSFORME | QA Contact: | Klaus Kämpf <kkaempf> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | lnussel, locilka, mvidner |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SuSE Pro 9.3 | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
Helmut: we opened bugzilla just for 10.x, so there is no option for 9.x or older bugs if you are not a beta tester. Usually we don't accept bugs for pre 10.0 (if not from a beta tester), anyway, let's ask the maintainer. Kurt or Lukas, any ideas from your side? Ludwig is the maintainer of the SuSEfirewall2, however if it doesn't start during the boot procedure, how could it fill-up some rules? I am only a maintainer of the yast2-firewall which configures SuSEfirewall2. It seems that some other application could fill them up. Well, it remembered me, that we were used to have a simple "personal firewall" too. But it has been dropped around 9.2 release (+-). Well, sure thing I can add some iptables statements to boot.local and force the rules back to the default setup. What completely trips me up is the fact that the other 3 9.3 systems that were installed of the same media using the same(!?) choices don't show this strange behavior. Just out of curiosity I added some "echo `date` >> /tmp/x" statements to the two shell scripts, rebooted and found the tag from SuSEfirewall2_init in /tmp/x. I'll try to get hold of the "callstack". Those are exactly the rules that SuSEfirewall2_init creates. It's not SuSEfirewall2's fault that someone calls it. You may try to run "SuSEfirewall2 off" which calls insserv -r -f to force removal of all symlinks. If that doesn't help you need to find out who calls SuSEfirewall2_init, I have no idea why anyone would do that. no feedback from reporter FYI: I changed the firewall scripts to dump the process env; the "call stack" looked like it came from one of the ifcfg-eth-id-* scripts as part of bringing up 'network'. So I started yast2 again, completely dropped the interface, saved the modification, quit yast2, restarted and recreated the interface. Everything is fine now. The only thing I noticed was that a variable setting with something like 'firewall' either in its value or name has disappeared from the ifcfg-eth-id-* script. |
First, this is on 9.3 pro but I'm finally giving up after 1 hour of being unable to locate 9.3 bug reporting. This is a brand new 9.3 pro installation, updated to the latest availabe patches around Dec 20, 2005. It replacing a 9.2 installation that has evolved out of an initial 6.x installation; the clean new installation is supposed to clean up various legacy things. Among other things the box is housing a dhcp server. I noticed that one of the client booting off this box wouldn't get it's IP address assigned; tcpdump showed that the request reached the 9.3 box but no response came back. 'ps' verified that the dhcpd server was running. I finally found that for some strange reasons iptables is in a state to drop all incomping packets. I rebooted the system, logged in and issued to following three commands to highlight the problem. The question is what is calling iptables here? # iptables -nvL Chain INPUT (policy DROP 42 packets, 4340 bytes) pkts bytes target prot opt in out source destination 274 21488 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 42 packets, 4340 bytes) pkts bytes target prot opt in out source destination 274 21488 ACCEPT all -- * lo 0.0.0.0/0 0.0.0.0/0 Chain reject_func (0 references) pkts bytes target prot opt in out source destination 0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with tcp-reset 0 0 REJECT udp -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable 0 0 REJECT all -- * * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-proto-unreachable # chkconfig --list | grep -i fire SuSEfirewall2_init 0:off 1:off 2:off 3:off 4:off 5:off 6:off SuSEfirewall2_setup 0:off 1:off 2:off 3:off 4:off 5:off 6:off # grep -i firewall /etc/sysconfig/network/config # With this variable you can determine if the SuSEfirewall when enabled FIREWALL="no"