I'm trying to find a generic solution that would comply with standard
3rd party SNMP trap receivers (HP openview, MG-SOFT MIB Browser,...).

Currently the only solution I see is to have net-snmp send the informs
from constant ports, and open those UDP ports in the Firewall.

Regarding your suggestions:
1) It seems that allowing all UDP traffic from a certain IP address is
not secure enough for my needs.
2) The MG-SOFT MIB Browser I'm working with sends the inform ACKs from a
random port (not 162).


-----Original Message-----
From: dave.shield@googlemail.com [mailto:dave.shield@googlemail.com] On
Behalf Of Dave Shield
Sent: Tuesday, February 27, 2007 1:28 AM
To: Makavy, Erez (Erez)
Cc: Wes Hardaker; net-snmp-coders@lists.sourceforge.net
Subject: Re: Disabling engineID Probe for Informs

On 26/02/07, Makavy, Erez (Erez) wrote:
> It then seems that the only solution for supporting informs in a
> "firewalled" system, is to use a fixed port (or range of ports) as the

> source port for the sent informs,

For a TCP-based transport, this sort of response to an outgoing request
would presumably be recognised as relating to the
original (authorised) request, so would be allowed. I'm presuming
that the problem here arises because SNMP notifications are usually sent
over UDP, and the firewall can't automatically make the connection
between the two packets.

So one possible workaround might be to send the INFORM request over TCP
rather than UDP.

An alternative would be to configure the firewall to accept notification
responses based on the source address (i.e.
the notification receiver) rather than the destination (the agent).
That would naturally be a fixed UDP port (typically 162), so it would be
straightforward to configure the firewall accordingly.


This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Net-snmp-coders mailing list