Hey all, I've found that the IPv6 state matching is non-functional in FC6. I first tried it in Test3 and have just reinstalled the entire system from scratch from rawhide and verified it from the latest rawhide. As installed, ip6tables has included the following default rules in the rule sets (for this particular install): : -A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m udp -p udp --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 445 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -j DROP With those rule sets, I was unable to establish any IPv6 connections to or from the box. Specifically, attempting to connect to the box with ssh (22/tcp) resulted in a timeout (DROP). While timing out, a check on the server indicated no socket indicating a connection attempt. The client system (other system) has a socket in SYN SENT. It appears, in this case, that the "-m state --state NEW" for port 22 was not triggered and we fell through to the "-j DROP" rule at the end. In the outbound case, the connection also times out but, this time, the while the client system (this system) is in SYN SENT, the other system is on SYN RECV. That indicates that the SYN packet was sent out successfully and the other system did respond but the response was not allowed back. In this case, it's the "-m state --state ESTABLISHED,RELATED" rule failed to trigger and the packet is, again, dropped. If I add a rule "-m tcp -p tcp --dport 22 -j ACCEPT" with no state matching, then inbound ssh connections succeed and function. Outbound connections still fail though, because the ESTABLISHED state match still isn't firing and now it a source port 22 on the incoming packets. So, I can add a second rule "-m tcp -p tcp --sport 22 -j ACCEPT" to solve that one. Basically, the only way to work around it is to put in stateless filtering (which is working). So the stateful filtering is broken for IPv6. Worth noting that stateful filtering didn't even exist in FC5 and earlier (I think it was introduced in kernel 2.6.16 or somewhere thereabouts) so it's pretty new anyways. But it does mean that, if you enabled the firewall, IPv6 becomes pretty much non-functional because the firewall is failing and dropping everything coming in. Filed in bugzilla: 209945 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209945 Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 985-6132 | mhw@xxxxxxxxxxxx /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list