Bug 247320
| Summary: | ip6tables INPUT filtering on source address blocks all traffic after a few seconds | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Tim Mooney <mooney> |
| Component: | kernel | Assignee: | Thomas Graf <tgraf> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Martin Jenner <mjenner> |
| Severity: | high | Docs Contact: | |
| Priority: | low | ||
| Version: | 4.6 | CC: | davem, development, nhorman, rkhan |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-08-16 18:19:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Thanks, Tim |
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: iptables-1.2.11-3.1.RHEL4 iptables-ipv6-1.2.11-3.1.RHEL4 On RHEL5: iptables-ipv6-1.3.5-1.2.1 iptables-1.3.5-1.2.1 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 *filter :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 COMMIT # 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 2001:4930:106::23. 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 -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 issue).