From owner-freebsd-pf@FreeBSD.ORG Wed Apr 21 13:10:24 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A719E1065674 for ; Wed, 21 Apr 2010 13:10:24 +0000 (UTC) (envelope-from dave.list@pixelhammer.com) Received: from smtp1.tls.net (smtp1.tls.net [65.124.104.104]) by mx1.freebsd.org (Postfix) with ESMTP id 4DA7E8FC18 for ; Wed, 21 Apr 2010 13:10:23 +0000 (UTC) Received: (qmail 68396 invoked from network); 21 Apr 2010 13:10:22 -0000 Received: by simscan 1.4.0 ppid: 68345, pid: 68389, t: 4.3727s scanners: attach: 1.4.0 clamav: 0.95.3/m:52/d:10766 spam: 3.2.1 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on smtp1.tls.net X-Spam-Level: * X-Spam-Status: No, score=1.6 required=7.0 tests=ALL_TRUSTED,TVD_RCVD_IP autolearn=disabled version=3.2.1 Received: from 64-184-11-205.bb.hrtc.net (HELO ?192.168.1.46?) (ldg@tls.net@64.184.11.205) by ssl-smtp1.tls.net with ESMTPA; 21 Apr 2010 13:10:18 -0000 Message-ID: <4BCEF926.9060800@pixelhammer.com> Date: Wed, 21 Apr 2010 09:09:58 -0400 From: DAve User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: freebsd-pf@freebsd.org References: <4BBF59E2.80303@pixelhammer.com> <4BBF8629.1090109@pixelhammer.com> <4BC72457.1000202@pixelhammer.com> <4BC7E357.2070203@pixelhammer.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Fwd: Issues with pf and snmp X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 13:10:24 -0000 Top posting for a reason. I appreciate all the help but I will no be working on this problem any longer. My position has been closed and I am out of a job. So the FW is someone else's problem now. Again, a thanks for the help from everyone both on and off list. DAve Peter Maxwell wrote: > > > On 16 April 2010 05:11, DAve > wrote: > > DAve wrote: > > Peter Maxwell wrote: > >> Can't see anything obvious but have you tried these things in the > event > >> something strange is going on: > >> > >> - removing the scrub rule; > >> > >> - removing the antispoof rule; > >> > >> - add 'log' to the the pass rules and then check to see if there > are any > >> other snmp udp packets getting passed/dropped in the wrong place. > > > > A good idea. I will try to get that done this evening, though I am > > running 100% until Monday. > > > > > > Nope, no scrubbing no antispoof, same result exactly. I did check > snmpget and it seemed to work. I will check which oid is next in line > and see if I can get that value next. > > > If snmpget is working, pf is passing packets and there is something > unexpected happening. I'd start opening up your ruleset until it works > or you reach a 'pass all' ruleset (with the former you've found the > problem, in the later you know for certain pf is the problem). > > - add an equivalent 'pass out' rule for the network; > > - change the pass rule to be 'from to any'; > > - comment out the three unnecessary block rules (3 through 5); > > - remove *all* instances of the 'quick' keyword; > > - move the snmp rules to immediately underneath the first block rules; > > - remove all the pass rules and replace with pass in from any to $ext_if > & pass out from $ext_if to any. > > If you've reached this far and it still doesn't work then, erm, we'll > deal with that if it happens. > > > > > It appears some restriction on the snmpwalk, possibly a limit on how > many results are being returned? (Shooting in the dark now). > > > No, that would be on the application layer, the tcpdump output showed an > inbound udp packet getting blocked. The only difference I can imagine > between snmpget and snmpwalk would be the size of the packets, number of > packets, or source port numbers. > > I'd try doing a tcpdump on the dc0 interface of the snmpwalk session > when pf isn't loaded then load pf and collect a tcpdump from both the > dc0 and pflog0 interfaces. There should be enough information in those > three datasets to discover what on earth is going on. > > > > > I use Cacti everywhere within our networks, no snmpwalk is a show > stopper for me here... > > DAve > > > -- > "Posterity, you will know how much it cost the present generation to > preserve your freedom. I hope you will make good use of it. If you > do not, I shall repent in heaven that ever I took half the pains to > preserve it." John Adams > > http://appleseedinfo.org > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org > " > > -- "Posterity, you will know how much it cost the present generation to preserve your freedom. I hope you will make good use of it. If you do not, I shall repent in heaven that ever I took half the pains to preserve it." John Adams http://appleseedinfo.org