ip6tables -m state (match state) not working...
Jay Cliburn
jacliburn at bellsouth.net
Sun Oct 8 18:28:36 UTC 2006
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
More information about the fedora-test-list
mailing list