• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 652
  • Last Modified:


Hi all

I have two Cisco 2921 routers both connected to the outside interface of an ASA 5520. Each router is connected to a ISP ISP A  & ISP B, all the web servers from  ISP A will have their  IP addresses migrated to those belonging to ISP B

The web servers are located on the DMZ of the ASA . Is it possible to NAT incoming (internet initiated)  source traffic to say an overload PAT address in order to be able to control which router(and which ISP) the outgoing internet traffic will go out on

I hope that makes sense :)

Thanks in advance
  • 2
  • 2
1 Solution
From what I can see, yes this is very possible*(I'll explain asterisk in a bit); if I'm understanding it right.  Correct me if I'm wrong, but it looks like the following is what you have:

Clients ISP A  ---> Router ISP A  ----|
                                                           ----> ASA ----> Server
Clients ISP B ----> Router ISP B ------|

And you already NAT traffic going to the server at the ASA? to the server.  Since you are migrating ISPs, you will have two IPs for the internal server.  Here's one of the asterisk points.  You can't do normal NAT with both ISP public IPs to the server on the ASA.  So you'd need to do Policy NAT in order for it to work.  The reason is that the ASA needs to know how to translate return traffic.  If there are 2 possible IPs, which does it use.  So you will need 2 ACLs and 2 NAT entries.  One ACL we will use for the ISP A since you're migrating from that.  Just say source of server and destination of ISP A IP* (I'll get to this one in just a moment as well).  Then you create a static NAT entry specifying the public IP for ISP A with that access list.  Then you create another ACL for ISP B that say to deny to ISP A IP and then accept everything else.  Apply that to a static NAT entry as well but with the ISP B address.  

Next you setup the overload NAT'ing for clients coming into your network.  This is where I explain the second asterisk.  When clients come in via ISP A, I would have that router perform an outside NAT overload on all traffic coming in.  The same for ISP B router.  This can be a RFC1918 IP address that is not even used anywhere else.  Say, you use on ISPA for nat'ing and for ISPB.  Then you just add static routes on the ASA.  Then when you create those ACLs for policy NAT on the ASA you use the IPs you assigned for NAT'ing here.  Also, incase you were wondering, on ISP B you do a deny and then accept all so that when the server itself needs to go out it has the ISP B IP to NAT to.  If you don't want that then you specify the ISP B address only.  The server would then use some other translation rule to get out for its own traffic.

Clients coming in get outside PAT at router
ASA policy NATs the server to a public IP.
s1mwatAuthor Commented:
Thanks for such an excellent answer cyclops, I need to get my head around a couple of things, will your solution work if one of my web servers was in the midst of a DNS change i.e. the public IP address of the web server that is associated to a URL is in the process to change from an ISP A address to a ISP B address. if we say the web server has a url of "webaddress.com" has a ISP A public address of a.a.a.a and the migrated ISP B address is b.b.b.b, it may take a little while for the migrated address to cover the whole of the internet will mean that some parts of the internet web address.com would resolve to the new address of b.b.b.b whilst other parts of the internet would still resolve to the original address of a.a.a.a.

So both ISP's address for web server.com could be in use simultaneously, would your solution cover for that if so can you give me a sample config

Ok, if this is what you're doing I would just simplify it by not doing my complicated configuration.  Yes, it will work, but its overkill for what you're after.

do the following instead:
1) Contact the owner of the DNS zone hosting webaddress.com (if its you skip this)
2) Change the TTL of the webaddress.com DNS record to something very low like 5 minutes.  Take note of what the current TTL is (they are in seconds).
3) Wait 2 times the old TTL value.  If it was 1 week, wait 2 weeks.  This is so you ensure any caching DNS servers have the new TTL so everyone updates appropriately (2 times just as a precaution really even though 1 times should be fine)
4) Change the DNS record to point to the new ISP's address you're assigning to your server.
5) update teh ASA changing the NAT configuration to be the new address.
6) after everything is tested good, change the TTL back to the old value.  Maybe test for a couple days.  If you don't see issues within that time period it should be safe to say you're good.

The maximum impact would be about 10 minutes during that process as DNS updates.  So if you do during off hours it shouldn't be a big deal.  This 10 minute outage is FAR better IMHO to put up with than the outside NAT of clients and policy NAT for the server which is going to be complicated.  To me its kind of a band-aid thing.  Rip it off fast and be done with it.  The best case about this too is if things don't go right, just change the ASA config back and change the DNS back to the old address so you have a quick revert of the change.

Seriously, I highly recommend this method instead from the sounds of what you're trying to accomplish.  It drastically simplifies the config and provides a quicker method of reverting back to a known good state if anything goes wrong.
s1mwatAuthor Commented:
Many thanks for the info.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Managed Security Services Webinar - March 15

Selecting the right managed security services platform to grow your business can be a huge undertaking. Join WatchGuard and Frost & Sullivan in an upcoming webinar as we dive into the key elements of selecting a vendor platform and partnership to fuel a successful MSSP business.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now