I recently deployed an ASA 5505 and after powering this unit up, things seemed to be fine. After a few hours, all internal connections out to the Internet stopped. I have not been able to find the cause of this, but when this happens, I try pinging any internal computers from the ASA inside interface,I get time outs. After reloading the ASA the connections out to the Internet start working again. This seems like a random issue as the inside interface stops responding at various different times. We do run 10 plus individual Cisco VPN client connections out through this device, so maybe the problem lies there?
when the conenctions stopped,were you able to log into the unit.?
were you able to ping internet ip's.?
is there ip address within your internal network which might have same ip address as the firewall's inside interface?
did you collect logs during the time connections stopped.
everything has a reason and we need data to find that,not speculations.
if you have n't got a syslogs server ,then setup one so that if this happens again,you have necessary logs.
ten vpn clients cannot create that much on connections which could stop other clients/hosts to create more connections.
Here are the steps for setting up the syslog server.
First you would need to install a syslog server software on one of the computers. You may
download one of the popular kiwisyslog server from
http://www.kiwisyslog.com/software_downloads.htm . It is listed as Kiwi
Syslog Daemon and latest version is 7.1.0. You may download standard edition that runs as
Once the syslog server is installed you will then need to login into the PIX in
configuration terminal mode and enter the following commands.
logging host [in_if_name] ip_address
(example: logging host inside 18.104.22.168
We are assuming syslog server is installed on computer with IP address 22.214.171.124 in the
logging trap 4
These commands will enable the PIX to start sending syslog messages to the syslog server.
For more information on logging commands you may refer to this URL:
.0-emergencies-System unusable messages
.1-alerts-Take immediate action
.5-notifications-Normal but significant condition
.7-debugging-Debug messages and log FTP commands and WWW URLs
these steps are applicable to asa too.
Thank you for this information. The inside interface is the only interface affected. This device is in one of our remote locations. I am able to open an ASDM session to the firewall when the inside interface goes down to reload the ASA.
well,in that case you can certainly put a syslog server on dmz/outside.by that when then inside interface goes down,still we'll have the corresponding logs.
ok..run the command debug icmp trace and try this :-
1)ping the inside interface of the FW from any inside Machine...see if you get the request on it
2)From the FW itself ping ts own inside interface, if you dont get reply..its a bad hardware
Did you ever find out what was wrong? I have a similar problem on my outside interface. I'm collecting logs but nothing was revealed in them that would explain it.
No I did not. I suspected this was an ISP issue as we did not have any problems for months after. I am not at that particular company anymore, so I don't know if it ever happened again...
The issue I'm having on my outside interface of my asa5505 is not related to the ASA it seems. It is located in a remote site and I have contacted the ISP who manages an Cisco 1841 router that the ASA is connected to via cross over cable. They asked us to replace the cross over cable because the router was presenting CRC errors and that is the first line of defense. That didn't do it so I asked them to set the interface to auto from full/100 and so far we haven't had an outage, but the day is young.
We are also experiencing timeouts issue when we ping the inside interface of the ASA5505 from any of the machines in the LAN. Most of the time, we can't ping the inside at all!
Did you manage to find a solution to the problem? Could it be the code? I can ping the inside interface from the firewall.
In my case the behavior was the same as you discribe. Nothing appeared in the logs and I was stumped and thought for sure the issue was the ASA 5505.
However, I contacted the ISP who managed the router, and the indicated that the inside interface of the router was showing many CRC errors.
I asked them to configure their interface to auto/auto instead of trying to force 100/full and all was fine after that. The other choice would have been to configure my firewall to 100/full using the info from this link:
After the ISP set the 1841 router to auto/auto no more CRC errors and we haven't gone down again.
Good luck hope this helps.
Thanks for your reply.
I already tried manually setting the speed and duplex of the interfaces to auto even though by default they are set auto-negotiate.
We only have 1841 before where the inside interface has 10.0.0.1/24. So when we added ASA5505 and configured the inside interface to 10.0.0.1/24, it is possible that the 10.0.0.1 are somewhere on the cache. Changed the inside interface IP to 10.0.0.253 and the timeouts are gone but Internet is only up to outside interface.
What license are you running on your ASA 5505? The Base license only allows 10 hosts on the inside network through the firewall. I recently had a similar problem that we didn't figure out until running packet-tracer. It showed packets were being dropped at the last step due to the host limit being reached.
It's a Security Plus license. Here's the product # and description:
ASA 5505 Sec Plus Appliance with SW, UL Users, HA, DES
K8 was upgrade K9.
The issue that we are facing with ASA5505 is resolved. We found out through the "show arp" command that hosts from the inside (LAN) are appearing in the outside interface (which should not be). The way it's connected is that the inside interface of the router, the outside interface of the ASA5505 and few servers are connected to the same Catalyst 3750 switch. So it's possible that the servers are leaking to the outside interface.
After directly connecting the inside of the router to the outside of the ASA5505 and clearing the arp, it started to work.
Thanks for all your help.