Red Hat Bugzilla – Bug 247320
ip6tables INPUT filtering on source address blocks all traffic after a few seconds
Last modified: 2014-06-18 04:29:34 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):
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
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-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
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.
Any connections (whether they're new or established) from the listed networks
should be allowed.
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
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
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
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.
Thanks, I agree with your assessment.
Are you still seeing the problem with a current release?
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.
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.