[Bug 64] New: Conntrack-Table is not cleared on inferface down using target MASQUERADE
bugzilla-daemon@netfilter.org
bugzilla-daemon@netfilter.org
Sat, 15 Mar 2003 21:15:48 +0100
https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=64
Summary: Conntrack-Table is not cleared on inferface down using
target MASQUERADE
Product: netfilter/iptables
Version: linux-2.4.x
Platform: i386
OS/Version: other
Status: NEW
Severity: normal
Priority: P2
Component: NAT
AssignedTo: laforge@netfilter.org
ReportedBy: tobias@portfolio16.de
CC: netfilter-buglog@lists.netfilter.org
Hi,
I'm a developer for the fli4l (http://www.fli4l.de/) floppy-router-project. Recently I came across
the message "ip_conntrack: table full, dropping packet.". Since I'm using DSL with PPPoE,
which is automatically disconnected by the provider after 24 hours, I thought, the table should
be flushed at every disconnect. This is waht the manpage states:
--- cut here ---
MASQUERADE
This target is only valid in the nat table, in the POSTROUTING chain.
It should only be used with dynamically assigned IP (dialup) connec-
tions: if you have a static IP address, you should use the SNAT target.
Masquerading is equivalent to specifying a mapping to the IP address of
the interface the packet is going out, but also has the effect that
connections are forgotten when the interface goes down. This is the
correct behavior when the next dialup is unlikely to have the same
interface address (and hence any established connections are lost any-
way).
--- cut here ---
The router has two internal nats attached (192.168.1.* and 192.168.2.*) and the
PPPoE-connection to the internet, the iptables are set up the following way:
--- cut here ---
sord 2.1.2tg # iptables -L -n
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- 192.168.1.0/24 192.168.2.0/24
ACCEPT all -- 192.168.2.0/24 192.168.1.0/24
ACCEPT all -- 127.0.0.1 127.0.0.1
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
ACCEPT all -- 192.168.1.0/24 0.0.0.0/0
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
REJECT all -- 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 192.168.1.0/24 192.168.2.0/24
ACCEPT all -- 192.168.2.0/24 192.168.1.0/24
REJECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpts:137:139 reject-with
icmp-port-unreachable
REJECT udp -- 0.0.0.0/0 0.0.0.0/0 udp dpts:137:139 reject-with
icmp-port-unreachable
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
sord 2.1.2tg # iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.1.0/24 0.0.0.0/0
MASQUERADE all -- 192.168.3.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
--- cut here ---
I did a little grep'ing around with a /proc/net/ip_conntrack file I copied from the router to my
workstation (no wc on router):
--- cut here ---
tobias@lafiel:/tmp$ wc -l ip_conntrack
2408 ip_conntrack
tobias@lafiel:/tmp$ grep -v "192\.168\.2\." ip_conntrack | grep -v "127\.0\.0\.1
" | grep -v "A\.B\.C\.D" | wc -l
1236
--- cut here ---
(where A.B.C.D is the current IP-address of the ppp0-interface)
All of these connections where ESTABLISHED and [ASSURED], if that helps.
All of these connections have an IP-address out of my providers dynamic range in the first
dst= field (the 6. field) and one of my local addresses in the second src= field (the 9. field), so
that I'm sure about the fact that this are leftovers from previous connections to the internet. As
a counclution, I think there is a bug in the clean-up code for the MASQUERADE-target. Please
tell me whatt to to about it!
TIA
Greetings Tobias
PS: Some data about the router system (Could be relevant?!?):
Kernel: Linux version 2.4.20 (robert@fli4l.de) (gcc version 2.95.4 20011002 (Debian
prerelease)) #1 Fri Dec 27 13:11:05 MET 2002
iptables v1.2.2
uclibc 0.9.15
busybox 0.60.5
CyrixInstead 5x86 3x Core/Bus Clock (33.28 BogoMIPS)
24 MB RAM
3x ISA 3c509
ITK Columbus World ISDN-Card
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.