snmptrapd only working on "lo" and not in "eth0"

[PatxiAndueza]

I'm currently working on a Zabbix Server over an Oracle Linux 8 (Zabbix Cloud Image, with Zabbix 5.4).

I have the zabbix_trap_recivier.pl working properly... but only works on loopback interface!

If I do a "tcpdump port 162 -i lo" and send to "localhost" a trap (from the server), appears in tcpdump and in the "zabbix_traps.tmp".
If I do a "tcodump port 162 -i eth0" and send to "<server_ip> a trap (from a proxy), appears in tcpdump but not in the "zabbix_traps.tmp".



I'm going crazy with this problem, any help is appreciated.

[cyber]

I have the zabbix_trap_recivier.pl working properly... but only works on loopback interface!

Do you see a contradiction here..

[PatxiAndueza]

Do you see a contradiction here..

I should have said "working not so properly"

I meant that the packages that arrives from loopback are "translated" to Zabbix format and they are visible from the frontend while eth0 packages are not.

[cyber]

I have never dealt with traps in Zabbix but looking at all this, I have a feeling, that this receiver only listens on localhost. As I see, it requires snmptrapd, so I would look into the config of that one.. Even if man pages say "The default behaviour is to listen on UDP port 162 on all IPv4 interfaces.", you may have some issues there. On top of all, selinux stuff causes headaches time to time, so you can take a look there also.

[PatxiAndueza]

I have never dealt with traps in Zabbix but looking at all this, I have a feeling, that this receiver only listens on localhost. As I see, it requires snmptrapd, so I would look into the config of that one.. Even if man pages say "The default behaviour is to listen on UDP port 162 on all IPv4 interfaces.", you may have some issues there. On top of all, selinux stuff causes headaches time to time, so you can take a look there also.

I'm going to take a look at the things you comment. Thanks for the suggestions!

[tim.mooney]

In addition to the suggestions that cyber had (especially the SELinux suggestion), a couple other things you might want to look at:

1. in one case you're testing a version 2c SNMP protocol trap, in the other you were testing version 1. Perhaps use the same protocol version for both tests, to see if that has something to do with it. For that matter you're using different traps in your two tests. Perhaps try using the same trap, to see if that's part of the issue.
2. in addition to the "execute" statement you should have in your snmptrapd.conf , you may want to add "log" and restart snmptrapd, and then repeat your tests. This may provide a clue as to why there's a difference in behavior. You can remove the "log" action after you have the problem diagnosed and fixed, but it's probably useful during testing.

[Markku]

Also: if you are unsure which interfaces/addresses the daemon are listening on, use the command sudo ss -nulp (if present in Oracle Linux) to show all UDP addresses+ports that are listening, as well as the process names.

Markku