[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    Re: 3.4.35 no output from `ipfstat -ion`
From:       Michal Mertl <mime () traveller ! cz>
Date:       2005-05-01 17:25:22
Message-ID: 1114968322.872.44.camel () genius1 ! i ! cz
[Download RAW message or body]

I wrote:
> Forgot to include mailing list in my reply. Sorry.
> 
> Tri pivceta wrote:
> > Hello everyone,
> > 
> > During the past week of intensive work on a DNS project, I've put IPFilter 
> > 3.4.35 in production.  Troubleshooting DNS with IP Filter became the order 
> > of the day, but I've also noticed that sometimes, seemingly at random, no 
> > output will be generated by `ipfstat -ion`, and it also seems that IP Filter 
> > won't log firther packet traversal when the packet matches the rule.
> > 
> > Searching up the IP Filter mailing list archives didn't turn up much; it was 
> > inconclusive at best.
> > 
> > I've noticed this: the ruleset is in place -- certain packets are passed and 
> > other are blocked, clearly matching the rules, the list generated by 
> > `ipfstat -ion` is reported as empty (in and out).

I now remembered a case where something was working even when I didn't
expect it. It was caused by the state table etries. Can in be the reason
of observed behaviour in your case? Did you flush the state table (with
'ipf -F S')? Even when the rule table as shown with 'ipfstat -ion' shows
no entries there may be some state table entries active. These can be
displayed with 'ipfstat -f' or 'ipfstat -t'.

> > 
> > Also, if I have a set of rules that define how a packet will flow, and am 
> > using 'local0.info' through syslogd, the rest of the flow won't show up in 
> > the log.  Perhaps I should 'up' the facility to debug, but I didn't test 
> > this yet, as I've solved the problems in the manwhile.  Nevertheless, it 
> > seems like a bug.
> > 
> > Examples:
> > pass in log level local0.info quick on qfe2 from x.x.x.x to x.x.x.x/32 keep 
> > state
> > pass out log level local0.info quick on qfe0 from x.x.x.x to x.x.x.x/32 keep 
> > state
> 
> Is it a router? If the numers (x.x.x.x and x.x.x.x/32) are the same in
> both places and the packets pass through it seems quite illogical and
> definitely suboptimal (to check the same packet twice and with the same
> rule is pointless).

After reading more about keep state it may be that when you use 'keep
state' the second rule is never checked - keep state creates an entry in
the state table which cause subsequent packets of a connection not to be
checked with firewall rules. Maybe even the first packets causes the
second line to be skipped (because on leaving the router there already
is an entry in the state table).

I also noticed there is never line with 'keep state' without 'proto
tcp/udp/icmp' in the documentation. Only tcp, udp and icmp (partially)
states are (according to the documentation) supported.


> > SOMETIMES, and I say sometimes, I'll see the packet be passed IN on qfe2, 
> > but I'll never see it logged as passed OUT on qfe0.  Sometimes, I won't see 
> > either in the log.
> > 
> > I allow that this may be an 'idiot user' error, but it looks like a bug to 
> > me.
> 
> It well may be bug of course. Have you tried logging more? Tried playing
> with option '-l' of ipf?
> 
> One more thing - I don't know details of either ipmon or your OS/syslogd
> operation but at least in general on FreeBSD with most programs you can
> lose some packets which go to the syslog. The socket, from which syslogd
> reads the log messages, has finite buffer and thus will drop some info
> when syslogd don't read it fast enough (e.g. it is waiting on disk I/O).
> Do you log very frequently? In this case sending messages directly to a
> file instead of through syslog with ipmon may help.
> 


Michal

[prev in list] [next in list] [prev in thread] [next in thread]