I am at a total loss. I have a problem with a Cisco ASA at my house and the same problem at a client’s office. Both sites are in Las Vegas, use COX business Internet, have multiple static IP addresses and use Cisco ASA devices. The only differences are my ASA is the 5505 and my client’s is a 5510. I have one IP assigned to the outside interface and the others are used for static NAT translations (servers) with the proper global and NAT statements. Everything gets configured and works just fine for several months, then without warning all static translations stop working (no Internet access) and the only one that does work is the one assigned to the outside interface, so the workstations can still get out.
If I remove the static translations forcing everything out the interface then the servers can hit the Internet, put them back to their statics and everything stops. The only fix I have found is to change the IP addresses in the statics. By change I mean, call COX get all new addresses and change the configuration of the ASA. For my client site they have an IP address that I never entered into the ASA, so I changed one of the statics to this unused IP and it started working. Basically, if the ASA ever had an address entered into it, take it out and put it back, makes no difference, but a fresh address that has never been added to the ASA does the trick. I really do not want to get a new set of addresses to fix the problem because I know that this will just come back again in six to nine months.
Additionally, this is the third time the problem has come up for my client and the first time for me. I have tried rebooting the modem, having the modem reprovisioned, rebooting the ASA, entering the config from scratch, clear local, and clear xlate. The other item of interest is that COX says they cannot see the ASA connected to the modem (not sure if that is part of the problem). COX wants to throw this back at me as an equipment problem, but I just do not understand how it can work for so long then stop and occur in two different locations. Any help or thoughts would be greatly appreciated.
This seriously sounds like an ISP issue. Many times we have seen cases where the ISP allocates same block to two different customers.
The ASA doesn't know the difference between the two blocks. It will continue to translate as the static instructs it. The only difference is traffic may be leaving your ASA destined to the internet but the response traffic may never come back. I can almost guarnatee it.
You need to capture when the old addresses fail to work on the ASA's outside interface and prove to the ISP that they are not routing the response traffic back to your ASA. That is the reason new IP block works because the ISP routes it back to your ASA.
This sounds exactly as the problem I'm having. I know for the fact that
my isp is mapping static ip's provided to me with mac address. So what happens is only outside interface of my asa, which has address assigned to it is mapped correctly with mac address on ISP side. No NAT's are working and for that reason I can not open various services on my servers to outside. I've been searching for a solution for a week now and ISP is not hellpimng at all.
I was wondering if you ever figured out your problem and if it's similar to what I explained here. Any help is very much appreciated.
After I changed all of the IP addresses to a new set, I allowed ICMP through the firewall to all hosts and the problem has not returned. I'm not sure if the problem will return or allowing ICMP fixed it. Good luck.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...