CSCvt97205 - SNMPPOLL/SNMPTRAP to remote end (site-to-site vpn) ASA interface fails on ASA 9.14.1

[tnelis@inlichtingenbureau.nl]

Hello,

This weekend I upgradet to version 9.14(2)8, coming from 9.13(1)10. After that the SNMP-requests faild. It seems to me the problem is not yet solved.

Greatings

Theo Nelis

[NathanGregory5253]

Hi. I have this exact same issue.  Upgraded to 9.14(2)8 and since then our SNMP Server cannot connect to the ASA to authenticate.

We are using a Site to Site VPN and the SNMP server is on the other side of the VPN.  This worked fine previously.  

The SNMP poll interface is set to the same as the Management Access Interface.

[kerstin-534]

Hi, problem not fixed in  9.14(2)13. Somebody knows when this is fixed ? 

[quocanhylvn]

I'm tried 9.14.(2)15, 9.14.(3), 9.16.1 but still no luck

[tanios191]

Hello,

Were you able to find a solution for this?

[Kortermann-IT ApS]

We are running 9.16.1, and have the same issue with PRTG where using SNMP to poll data over IPSec IKE1 and IKE2 VPN, which doesnt work. Anyting inside is working perfect.

Any news here?! **bleep** **bleep**......

[John Robinson IV]

Still working this issue, with no solution. Been on with support for months now.

[kerstin-534]

I decided to include outside IP Adress of firewalls in crypto maps and use the workaround. I'm not sure if Cisco is fixing this. I tested workaround in lab and will use this when migrate to 9.14. Nevertheless the workaround is a deep impact on the configration of firewall and monitoring software.

[tanios191]

Thank you Kerstin not a reliable solution knowing the risk of it especially if you dont have a public fix IP on your outside interface

Hope we will have a solution from Cisco with newer version

[Kortermann-IT ApS]

We are running 9.16.1, and have the same issue with PRTG where using SNMP to poll data over IPSec IKE1 and IKE2 VPN, which doesnt work. Anyting inside is working perfect.

Any news here?! **bleep** **bleep**..

[bg-tech]

Recently upgraded to 9.16.2 and this issues still persists.

Is Cisco really proposing that the solution is to push our SNMP traffic through the public internet 3 updates later?

Has there been any update on this and do Cisco plan to resolve this issue or is this "feature" here to stay?

[Gaston Sanchez]

Hi All !

it looks like is no resolved on 9.16(2)14 either (last recommended version as far as i know) anyone knows if this will be solved

[KieranBilling]

Just upgraded to 9.16(3) and still not resolved, interestingly the Bug CSCvt97205 is showing as fixed but it is definitely not.

[tnelis@inlichtingenbureau.nl]

The same thing on our environment, upgraded to 9.16(3), and still the problem is not solved.

[tvotna]

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:169.254.1.2 Bcast:169.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 169.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:

# snmp-server host inside 1.2.3.4 comm public version$
# show nat det
Manual NAT Policies Implicit (Section 0)
1 (nlp_int_tap) to (inside) source static nlp_server__snmp_1.2.3.4_intf2 interface destination static 0_1.2.3.4_18 0_1.2.3.4_18 service udp snmp snmp
translate_hits = 0, untranslate_hits = 0
Source - Origin: 169.254.1.2/32, Translated: 10.44.17.74/29
Destination - Origin: 1.2.3.4/32, Translated: 1.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...