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
Jay
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list