Bug 247320 - ip6tables INPUT filtering on source address blocks all traffic after a few seconds
ip6tables INPUT filtering on source address blocks all traffic after a few se...
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Thomas Graf
Martin Jenner
Depends On:
  Show dependency treegraph
Reported: 2007-07-06 17:52 EDT by Tim Mooney
Modified: 2014-06-18 04:29 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-08-16 14:19:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Mooney 2007-07-06 17:52:00 EDT
Description of problem:

On both RHEL4u5 and RHEL5, if you install an INPUT filter that allows all
traffic from a particular network but DROPs all other traffic, it will function
correctly for a few seconds, but then it will also begin dropping the traffic
from the network(s) that should be allowed.

Version-Release number of selected component (if applicable):

On RHEL4u5:




How reproducible:

Always, though the amount of time it takes before the ip6tables firewall begins
to block the traffic that we believe it should continue to allow is variable.

Steps to Reproduce:

On a RHEL4u5 host with IPv6 configured:
$/sbin/ifconfig -a | egrep '2001:'
          inet6 addr: 2001:4930::74/64 Scope:Global

Install the following simple ip6tables firewall:

$ sudo cat /etc/sysconfig/ip6tables
-A INPUT -i lo -j ACCEPT 
-A INPUT -s 2001:4930::0/64 -i eth0 -j ACCEPT 
-A INPUT -s 2001:4930:106::0/64 -i eth0 -j ACCEPT 
# Completed on Sun Apr  1 08:09:00 2007

We believe this firewall should:

- allow any IPv6 traffic over the loopback
- allow any IPv6 traffic on eth0 from the network 2001:4930:0000:0000
- allow any IPv6 traffic on eth0 from the network 2001:4930:0106:0000

Activate the ip6tables firewall:
$ sudo service ip6tables start
Flushing firewall rules: [  OK  ]
Setting chains to policy ACCEPT: filter [  OK  ]
Unloading ip6tables modules: [  OK  ]
Applying ip6tables firewall rules: [  OK  ]

From a separate system with an IPv6 address on the 2001:4930:0106:0000 network,
ssh into the box:

$ ssh -6 2001:4930::74
Last login: Fri Jul  6 13:28:16 2007 from ...

[now, on the new box with the ip6tables firewall enabled, (quickly) run netstat
to verify that the connection came in over IPv6]:

$netstat -A inet6 -n | egrep '106:'
tcp        0    352 2001:4930::74:22      2001:4930:106::23:37244 ESTABLISHED 
tcp        0      0 2001:4930::74:22      2001:4930:106::23:35841 ESTABLISHED 
tcp        0      0 2001:4930::74:22      2001:4930:106::23:37106 ESTABLISHED 

As you can clearly see, it allowed me in, and I came from a system that should
match the second IPv6 network in the INPUT allow chain (-s 2001:4930:106::0/64).
This much is expected.

However, after 8-15 seconds, the ssh connection locks up.  In addition, no new
IPv6 connections (ssh, ping, etc.) are allowed from the machine with a source of

Actual results:

The INPUT rule will briefly allow both incoming and established connections that
match any of the source (network) addresses specified, but then eventually it
quits allowing them and starts dropping packets from those networks.

Expected results:

Any connections (whether they're new or established) from the listed networks
should be allowed.

Additional info:

Note that it doesn't matter if I use a source that's a network (-s
2001:4930:106::0/64) or a source that's a specific host (-s
2001:4930:106::23/128).  If I activate the ip6tables firewall using INPUT rules
that use source, the ip6tables will briefly allow new connections from that
address, but after a few seconds, new connections will no longer be allowed and
established connections will begin to be dropped.

Also, we're using analogous rules for IPv4 (exact same set of rules, it's only
the source addresses that change), and those work exactly as expected.  The one
difference for our IPv4 rules is that we also include a


rule.  That's not currently an option for ip6tables on RHEL4, since RHEL4
doesn't ship a state module (which I consider a big problem, but is a separate
Comment 1 Thomas Woerner 2007-07-25 07:57:27 EDT
iptables is the userland configuration tool for netfilter - the kernel part. If
it is working at fist, this can not be a configuration problem.

Assigning to kernel.
Comment 2 Tim Mooney 2007-07-25 12:50:24 EDT
Thanks, I agree with your assessment.
Comment 3 Thomas Graf 2008-06-13 16:30:20 EDT
Are you still seeing the problem with a current release?
Comment 4 Tim Mooney 2008-06-20 17:48:42 EDT
It seems to be behaving differently now, but I don't believe it's functioning
correctly.  I'll do some more diagnostics and add more info as soon as I can.
Comment 5 Tim Mooney 2009-08-13 17:06:06 EDT
Wow, sorry it took more than a year for me to get back to this.  I suck.

I just did some testing with the latest 4.8 kernel, and I can no longer reproduce the problem.  It looks like the ip6tables firewall is now working as we expected.

You can close this one as fixed.



Note You need to log in before you can comment on or make changes to this bug.