SNMP port forwarding



  • hey guys, i thought this would be pretty straight forward, but it's taking me way longer than I thought to simply port forward UDP 162 .

    I created a rule to Pass from WAN interface to a single address with destination port 162.  Source is any.  I have no other rules except for the default RFC 1918 and Bogon one.  I enabled logging and do see the traffic passing through to my SNMP daemon, but the daemon is not recording anything.  If I change my test computer to on the internal address space (bypassing the firewall), the daemon does record the test trap.  But when I put the test computer outside the firewall, it does not record anything.

    Any ideas?


  • Rebel Alliance Developer Netgate

    How are you testing the forward?

    udp/162 is only for SNMP Traps. udp/161 is for SNMP queries.

    Do you see anything blocked in the firewall log for that port?
    Anything showing in the states table for the port?
    Does the request show up on WAN in a packet capture?

    More tips here:
    https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting


  • Galactic Empire

    Wouldn't you be better doing it over an IPsec Tunnel ?

    SNMP isn't NAT friendly :-

    https://www.ietf.org/rfc/rfc3027.txt

    4.8 SNMP

    SNMP is a network management protocol based on UDP.  SNMP payload may
      contain IP addresses or may refer IP addresses through an index into
      a table.  As a result, when devices within a private network are
      managed by an external node, SNMP packets transiting a NAT device may
      contain information that is not relevant in external domain.  In some
      cases, as described in [SNMP-ALG], an SNMP ALG may be used to
      transparently convert realm-specific addresses into globally unique
      addresses.  Such an ALG assumes static address mapping and bi-
      directional NAT.  It can only work for the set of data types (textual
      conventions) understood by the SNMP-ALG implementation and for a
      given set of MIB modules.  Furthermore, replacing IP addresses in the
      SNMP payload may lead to communication failures due to changes in
      message size or changes in the lexicographic ordering.

    Making SNMP ALGs completely transparent to all management
      applications is not an achievable task.  The ALGs will run into
      problems with SNMPv3 security features, when authentication (and
      optionally privacy) is enabled, unless the ALG has access to security
      keys.  [NAT-ARCH] also hints at potential issues with SNMP management
      via NAT.

    Alternately,  SNMP proxies, as defined in [SNMP-APPL], may be used in
      conjunction with NAT to forward SNMP messages to external SNMP
      engines (and vice versa).  SNMP proxies are tailored to the private
      domain context and can hence operate independent of the specific
      managed object types being accessed.  The proxy solution will require
      the external management application to be aware of the proxy
      forwarder and the individual nodes being managed will need to be
      configured to direct their SNMP traffic (notifications and requests)
      to the proxy forwarder.

    Also SNMP data isn't encrypted.