I guess they don't know how to fix. As of 9.14 snmpd runs under Linux as a separate NLP process (Non-Lina process) and connects to the outside world via internal nlp_int_tap interface. E.g. in 9.16.3:
ASA# show kernel ifconfig
tap_nlp Link encap:Ethernet HWaddr ba:1a:01:32:cc:cf
inet6 addr: fe80::b81a:1ff:fe32:cccf/64 Scope:Link
inet6 addr: fd00:0:0:1::2/64 Scope:Global
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1434 errors:0 dropped:0 overruns:0 frame:0
TX packets:1464 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101320 (98.9 KiB) TX bytes:109380 (106.8 KiB)
tap_nlp:1 Link encap:Ethernet HWaddr ba:1a:01:32:cc:cf
inet addr:xxx.254.1.2 Bcast:xxx.254.1.7 Mask:255.255.255.248
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
In order to reach the snmpd process running on xxx.254.1.2 static NAT rule is created by the system between the interface used in the snmp-server command and the nlp_int_tap interface. E.g. when inside interface is used:
ASA# snmp-server host inside x.2.3.4 comm public version$
ASA# show nat det
Manual NAT Policies Implicit (Section 0)
1 (nlp_int_tap) to (inside) source static nlp_server__snmp_x.2.3.4_intf2 interface destination static 0_x.2.3.4_18 0_x.2.3.4_18 service udp snmp snmp
translate_hits = 0, untranslate_hits = 0
Source - Origin: xxx.254.1.2/32, Translated: 10.44.17.74/29
Destination - Origin: x.2.3.4/32, Translated: x.2.3.4/32
Service - Protocol: udp Real: snmp Mapped: snmp
As of 9.16 this rule is placed into the system section 0. It's unclear how to make use of this rule if traffic comes over VPN via outside interface. I guess it won't be hit even if "management-access inside" is configured (you can check untranslate_hits). Hence traffic doesn't reach snmpd. Also, another identity twice NAT rule is typically configured to exempt VPN traffic from NAT. If this rule is hit (on the outside), lookup isn't made for the 2nd one (system SNMP rule).
It's interesting what TAC is saying...
