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

* Re: iptables: why different behaviour with two kernel versions?
  2002-02-08 22:25 iptables: why different behaviour with two kernel versions? Olaf Zaplinski
@ 2002-02-09  9:06 ` Harald Welte
  0 siblings, 0 replies; 2+ messages in thread
From: Harald Welte @ 2002-02-09  9:06 UTC (permalink / raw)
  To: Olaf Zaplinski; +Cc: linux-kernel, netfilter

On Fri, Feb 08, 2002 at 11:25:11PM +0100, Olaf Zaplinski wrote:
> Hi all,

Hi Olaf.

Please direct iptables usage questions to the netfilter@lists.samba.org
mailinglist (as stated in the MAINTAINERS file).

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

>From what you have written, I can draw the assumption that you think
forwarded packets go through INPUT or OUTPUT?  Then you're thinking in
2.2.x ipchains terms.

In 2.4.x (== iptables) firewalling, forwarded packets go only through 
output.

> 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?

Maybe something else in your setup was different?  There is no difference
between the filter table in 2.4.13 and 2.4.17.

> Olaf

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+ 
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)

^ 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