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