Date: Fri, 16 Apr 2010 06:13:46 +0100 From: Peter Maxwell <peter@allicient.co.uk> To: DAve <dave.list@pixelhammer.com> Cc: freebsd-pf@freebsd.org Subject: Re: Fwd: Issues with pf and snmp Message-ID: <z2s7731938b1004152213nd6c260a1w89d98dcbf6c6568@mail.gmail.com> In-Reply-To: <4BC7E357.2070203@pixelhammer.com> References: <4BBF59E2.80303@pixelhammer.com> <m2r7731938b1004091234yeaf9eaa1i92a48fbf28610408@mail.gmail.com> <4BBF8629.1090109@pixelhammer.com> <h2s7731938b1004091716z2f460770w2eb2034c8d6a411c@mail.gmail.com> <q2m7731938b1004091718m17ab4750u66308a1120337065@mail.gmail.com> <4BC72457.1000202@pixelhammer.com> <4BC7E357.2070203@pixelhammer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 April 2010 05:11, DAve <dave.list@pixelhammer.com> 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 <monitoring> network; - change the pass rule to be 'from <monitoring> 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" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?z2s7731938b1004152213nd6c260a1w89d98dcbf6c6568>