0

Background

I am running the following

  • On my laptop the very latest version of arch linux with all the latest updates. It is from this laptop that I am querying an SNMP stack on a rasp pi

    $ uname -a Linux 4.20.13-arch1-1-ARCH #1 SMP PREEMPT Wed Feb 27 19:10:28 UTC 2019 x86_64 GNU/Linux

  • On a raspberry pi I am running raspian with all the latest updates.

    $ uname -a Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux

  • On the raspberry pi I am running an SNMP stack with configuration as follows

    • $ sudo apt-get install -y snmp snmpd

      $ snmpd -v

      NET-SNMP version: 5.7.3

    • The /etc/snmp/snmp.conf file is empty

    • The /etc/snmp/snmpd.conf file contents are pasted below

Issue Description

I am unable to get the snmpstatus command to work from the WAN ie while away and accessing the LAN remotely from across the internet. The command that won't work from the WAN side but will work from the LAN side is

snmpstatus -v1 -c public my_dydns.org:1234 (as a result of this command nothing is displayed).

From the LAN side of the router the same command works as expected snmpstatus -v1 -c public my_dydns.org:1234 gives the following correct output: [UDP: [94.94.94.94]:1234->[0.0.0.0]:40866]=>[Linux raspberrypi 4.14.98-v7+ #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l] Up: 15:33:34.58

I have set-up my home router so that the external WAN facing port 1234 port, port forwards to 192.168.1.30 port 161 which is the SNMP stack on the rasp pi.

I know that my dydns and port forwarding work well becasue the same snmpstatus command used to get the SNMP status of a printer on the same LAN, accessed from the WAN, using a similar port forwarding regieme works just fine.

Below is my snmpd.conf file as use on the rasp pi.
The snmp.conf file exists and is empty.

Contents of /etc/snmp/snmpd.conf pasted below

agentAddress udp:161,udp6:[::1]:161

# below allows any ip in the range 192.168.1.0 to 192.168.1.254 access to this SNMP, including the router at 192.168.1.1

rocommunity public 192.168.1.0/24

# allows port forwarding through the router from the WAN (ie the outside side of the router)

rocommunity public me.my_dydns.org

  • Is that 1234 TCP or UDP? – Rui F Ribeiro Mar 5 '19 at 15:26
  • On the port forwarding both. Should I change to UDP only? – Kes Mar 5 '19 at 15:27
  • Both work, the issue is another I think....will update the answer. – Rui F Ribeiro Mar 5 '19 at 15:29
1

That IP address on the SNMP file is wrong. However, it is already included in 192.168.0/24, as the remark correctly mentions "including the router". e.g. you can comment out the line rocommunity public me.my_dydns.org

Nevertheless, it is not recommended to have SNMP services presented on Internet exposed interfaces for security reasons. Much less SNMP with v1/v2 authentication, where authentication is not encrypted.

I would advise setting up a VPN for talking SNMP over a VPN.

However, as far as I remember, some protocols are not NAT friendly, and SNMP is not one of the most NAT friendly. e.g. SNMP does not work well over NAT. It might or not work, and in this case, probably not.

I would advise setting up a VPN for talking SNMP over the Internet.

As an example with Cisco equipment:

Network Address Translation > NAT Issues

Table 4-1 IP Traffic Types/Applications Supported by Cisco NAT
Traffic Types/Applications Not Supported SNMP

PS. In enterprise equipment they have inspectors/specialized agent that rewrite SNMP packets for it to work over NAT.

| improve this answer | |
  • Thanks @rui-f-ribeiro. SNMP port 161 is not blocked by the ISP as I can access a different SNMP device - a printer - from the WAN that is on the same LAN. So that is not the problem. – Kes Mar 5 '19 at 15:21
  • 1
    Jetdirects never implemented things right, but it is an off-remark. What I am trying to say, is that is a known problem - I searched expressly for vaguely remembering it either, did not stumble on it either. – Rui F Ribeiro Mar 5 '19 at 15:35
  • 1
    I always used VPNs/did it on internal networks. UDP is not supposed to be used over WAN, I guess vendors do not worry much about implementing it. – Rui F Ribeiro Mar 5 '19 at 15:37
  • 1
    Router for itself is not doing NAT. Dinner time here! – Rui F Ribeiro Mar 5 '19 at 15:38
  • 1
    HP might just have a sloppy implementation that does not care about which values it is fed...it does not mean much. Try to use snmpdump to debug what arrives at the SNMP side from the internet. – Rui F Ribeiro Mar 6 '19 at 12:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.