Description of problem: The iptables and ip6tables configurations are not always synchronized by system-config-firewall. While attempting to figure out what is going on with bug# 431803 (selinux denials on access to /etc/sysconfig/iptables) I noticed this problem with system-config-firewall. The iptables and ip6tables configurations are not both being set by system-config-firewall writing the configuration (clicking Apply). This happens if iptables has a custom configuration, or if ip6tables has a custom configuration (this can be anything other than what system-config-firewall tried to load). If there is an iptables change made, then only ip6tables is getting a configuration loaded, leaving all the chains in iptables as they were. If there is an ip6tables change, then only iptables is getting loaded by system-config-firewall. What this means is all ipv4 traffic is coming in irregardless of settings in system-config-firewall because it only effected ipv6 traffic, not ipv4. Version-Release number of selected component (if applicable): system-config-firewall-1.2.2-1.fc9.noarch iptables-1.3.8-6.fc9.i386 Steps to Reproduce: - cd /etc/sysconfig - service iptables stop; service ip6tables stop; rm iptables ip6tables iptables.save ip6tables.save Now.. no configurations. 1. clear all configurations in iptables and ip6tables (iptables -F; ip6tables -F) 2. set FORWARD iptables chain to default DROP manually (iptables -P FORWARD DROP) 2. open system-config-firewall and set configuration 3. check iptables -L and ip6tables -L Actual results: All ipv4 traffic is permitted through iptables chains Expected results: Firewall configuration should apply to both iptables and ip6tables, removing prior changes Additional info: Here is what happens after system-config-firewall applies settings (load default configuration 'server') when ip6tables has no configuration but iptables DOES have a custom configuration. - iptables -P FORWARD DROP 18:59:32 |root:2| |58 files:468K@sysconfig| |1 jobs| - iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 18:59:35 |root:2| |58 files:468K@sysconfig| |1 jobs| - system-config-firewall [1]+ Done system-config-firewall 19:00:10 |root:2| |61 files:492K@sysconfig| |0 jobs| - iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination 19:00:13 |root:2| |61 files:492K@sysconfig| |0 jobs| - ip6tables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all anywhere anywhere state RELATED,ESTABLISHED ACCEPT ipv6-icmp anywhere anywhere ACCEPT all anywhere anywhere ACCEPT tcp anywhere anywhere state NEW tcp dpt:ssh REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain FORWARD (policy ACCEPT) target prot opt source destination REJECT all anywhere anywhere reject-with icmp6-adm-prohibited Chain OUTPUT (policy ACCEPT) target prot opt source destination
I can not reproduce your problem. When you hit apply, system-config-firewall is calling lokkit to generate the /etc/sysconfig/ip*tables files. lokkit reports an error if one or more files could not be written. Are the new ip*tables files in place and do they contain the correct configuration? Could it be that you have some other firewall configuration utility installed on your system, which is resetting the rules?
There is nothing else in place I know of that is changing the rules between system-config-firewall and looking back at the configuration. I can see that both configs are written if neither is edited manually and different to the other. If iptables and ip6tables are both removed from /etc/sysconfig then new files are written with correct perms, config, and contexts. But, if one is manually edited in the chain it does not save to that one (loaded in memory). I'm not sure whether it edits the file on disk, so I'll check into this more.
Created attachment 294857 [details] system-config-firewall-bash-tables-not-matched.txt Here is a set of commands run in order that show what I'm talking about with the two tables having unmatched configuration. It starts with my current firewall configuration (a bit convoluted, learning iptables tweaking) which I clear out. I then stop the services, remove their configurations, touch blank files, and customize only iptables. Then I run system-config-firewall, load default server config, disable/enable the firewall and apply the config. Notice after I've done that the two firewall tables are not both changed.
You have set IPTABLES_SAVE_ON_RESTART="yes" in /etc/sysconfig/iptables-config. This overwrites the configuration made by system-config-firewall. I will change the apply behaviour to 1) Stop the firewall 2) Write new config 3) Load new firewall configuration
Fixed in rawhide in package system-config-firewall-1.2.4-1.fc9.