Alterado o vNIC convidado para VMXNet3, não pode fazer SNMP contra dispositivos Cisco ASA

Tem um arranhador de cabeça aqui. Ou encontrei um bug do Windows e/ou VMware, ou perdi algo estupendamente simples. [Spoiler - foi estupendamente simples.]

Nosso ambiente VMware é ESXI 5.5. Temos uma VM Windows 2012 R2 (chamada BOS-NETMON) que não pode mais fazer consultas SNMP de dispositivos Cisco ASA (v2 ou v3).

Esta máquina executa o SolarWinds Orion, e nem isso nem ferramentas independentes como o Paessler SNMPTEST funcionam. Todos os outros dispositivos atualmente monitorados continuam a responder ao SNMP deste convidado - temos Cisco IOS, Meraki, Exagrid, APC/Schneider - tudo bem. Todos os outros protocolos permitidos (SSH, HTTPS, ICMP) funcionam ao conectar-se aos ASAs deste convidado.

O problema começou quando trocamos o convidado do hardware E1000e vNIC para o VMXNet3. Antes disso, funcionou bem por alguns anos.

• Executando a janela ASDM Logging, ela nem mesmo vê a tentativa de conexão SNMP do BOS-NETMON. EDIT - Isso ocorreu porque eu não tinha as configurações de registro corretas no ASA.
• Executando o Wireshark no BOS-NETMON, ele mostra as consultas SNMP saindo, não registra as respostas dos ASAs.
  • Eu testei o SNMP de outro convidado VMXNet3, ele também falha ao consultar o SNMP em um ASA, mas funciona em dispositivos Cisco não ASA. EDIT - isso não parece ser verdade. Ou eu testei errado, ou começou a funcionar recentemente. De qualquer forma, outro host com uma NIC VMXNet3 pode consultar o SNMP em relação a um desses ASAs.
• Testei o SNMP de um convidado com o E1000e vNIC e ele consulta com êxito o SNMP em um ASA.
• 4/5 dos ASAs de destino não estão no mesmo local, portanto, não deve ser um problema de ARP - e, se fosse, os outros protocolos não SNMP seriam afetados.

Edição adicional: tenho informações de depuração ASDM para uma sessão SNMP bem-sucedida e malsucedida. O próximo passo será uma captura de pacotes, eu acho.

6   Mar 12 2018 16:30:26    302015  10.50.100.177   63809   10.10.99.10 161 Built inbound UDP connection 610885144 for Inside_Interface:10.50.100.177/63809 (10.50.100.177/63809) to identity:10.10.99.10/161 (10.10.99.10/161)

7   Mar 12 2018 16:30:26    710005  10.50.100.152   49588   10.10.99.10 161 UDP request discarded from 10.50.100.152/49588 to Inside_Interface:10.10.99.10/161