Fwd: Issues with pf and snmp

[Peter Maxwell]

On 16 April 2010 05:11, DAve <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 mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-pf
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
>