Odd PF Denied Message

Ian Smith smithi at nimnet.asn.au
Fri Oct 19 03:30:31 PDT 2007

On Fri, 19 Oct 2007, Nikos Vassiliadis wrote:
 > On Friday 19 October 2007 07:06:35 Ian Smith wrote:
 > > On Thu, 18 Oct 2007 19:36:27 +0300 Nikos Vassiliadis wrote:
 > >  > I think log_in_vain can be used when configuring a firewall.
 > >  > Just to see quickly if your firewall works as expected and
 > >  > then turn it off. Otherwise it is just going to create tons
 > >  > of irrelevant log messages.
 > >
 > > On the contrary .. if your firewall is working correctly, you shouldn't
 > > ever be seeing connection attempts to non-listening ports, especially
 > > from outside. 
 > Hey, we are saying the same thing, aren't we?

Well, not exactly :) but I don't think we have any serious disagreement.

 > > log_in_vain messages indicate some attention is needed, 
 > > either to block or reset those connections, or to provide a listener :)
 > > so removing log_in_vain (shooting the messenger) may not be a good idea.
 > Hm, almost the same thing. I tend to disagree with this. I prefer
 > log_in_vain off because usually a server will live in a DMZ. And
 > most of the time we donot bother runnning local firewalls one each
 > server and some will say it's wrong to do firewalling on each/a server.

Some will.  And some run only one server, and must be extra paranoid :)

 > Just one firewall protecting the DMZ. Other computing systems
 > living in the DMZ can cause noise, irrelevant log messages.
 > I remember a case where delayed replies from the DNS server were
 > logged by the kernel creating noise and bloating the logs.
 > Ofcourse YMMV...
 > But we basically say the same thing... Use log_in_vain to see what
 > passes your firewall and "touches" your servers. I prefer to turn
 > it off afterwards, Ian prefers to let it on.

Fair enough.  I don't see any harm in leaving it on, as I tend to pay
attention to any 'irrelevant' messages and fix the source of them, and
if something slips by the firewall I want to know about it.  Sometimes
that means such as delayed responses from DNS being logged, it's true.

In Michael's case in point it did indicate a problem though, or at least
a deficiency in the lack of handling ident requests.  As you say, YMMV.

Cheers, Ian

More information about the freebsd-questions mailing list