This was mentioned by Graham Murray on gentoo-user and I've just confirmed. The old --state matches were deprecated in favor of the new conntrack stuff, and when upgrading, your old state rules get clobbered. Steps to reproduce: # emerge -1 =net-firewall/iptables-1.4.13 # sudo iptables -A INPUT -p ALL -m state --state NEW,INVALID -j DROP This should disallow new and invalid connections. # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 state INVALID,NEW Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination Now upgrade to iptables-1.4.16.3: # emerge -1 =net-firewall/iptables-1.4.16.3 The state rule is now broken: # iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination DROP all -- 0.0.0.0/0 0.0.0.0/0 state Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination The same thing happens if we try to -j ACCEPT connections of state ESTABLISHED or RELATED. So while I'm not sure how iptables will handle this, one case or the other is a problem. We *definitely* need a big warning for this.
I just realized the fix may not be obvious, so here it is: recreate all of your state rules and then save them. I have an iptables-config script that does this, and even with the old --state matches it works (albeit with warnings). The new iptables will convert these rules to conntrack rules, at which point it's safe to `/etc/init.d/iptables save`.
we could add an elog, but i'm not sure we'd add anything else
(In reply to comment #2) > we could add an elog, but i'm not sure we'd add anything else With my particular set of rules, I wouldn't see it, because my SSH packets will be dropped.
I have two groups of people in mind: 1. People who admin over SSH and will have their connections dropped after the upgrade. Those people won't be able to see an elog, and they may have a huge hole opened in their firewalls until they can physically get to the server to fix it. Or maybe there's no hole, because everything is blocked, and they have to get to the server to fix /that/. I fit into this category, and was lucky that someone was nice enough to point out the breakage before it happened. 2. Those people who either admin locally, or whose SSH rules will keep working after the upgrade. They're able to see the elog, but it's kind of rude to have an elog that says "Hey, we just broke your firewall, we hope you remember what the rules were!" You can't fix it easily without knowing which rules to recreate. While they scramble to figure out what to do, they might have a hole in their firewall. Or everything might be down. Before the upgrade, you can just dump your iptables state and see which state rules you've got. After the upgrade, you can recreate them and everything will be OK (if your SSH connection didn't just get dropped). But if you don't know to look beforehand and you upgrade, the rules get clobbered and you have to know what they were to fix everything. The proper fix, before it breaks, is to replace all of your state matches with conntrack matches, and `/etc/init.d/iptables save`. Then the upgrade works normally. But you can't do this unless you know about it beforehand.
Adding to the discomfort, ones potentially needs to recompile his kernel. Newer iptables requires NETFILTER_XT_MATCH_CONNTRACK, whereas the old state matches used NETFILTER_XT_MATCH_STATE.
could you post the phrasing you'd like to see in the elog ?
(In reply to comment #6) > could you post the phrasing you'd like to see in the elog ? It's pointless now. Three months later, everyone's state rules are long gone. User action was required *before* the upgrade.
so it goes
