[ZBX-16916] SNMPv3 Network discovery confuses AES and DES privacy settings Created: 2019 Nov 14  Updated: 2023 Jan 05  Resolved: 2023 Jan 05

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P)
Affects Version/s: 4.0.14
Fix Version/s: None

Type: Problem report Priority: Trivial
Reporter: H.L. Assignee: Artjoms Rimdjonoks
Resolution: Unsupported version Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

zabbix-agent 4.0.14-1.el7 @centos7-base-x86_64
zabbix-proxy-mysql 4.0.14-1.el7 @centos7-base-x86_64
mariadb-server 1:5.5.64-1.el7 @base

Attachments: JPEG File FIRST_SNMP.jpg     JPEG File SECOND_SNMP.jpg     PNG File zabbix_snmpv3_AES_decryption.png     PNG File zabbix_snmpv3_AES_discovery.png     PNG File zabbix_snmpv3_DES_decryption.png     PNG File zabbix_snmpv3_DES_discovery.png     PNG File zabbix_snmpv3_Proxy_DB_drules.png    
Issue Links:
Duplicate
duplicates ZBXNEXT-3940 Provide a way to flush SNMP cache for... Closed

 Description   

Steps to reproduce:

  1. Create a network discovery from a proxy including two SNMPv3 checks with the same credentials, checking oid "SNMPv2-MIB::sysObjectID.0". One check with SHA1+AES, the other with SHA1+DES. See Screenshots
  2. Let it run

Result:

  1. SNMPv3 SHA1+AES Devices will be discovered, SNMPv3 SHA1+DES Devices will be never discovered.

Expected:

  1. SNMPv3 SHA1+AES Devices and SNMPv3 SHA1+DES Devices should be discovered

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 these 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 another drawback: Then both discoveries try SNMPv3-DES and SNMPv3-AES at the same time on the same host and It would double our network discoveries...

 Comments   
Comment by Edgar Akhmetshin [ 2019 Nov 15 ]

Hello,

Thank you for reporting the issue! Confirming, because Zabbix uses caching for the SNMPv3 credentials and looks like it has impact in case of two type used whiting one discovery rule. Also i'm able to reproduce with SNMPv3 on alpine linux test box (DES) and Synology DS118 (AES) at the same network.

Regards,
Edgar

Comment by H.L. [ 2019 Nov 15 ]

Thanks for confirming Edgar! This issue made me a lot of headaches and cost me a lot of hours. It felt totally weird, some discoveries discover one sort of devices (DES), some other discoveries discover that sort of devices (AES), after delete and recreation a discovery startet to discover the other kind of devices... Totally confusing and made no sense at all.
Is there anything I can change to work around this Bug? As I wrote, to split up the discoveries is not a good deal for us..
Best regards,
Holger

Comment by H.L. [ 2019 Nov 19 ]

Is there any way to deactivate snmp caching till this gets fixed?
Thanky you,
Holger

Comment by H.L. [ 2020 Aug 18 ]

Hi there! As I wrote I split up our discoveries as workaround for this Bug. But now it seems I have too many discoveries running. At least the 11th discovery never starts and I have no clue why. Have a look in https://support.zabbix.com/browse/ZBX-18256

Is this Bug fixed in Version 5.0.2? Then I could merge these discoveries again.

Comment by Michael Veksler [ 2021 Oct 28 ]

SNMP cache reset has been implemented in ZBXNEXT-3940

Comment by H.L. [ 2021 Oct 28 ]

Hi Michael

Thank you for pointing me there. I already tried snmp cache reload some time ago. Unfortunately a snmp cache reload will not fix this issue. One network discovery process will either discover SNMPv3 DES devices or AES devices, not both. With snmp cache reload I may be able to "switch" the discovery process from one encryption type to the other, but still not both. Thus doubling up the discoveries per snmp encryption protocol is the only workaround for this bug, yet.

Thanks, Holger

Comment by Artjoms Rimdjonoks [ 2022 Jan 04 ]

h.l. Hello, Zabbix 4.0 is not longer fully supported. Could you please re-confirm if you experience this issue on one of the newer versions of Zabbix.
From what I observed - it is actually not possible in front-end (in latest Zabbix versions) to create a single Network Discovery rule with:
1) 2 network discovery checks
2) with the same OID
3) and same passphrases
4) and without contexts
5) that would be different only by Privacy Protocol (AES/DES)

If I circumvent this limitation with 2 different contexts - I still managed to discover both AES and DES snmp servers. (I tested with having snmp configured with DES user on host machine and AES user in VirtualBox) - both were discovered.

Generated at Wed Jul 09 11:16:38 EEST 2025 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.