public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Olaf Zaplinski <olaf.zaplinski@web.de>
To: linux-kernel@vger.kernel.org
Subject: iptables: why different behaviour with two kernel versions?
Date: Fri, 08 Feb 2002 23:25:11 +0100	[thread overview]
Message-ID: <3C645047.C2C248B8@web.de> (raw)

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

             reply	other threads:[~2002-02-08 22:25 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-08 22:25 Olaf Zaplinski [this message]
2002-02-09  9:06 ` iptables: why different behaviour with two kernel versions? Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3C645047.C2C248B8@web.de \
    --to=olaf.zaplinski@web.de \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox