public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* iptables: why different behaviour with two kernel versions?
@ 2002-02-08 22:25 Olaf Zaplinski
  2002-02-09  9:06 ` Harald Welte
  0 siblings, 1 reply; 2+ messages in thread
From: Olaf Zaplinski @ 2002-02-08 22:25 UTC (permalink / raw)
  To: linux-kernel

Hi all,

my self made firewall at $HOME (iptables based) works fine, but the
accounting data it reports every day is not as expected.

The accounting rules are:

$IPTAB -N all-in
$IPTAB -N all-out
$IPTAB -N all-io
$IPTAB -A all-in
$IPTAB -A all-out
$IPTAB -A all-io
$IPTAB -A INPUT   -i $FW_DEV_EXT -j all-in
$IPTAB -A INPUT   -i $FW_DEV_EXT -j all-io
$IPTAB -A FORWARD                -j all-io
$IPTAB -A OUTPUT  -o $FW_DEV_EXT -j all-out
$IPTAB -A OUTPUT  -o $FW_DEV_EXT -j all-io

($FW_DEV_EXT = ppp0, ADSL)

I re-set the accounting log:

wally:~ # > /var/log/accounting
wally:~ # acct show
all-in            0.00 KBytes
all-io            0.00 KBytes
all-out           0.00 KBytes

and downloaded a file of exactly 1 MB. Then:

wally:~ # acct flush
wally:~ # acct show
all-in            0.06 KBytes
all-io         1447.77 KBytes
all-out           0.04 KBytes

(could be that client B generated some traffic also, I work at client A)
Shouldn't be all-io the summary of all-in and all-io? So I checked:

wally:~ # iptables -Z INPUT
wally:~ # iptables -Z FORWARD

... downloaded 1 MB again and ...

wally:~ # iptables -nvL INPUT
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source              
destination         
    0     0 all-in     all  --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          
    0     0 all-io     all  --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          
    0     0 ACCEPT     all  --  lo     *       0.0.0.0/0           
0.0.0.0/0          
   71  5100 ACCEPT     all  --  eth0   *       192.168.42.0/24     
192.168.42.0/24    
    0     0 log-in     all  --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          state INVALID 
    0     0 log-in     all  --  ppp0   *       127.0.0.0/8         
0.0.0.0/0          
    0     0 log-in     all  --  ppp0   *       10.0.0.0/8          
0.0.0.0/0          
    0     0 log-in     all  --  ppp0   *       172.16.0.0/12       
0.0.0.0/0          
    0     0 log-in     all  --  ppp0   *       192.168.0.0/16      
0.0.0.0/0          
    0     0 ACCEPT     icmp --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          icmp type 8 limit: avg 2/sec burst 2 
    0     0 LOG        icmp --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          icmp type 8 limit: avg 1/sec burst 2 LOG flags 0 level 4
prefix 
`iptab-limit ' 
    0     0 DROP       icmp --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          icmp type 8 
    0     0 ACCEPT     all  --  eth0   *       192.168.42.0/24     
0.0.0.0/0          state NEW,RELATED,ESTABLISHED 
    0     0 ACCEPT     udp  --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          udp dpts:6970:7170 
    0     0 REJECT     tcp  --  ppp0   *       0.0.0.0/0           
62.109.72.140      tcp dpt:113 reject-with tcp-reset 
    0     0 ACCEPT     all  --  ppp0   *       0.0.0.0/0           
62.109.72.140      state RELATED,ESTABLISHED 
    0     0 log-in     all  --  ppp0   *       0.0.0.0/0           
0.0.0.0/0          state INVALID,NEW 
    0     0 log-in     all  --  *      *       0.0.0.0/0           
0.0.0.0/0          

Yup, there are many bytes missing here. And yes, this rules are probably not
perfect. ;-) But in FORWARD it's okay:

wally:~ # iptables -nvL FORWARD
Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source              
destination         
 1220 1088K all-io     all  --  *      *       0.0.0.0/0           
0.0.0.0/0          
   51  2448 TCPMSS     tcp  --  *      *       0.0.0.0/0           
0.0.0.0/0          tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
    0     0 log-fwd    all  --  *      ppp0    192.168.42.0/24     
207.46.209.203     
    0     0 log-fwd    all  --  *      ppp0    207.46.209.203      
0.0.0.0/0          
    0     0 log-fwd    all  --  *      *       0.0.0.0/0           
127.0.0.0/8        
    0     0 log-fwd    all  --  *      *       0.0.0.0/0           
10.0.0.0/8         
    0     0 log-fwd    all  --  *      *       0.0.0.0/0           
172.16.0.0/12      
  775 1065K ACCEPT     all  --  *      *       0.0.0.0/0           
192.168.42.0/24    
    0     0 log-fwd    all  --  *      *       0.0.0.0/0           
192.168.0.0/16     
  445 22977 ACCEPT     all  --  *      ppp0    192.168.42.0/24    
!192.168.42.0/24    state NEW,RELATED,ESTABLISHED 
    0     0 ACCEPT     all  --  *      eth0   !192.168.42.0/24     
192.168.42.0/24    state RELATED,ESTABLISHED 
    0     0 log-fwd    all  --  *      *       0.0.0.0/0           
0.0.0.0/0          

So I built the 2.4.13 kernel to test that and got dozens of rejects in the
logs, e.g. UDP connects to the DNS forwarders... so I could not test the
accounting stuff. I switched back to 2.4.17 and everything was fine again.

So what's wrong with iptables-1.2.4 userland tools and 2.4.[13|17]? Why is
iptables-rules@2.4.13 not the same as iptables-rules@2.4.17?

Olaf

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2002-02-09  9:13 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-02-08 22:25 iptables: why different behaviour with two kernel versions? Olaf Zaplinski
2002-02-09  9:06 ` Harald Welte

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox