11-17-2021 03:06 PM - edited 11-18-2021 08:33 AM
Troubleshooting configuring SNMPv3 via API Explorer and CLI in FTD 6.7/ASA version 9.15(1)
Snmpv3 server and FTD can ping each other. Have verified more than once credentials and algorithms are all correct and match between the two hosts.
Anyone else get this set up to work ?
192.168.140.57 is the snmp server that is polling the agents ( Firepower 1120 FTD, Catalayst switches )
192.168.140.1 is the default gateway for the subnet/subinterface facing the snmp server.
Apparently, there exists a bug for these devices OS versions and a workaround is making a peculiar NAT rule. However,
after attempting this it is still not working. The other option is to downgrade the LINA engine to 9.13.10 which I will not do
because of risking vulnerability exploits not accounted for by that LINA engine version.
1: 20:45:43.776952 802.1Q vlan#140 P0 192.168.140.57.48976 > 192.168.140.1.161: udp 61
2: 20:45:43.777303 802.1Q vlan#140 P0 192.168.140.1 > 192.168.140.57 icmp: 169.254.1.3 udp port 4161 unreachable
3: 20:45:46.778142 802.1Q vlan#140 P0 192.168.140.57.48976 > 192.168.140.1.161: udp 61
4: 20:45:46.778447 802.1Q vlan#140 P0 192.168.140.1 > 192.168.140.57 icmp: 169.254.1.3 udp port 4161 unreachable
This line shows the abnormal behavior on the xlate:
firepower# sh xlate | in 192.168.140.57
UDP PAT from rack_servers:192.168.140.57 162-162 to nlp_int_tap:192.168.140.57 162-162
06-14-2022 12:33 PM
What encryption are you using? I found a bug with newer code where AES 256 would not work for the Priv, I believe when used with a non-split tunnel (tunneling all traffic), though it might have been with any IPSec tunnel enabled.
The posted work around was to use AES 128, so SHA and AES 128 combo worked after making that change. Hope this helps.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide