Showing results for 
Search instead for 
Did you mean: 

ASA 5525 block snmp but logs ntp

Flavio Vettori

    we have an ASA5525 9.2(2)4 active/active failover cluster in multcontext mode, with 4 active contexts (3 + admin).

Two of the three contexts seem to have no problems; the last context we configured shows several NMS reading problems.

The suffering context's configuration is very simple: two interfaces making inside surf the internet natting on outside's interface, no acl and everything else leaved at default setting.
We noticed many graphs "holes" and false-positive alarms on failover status checks.
Almost all the NMS reads are collected via snmp v2c, incoming from outside (I know, insicure) interface originating from public addresses.

Focusing on asa behaviour we discovered this situation: when holes occur, NMS faces timeout on snmp walk/read and asa logs the following message

%ASA-4-106023: Deny udp src outside:pub_nms_addr/37228 dst inside:random_private_addr/123 by access-group "outside_access_in" [0x0, 0x0]

going there (on the asa) and clearing xlates/connection regarding all udp port 123 does the magic, recovering snmp readability from trusted sources.


Thank you,

2 Replies 2

Vibhor Amrodia
Cisco Employee
Cisco Employee


The logs that you have pointed on this issue is due to the traffic being dropped on the ASA device due to ACL denying the traffic.

Clearing the xlate for 123 suggests that it might be running out of ports for creating the xlate probably.

Can you check for the xlate for this server at the time it is not working and collect all the related logs for this IP.

Thanks and Regards,

Vibhor Amrodia

Hi, thank you Vibhor for replying.

Here's what happened few moments ago:

- problem's out solid since hours so NMS reports SNMP reading timeout
- from console:

hostname/act/context-name# show conn address NMS-PUB-IP
7009 in use, 10139 most used

hostname/act/context-name# sho xlate global NMS-PUB-IP
7128 in use, 9604 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net


so it looks like no conns nor xlates are on (I mean for NMS address).

I go have a quite random check on conns/xlates, as what I'm trying to do is management access, not production conns:

hostname/act/context-name# show xlate gport 161-162
6912 in use, 9604 most used
Flags: D - DNS, e - extended, I - identity, i - dynamic, r - portmap,
       s - static, T - twice, N - net-to-net

UDP PAT from inside: to flags ri idle 0:01:46 timeout 0:00:30
UDP PAT from inside: to flags ri idle 0:20:09 timeout 0:00:30

what? Why??? My nat configuration is solely:

nat (inside,outside) source dynamic GRP-NET-TO_MASQ interface

so why I see that kind of xlate??? I would expect no outbound xlate using snmp port, specially natting ntp traffic.
Anyway getting ahead I tried clearing something looking for what where blocking my snmp from outside, logging this:

Jun 17 2015    16:02:03    106023    NMS_HOST-PUB-ADDR    44321    123    Deny udp src outside:NMS_HOST-PUB-ADDR/44321 dst inside: by access-group "outside_access_in" [0x0, 0x0]

so I tried:

hostname/act/context-name#             clear xlate gport 123
INFO: 1 xlate deleted

snmp from NMS still doesn't work..

hostname/act/context-name# clear conn port 123 protocol udp all
116 connection(s) deleted.

snmp from NMS still doesn't work...

at the end focused on private ip address mentioned in deny logs, so:

hostname/act/context-name# show conn address
7225 in use, 10139 most used

UDP outside inside, idle 0:00:54, bytes 96, flags -

hostname/act/context-name# clear conn address all
1 connection(s) deleted.

--->>SNMP reads now works as expected. This sounds to me like a bug.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers