All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.