Ad Widget

Collapse

Netw. discovery: two likewise snmpv3 checks for the same oid, snmpv3-AES alway fails

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • b52
    Junior Member
    • Nov 2019
    • 15

    #1

    Netw. discovery: two likewise snmpv3 checks for the same oid, snmpv3-AES alway fails

    Hi all,

    We use 4.0.14 on server and proxies. The network discovery is made by a proxy in active mode. I discovered the following behaviour and would like to know if anyone can confirm this:

    I had one network discovery job with several checks for the same oid "SNMPv2-MIB::sysObjectID.0". Because we discover different hardware devices, I had snmpv2 checks for this oid and two snmpv3 checks for this oid. The snmpv3 checks where almost identical, same oid, both authpriv, same "Security name", same Credentials, except "Privacy protocol". It was DES on the first check (some devices only support DES) and AES on the second. The snmpv3-DES check worked, but the snmpv3-AES check always failed with "NETWORK_ERROR" "Timeout while connecting to...". Thus I checked network connection (worked) and snmp credentials (where correct). I checked again, and again, restarted server, restarted proxy, but I never got it working...

    Till I split up both snmpv3 checks in two different network discoveries. Then they worked! The snmpv3-DES check discovered all the DES-devices and the snmpv3-AES check discovered all the AES-devices and both returned the value of "SNMPv2-MIB::sysObjectID.0"

    If I put them again together in one network discovery, only the snmpv3-DES check works.

    The discovery options where:
    Code:
    Discovered by Proxy
    IP Range: single IP
    Update Interval 5m
    Check 1:
    Check type: SNMPv3 agent
    Port range: 161
    SNMP OID: SNMPv2-MIB::sysObjectID.0
    Context name:
    Security name: User
    Security level: authPriv
    Authentication protocol: SHA
    Authentication passphrase: password1
    Privacy protocol: DES
    Privacy passphrase: password2
    Check 2:
    Check type: SNMPv3 agent
    Port range: 161
    SNMP OID: SNMPv2-MIB::sysObjectID.0
    Context name:
    Security name: User
    Security level: authPriv
    Authentication protocol: SHA
    Authentication passphrase: password1
    Privacy protocol: AES
    Privacy passphrase: password2
    Device uniqueness criteria: IP address
    Enabled
    Can anyone confirm this?

    Thanks!
    Last edited by b52; 07-11-2019, 20:34.
  • b52
    Junior Member
    • Nov 2019
    • 15

    #2
    Ok this seems to be worse than I thought...
    I did some traces and realized that the network discovery process on our proxy always sends SNMPv3 AES packets. I attached two traces and told wireshark to decrypt SNMPv3-Packets with our DES Keys. As you can see in the screenshots wireshark is not able to decrypt the packets. If I add our AES Keys to wireshark, it is able to decrypt both discoveries. Thus only AES is used!

    I configured it to try SNMPv3 with DES and then SNMPv3 with AES. If I look in the dchecks database table on our Proxy (other screenshot), it is correctly saved, AES+DES, as you can seen in the snmpv3_privprotocol field. But zabbix only uses AES.

    I tried already a lot to get this running, deleted the discoveries, recreated them, always the same result. The only way to workaround this bug, is to split the AES and DES discovery in two discoveries. But this has the drawback, that then both discoveries try SNMPv3-DES and SNMPv3-AES at the same time on the same host and It would double our network discoveries...

    Any Idea why zabbix should use AES twice while database says AES and DES?
    Attached Files

    Comment

    • b52
      Junior Member
      • Nov 2019
      • 15

      #3
      Ok I made a Bug report for that and it got confirmed: https://support.zabbix.com/browse/ZBX-16916

      Comment

      • b52
        Junior Member
        • Nov 2019
        • 15

        #4
        Since this Bug is linked to SNMP Caching, is there any way to disable SNMP Caching till this get's fixed?
        Thanks!

        Comment

        Working...