I'm trying to set up SNMP for a router so I can monitor it from an existing Nagios installation on an off-site server. I'm having trouble getting the router to respond to SNMP requests from the WAN, despite trying a few different iptables rules. The router is a new ASUS RT-AC66U, running AsusWRT (Merlin build).

I was very recently and unfortunately forced to switch to Comcast as an ISP, and they say that they block port 161 and 162 across the network. In light of that, I'm trying to redirect 1610 to 161. I currently have port forwarding set up for my NAS, 1611->161, and SNMP works just fine there.

The first thing I tried was setting up a port forwarding rule from 1610-> (UDP), which didn't seem to work:

[ssube@centos-server ~]$ snmpwalk -v 2c -c [name] [ip]:1610
Timeout: No Response from [ip]:1610

[ssube@centos-server ~]$ snmpwalk -v 2c -c [name] [ip]:1611
SNMPv2-MIB::sysDescr.0 = STRING: Linux Triton #2668 Tue Dec 11 12:36:30 CST 2012 armv5tel
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

The NAS rule is working just fine, as you can see above. Removing the NAS rule and replacing 1610 with 1611 in all the router rules didn't seem to help. The error message (no response) has been consistent regardless of what I try.

My second attempt was to go through iptables itself. I set up the following rules:

boss@RT-AC66U:/jffs/scripts# cat firewall-start

iptables -I INPUT 1 -p udp --dport 1610 -j ACCEPT
boss@RT-AC66U:/jffs/scripts# cat nat-start

iptables -t nat -A PREROUTING -p udp --dport 1610 -j REDIRECT --to-port 161

From within the LAN, I can see the router just fine:

ssube@KRAKEN /c/Program Files/ConEmu > snmpwalk -v 2c -c [name]
SNMPv2-MIB::sysDescr.0 = STRING: Linux RT-AC66U #1 Sun Mar 17 17:16:27 EDT 2013 mips
SNMPv2-MIB::sysObjectID.0 = OID: NET-SNMP-MIB::netSnmpAgentOIDs.10

However, I still can't see it from outside of the LAN, with or without the INPUT chain rule. Both rules appear in iptables:

boss@RT-AC66U:/tmp/home/root# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere            udp dpt:1610

(listed before any DROP rules, after a few unrelated ACCEPTs)

boss@RT-AC66U:/jffs/scripts# iptables -t nat -L
target     prot opt source               destination
VSERVER    all  --  anywhere             [ip].comcast.net
REDIRECT   udp  --  anywhere             anywhere            udp dpt:1610 redir ports 161

Still, no luck on external SNMP. I've tried tcpdump to see if the packets are making it in at all, but running tcpdump on the router seems to kick me off wifi within a few seconds, and I haven't had a chance to plug into the router and run it there yet (will edit with updates when I do).

The scripts seem to be working, since the rules appear. I suspect the issue is with the rules, but am having a hard time pinning it down, and have yet to get a response on the firmware message board.


1 Answer 1


Seems like you're just trying to do a straight port forward of [WAN IP]:1610 to [LAN IP]:161. These 3 rules should accomplish this:

# forwards port 1610 -> 611
$ iptables -t nat -A PREROUTING -p tcp -d [LAN IP] --dport 1610 -j DNAT --to [LAN IP]:611

NOTE: [LAN IP] would be your internal server's IP address.

# Allow 1610 traffic
iptables -A INPUT -i eth0 -p tcp --dport 1610 -m state --state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp --sport 1610 -m state --state ESTABLISHED -j ACCEPT
  • I believe I've tried that already, or something very similar. I'm using plain old port forwarding for the NAS successfully, now I want to do the equivalent on the router itself. I tried adding an equivalent forward rule, which didn't work, then moved on toward trying to open the port on the router's WAN interface. For clarity, I would (I think) like any packets coming in on [public ip]:1610 to come into the router on eth0 161. I'll make sure my initial attempt doesn't match your rules and try them if so.
    – ssube
    Jun 7, 2013 at 15:03
  • Take a look for some files in your /etc directory called hosts.allow and hosts.deny and see if there are any references to snmp in there. These files are part of TCPWrappers and it might be blocking access to the snmp daemon.
    – slm
    Jun 8, 2013 at 8:34
  • It doesn't look like hosts.allow or deny exists anywhere on the filesystem, certainly not directly in /etc.
    – ssube
    Jun 9, 2013 at 19:45
  • Can you please run netstat -anp|grep 161 so we can see what interfaces snmp is listening on on the WRT box.
    – slm
    Jun 9, 2013 at 20:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .