Skip site navigation (1)Skip section navigation (2)
Date:      25 Oct 2002 11:53:35 -0700
From:      swear@attbi.com (Gary W. Swearingen)
To:        Bryan Cassidy <bryanc2000@insightbb.com>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Whats the deal?
Message-ID:  <t2znt2wdsg.nt2@localhost.localdomain>
In-Reply-To: <20021025031957.797b2ca1.bryanc2000@insightbb.com>
References:  <20021025005639.507fd4a1.bryanc2000@insightbb.com> <20021025062905.GC70503@vectors.cx> <20021025013131.13ddf403.bryanc2000@insightbb.com> <005b01c27bf0$9f26c1c0$780010ac@KENNETH> <20021025031957.797b2ca1.bryanc2000@insightbb.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Bryan Cassidy <bryanc2000@insightbb.com> writes:

> here is the output from "ipfw show"
> 
> insightbb# ipfw show
> 01000 307 64003 allow ip from any to any
> 65535   1   367 deny ip from any to any
> 
> Sounds like the 'deny ip from any to any' could be the reason why I
> lose connection. Do you think so?

No. I think you got a bum steer.  RTFM.  That "ip" bit is the same as
"all".  Any packet that the filter CAN block (only IP pkts) will be
passed by your rule 01000 and so the final rule will never be used
whether it's drop or pass.

And the counts there show that it has passed 307 pkts.
Your problem seems to lie elsewhere.

You could do from your shell:
    ipfw add 100 pass log logamount 1000 all from any to any
to get info on the next 1000 pkgs you pass, but I'm not sure
how that'd help you.

DNS is a frequent culprit.

P.S. Leaving your kernel so rule 65535 is deny is safest from a 
security standpoint because it protects you before the filter 
rules are configured and if they should get deleted, but there
is some chance of limiting you to console access, so people
differ on which default they prefer.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?t2znt2wdsg.nt2>