Lost management access (SSH & HTTPS)

[TRENT WAITE]

I have lost management access to about 10 ASA5505s all within past few days. Of about 20 or so, half of them are unreachable via SSH or HTTPS. The firewalls are up and operational, including the VPNs to the central data center. I can ping them just fine on both internal and external interface.

Almost all the ASAs are running 9.1(2) with ASDM v7.1.3. Of those that are working, one common trait is that they have been rebooted more recently. Of those that I can not access, their uptime is around 200+ days. However I was able to access one that has 229 day uptime, and can not for one that is been up for less than 100. But mostly does kind of seem to be the uptime

As these are remote locations, no possibility to gain console access to investigate further. Only option is to request someone to power cycle. I would really like to hear other's thoughts on this, or if anyone else has experienced this problem. What was the cause, and better yet what was the resolution.

[Rishabh Seth]

Hi,

Recenlty seen similar issue, refer follwoing discussion link:

https://supportforums.cisco.com/discussion/12599446/cisco-asa-5510-reboot-necessary-every-week

Also you can contact TAC and get this issue rectified as the reboot might temporarily fix the issue but it might occur again.

Thanks,

R.Seth

[TRENT WAITE]

I think mine is caused by different issue entirely, and it may not necessarily be a bug. I took inventory of devices, and below is the software version and uptime. 

My theory now, (this doesnt exactly make sense to me) is that this problem is caused by too much SNMP monitoring. Only after I had setup two applications (OpenNMS and Observium) to do some polling that this problem arose. Now these used SNMP and ICMP only. However, OpenNMS did test to see if SSH or HTTPS was functional.

Could be that the testing opened up the connection, but never closed, or too many requests the Cisco device shut down the service. Again, there is no problem with SNMP, this is only trying to access the device itself via SSH or ASDM/HTTPS. Otherwise clients behind the firewall report no issues, their VPNs work perfectly. 

Without problem
Site 1	-v -9.1(2)	10days,4:43:17.00
Site 2	-v -9.1(2)	11days,15:45:36.00
Site 3	-v -9.1(2)8	5days,22:48:08.00
Site 4	-v -9.1(6)	120days,0:31:49.00
Site 5	-v -9.1(2)	64days,2:54:21.00
Site 6	-v -9.1(2)	21days,19:49:12.00
Site 7	-v -9.1(4)	301days,16:16:54.00
Site 8	-v -9.1(2)	2days,19:30:55.00
Problem devices:
Site 10	-v -9.1(1)4	20days,19:16:01.00
Site 11	-v -9.1(2)	4days,6:12:35.00
Site 12	-v -9.1(2)	421days,0:38:44.00
Site 13	-v -9.1(2)	223days,21:10:49.00
Site 14	-v -9.1(2)	190days,17:13:52.00
Site 15	-v -9.1(2)	175days,22:26:12.00
Site 16	-v -9.1(2)	59days,3:36:12.00
Site 17	-v -9.1(2)	75days,3:06:28.00
Site 18	-v -.0(1)	57days,19:32:33.00
Site 19	-v -9.1(2)	57days,19:00:22.00
Site 20	-v -9.0(1)	31days,23:13:29.00
Site 21	-v -9.1(2)	71days,22:13:49.00
Site 22	-v -9.1(1)4	70days,23:40:50.00