On Sun, 2006-10-08 at 13:28 -0500, Jay Cliburn wrote: > Michael H. Warfield wrote: > > 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 > > > I whined about this back in July. Nobody cared. > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=190590 So it seems, so it seems. I did searches for iptables and ip6tables and came up empty handed. IAC... If it's busted then it needs to be disabled. As it is now, it leaves the core IPv6 networking in a totally non-functional state. > Jay 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