Fwd: Issues with pf and snmp
DAve
dave.list at pixelhammer.com
Wed Apr 21 13:10:24 UTC 2010
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 <dave.list at pixelhammer.com
> <mailto:dave.list at 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 at freebsd.org <mailto:freebsd-pf at freebsd.org> mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org
> <mailto:freebsd-pf-unsubscribe at 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
More information about the freebsd-pf
mailing list