cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements

Welcome to Cisco Firewalls Community


190
Views
0
Helpful
3
Replies
Cisco Employee

ASA5525 stopped responsive and was not accessible via ASDM, although it was accessible via SSH. And the issue was resolved after reloading the ASA.

ASA5525 stopped responsive and was not accessible via ASDM, although it was accessible via SSH. And the issue was resolved after reloading the ASA. 

We noticed after reload there are numerous  ‘FSCK0001.REC’, ‘FSCK0002.REC’ files etc on the flashcard of the firewall. 

 

Cisco Adaptive Security Appliance Software Version 9.10(1)
Firepower Extensible Operating System Version 2.4(1.103)
Device Manager Version 7.12(1)

Everyone's tags (1)
3 REPLIES 3
VIP Advocate

Re: ASA5525 stopped responsive and was not accessible via ASDM, although it was accessible via SSH. And the issue was resolved after reloading the ASA.

If you are looking to find out the root cause of this, I would suggest creating a case with Cisco TAC.  They have tools that analyze logs and crash files much better than what we can.

--
Please remember to rate and select a correct answer
Beginner

Re: ASA5525 stopped responsive and was not accessible via ASDM, although it was accessible via SSH. And the issue was resolved after reloading the ASA.

I've got the same issue.  Randomly a few times a month the ASA will quit passing traffic, I cannot connect with ASDM but I can telnet to issue the reload command.  Once the ASA reboots it operates as expected.  I just opened a TAC case, waiting to hear back from them.

Highlighted
VIP Advocate

Re: ASA5525 stopped responsive and was not accessible via ASDM, although it was accessible via SSH. And the issue was resolved after reloading the ASA.

You might want to check the connections table (show conn).  Try to filter on a specific address as this table will be quite long.  I have seen that sometimes if connection through the ASA is lost and then re-established a short time later there will be stale connections in the connections table (or more accuratly incorrect entries).  We use dynamic routing so when that route goes down the default route is used and an entry in the connection table is established to the outside interface instead of a DMZ interface.  However, once the dynamic route is back in place the connection table does not update automatically so it still sends traffic destined for the DMZ to the outside interface.  A clear conn all or clear conn specific IP solves the issue for us.  I have had a few TAC cases on this but it has yet not been classified as a bug as far as I know.

--
Please remember to rate and select a correct answer