I am working on API that reads a lot of data via SNMP (routes, interfaces, QoS policies, etc...). Lately, I have experienced a random error stating:

Operation not permitted

Now, I use SNMP4J as core library and cannot really pinpoint the source of error. Some Stackoverflow questions have suggested OS being unable to open sufficient number of file handles but increasing that parameter did not help much.

The strange thing is that error occurs only when iptables is up and running.

Could it be that firewall is blocking some traffic? I have tried writing JUnit test that mimicked application's logic but no errors were fired...

Any help would be appreciated! Thanks!


:OUTPUT ACCEPT [68:4218]
# route redirect za SNMP Trap i syslog
-A PREROUTING -i eth0 -p udp -m udp --dport 514 -j REDIRECT --to-ports 33514 
-A PREROUTING -i eth0 -p udp -m udp --dport 162 -j REDIRECT --to-ports 33162


-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT


-A INPUT -p udp -m state --state NEW -m udp --dport 161 -j ACCEPT 

# SNMP trap
-A INPUT -p udp -m state --state NEW -m udp --dport 162 -j ACCEPT 
-A INPUT -p udp -m state --state NEW -m udp --dport 33162 -j ACCEPT 


-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
  • Well, firewalls can block traffic. Without any information about whats actually in your iptables rule set, it's hard to be more specific. – devicenull Mar 24 '14 at 4:12
  • Thank you for answering, I have updated the question with my iptables. Due to the fact that our iptables contains a lot of rules I have posted only those relevant to the SNMP. I hope you understand :) – Jovan Perovic Mar 24 '14 at 9:59
  • Are you overflowing iptables state tracking? If you remove -m state --state NEW, do you still have issues? State tracking largely doesn't make sense for UDP, since it doesn't have any sort of idea of what a connection is. – devicenull Mar 24 '14 at 12:43
  • Thanks I will try that. It sure sounds like it could be the solution... – Jovan Perovic Mar 24 '14 at 13:26
  • This other question and answer on SO seems related: stackoverflow.com/a/10726454/1098590 – Tonin Mar 25 '14 at 10:10

Your question isn't 100% clear but I assume your Operation not permitted error comes from inside your SNMP library on your client and means a rejection from the target host. Please clarify if you know different.

You are accepting SNMP connections from outside so the state module isn't helping. Normally it is used drop incoming packets where there was no outgoing connection. This doesn't apply so you probably want to turn state off. use the CT --notrack option (see man iptables-extensions). Having done that you will want to put rules in both directions.

-I INPUT -p udp -m udp --dport 161 -j ACCEPT
-I OUTPUT -p udp -m udp --sport 161 -j ACCEPT #only needed if you have some output blocked

This may well solve your problem.

If you want to troubleshoot then there are a number of reasons possible for iptables blocking connections which it seems the rules should permit. For example:

  1. the state has timed out
  2. the state doesn't fit into the state table

Since you only seem to be using UDP connections there is no real state. This means that packets coming from your client system should be accepted by your rules even if this is a "new" connection.

For sure you want to know where your iptables is dropping packets. Use

sudo iptables --list  --verbose

to look at which rules get packets. To get a clearer view you may use

sudo iptables --zero

to clear the counters and then check to see if one particular line goes up just after an error. You can then add logging rules (see e.g. https://wiki.archlinux.org/index.php/iptables#Logging) and see exactly which packet is dropped where.

At that point you can also look in your system logs and you should find some explanation.

| | |

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