Ad Widget

Collapse

SNMP V2/V3 replles being rejected by OS Firewalld/UWE (Ubuntu 20.04/Rocky 9)

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Wolfsbane2k
    Member
    • Nov 2022
    • 48

    #1

    SNMP V2/V3 replles being rejected by OS Firewalld/UWE (Ubuntu 20.04/Rocky 9)


    Hi.

    Apols that this isn't directly zabbix related, but more an SNMP and OS Firewall problem, but at this moment in time i'm not sure where else to go, and there doesn't seem to be much out there around it.

    We're currently struggling to get a SNMP v2 working with a specific host because the SNMP replies are being rejected by the Zabbix host's firewall as it doesn't appear to be able to relate the two.
    What Source Src Port Destination Dest port
    snmpget zabbix-server A snmp agent 161
    snmp reply snmp agent B zabbix server A
    In "most" scenarios, B is 161 (as the source port and follows snmp v1 protocol) , but not in this case: this behaviour is allowed in both SNMP V2 and V3 and therefore should be expected.

    RFC 1157 - Simple Network Management Protocol (SNMP) (ietf.org) (SNMPv1) : 4.1 “If, as a result of this processing, a message is returned then the source transport address that the response message is sent from shall be identical to the destination transport address that the original request message was sent to”
    RFC 1901 - Introduction to Community-based SNMPv2 (ietf.org) (snmpv2): (3) The requirement in the Elements of Procedure in Section 4.1 of [9] that the "the source transport address that a response message is sent from shall be identical to the destination transport address that the original request message was sent to" is deleted, i.e., the source transport address of a response message can be any transport address belonging to the agent.

    However, because of the difference in ports, the OS's firewall (ufw on Ubuntu and firewalld on RHEL) are rejecting the reply. (wireshark shows ICMP packets indicating "Administratively rejected" going back to the snmp agent's host. )

    Disabling the firewall on either OS's allow the SNMP reply through without problems, but is not suitable to leave it in this manner.


    Has anyone worked out how to solve this "properly" without opening the FW to accept UDP sessions from that specific host across the full UDP port range? It appears to be a kernel problem as "conntrack -L" shows the requests as "UNREPLIED"

    In RHEL, firewalld seems to talk about "net-connection helpers" net filter helpers , but this doesn't seem to work (even though there is a helper in /usr/lib/firewalld/helpers/snmp.xml) and i've set AutomaticHelpers to "Yes" in the /etc/firewalld/firewalld.conf file and played various reload-reboot etc tunes.

    I've not gone that far in decoding the ufw install in Ubuntu 20.04.​

    It appears that nearly all of the products we're monitoring uses different ports so works without issue, but i can't change this one.... that's as typical, absolutely critical..

    Any help most appreciated.

    Ta

    Last edited by Wolfsbane2k; 12-09-2023, 17:36.
Working...