Fwd: Issues with pf and snmp
peter at allicient.co.uk
Fri Apr 16 05:13:47 UTC 2010
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...
> "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
> freebsd-pf at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-pf-unsubscribe at freebsd.org"
More information about the freebsd-pf