netfilter buglog - Mar 2003 - [Bug 64] New: Conntrack-Table is not cleared on inferface down using target MASQUERADE

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.