Supporting two outside interfaces on ASA 5510

[skhader]

Hello,

I am planning to change my Internet provider, but it must be done in stages so in addition to my existing outside interface, I need to create a secondary outside interface to a different carrier.  But both interfaces need to NAT to an inside server.  Here is an example:

interface Ethernet0/0

 nameif Outside1

 security-level 0

 ip address 1.1.1.1 255.255.255.192

!

interface Ethernet0/1

 nameif Inside

 security-level 100

 ip address 192.x.x.x 255.255.255.0

!

interface Ethernet0/2

nameif Outside2

 security-level 0

 ip address 2.2.2.2 255.255.255.192

static (Inside,Outside1) udp interface 5050 TMAPP 5050 netmask 255.255.255.255  

static (Inside,Outside2) udp interface 5050 TMAPP 5050 netmask 255.255.255.255  

Can this be done?

[balaji.bandi]

yes that can be achieved, please look some examples  also for reference :

https://www.practicalnetworking.net/stand-alone/cisco-asa-nat/

[Karsten Iwen]

Are you aware that you are running an EOL security device with probably tons of security vulnerabilities that didn't get updated for probably seven years? Hopefully you are not working in a country where you are legally responsible for the damage you can cause by that.

[Aref Alsouqi]

Yes that could be done, however, one of the big limitations you would run into would be how to route the outbound traffic across the two ISPs. The ASA does not support multiple default routes, which means that the outbound traffic would be routed via a single ISP, unless you configure a policy based routing to force part of the traffic to be routed via the ISP1, and other via the ISP2. Alternatively you could configure two specific routes and split the destination public IP ranges in two parts, one via ISP1 and another via ISP2.

[skhader]

Hi Aref,

Thanks for the reply and feedback.  Maybe I can clarify further.  The source is a mobile device connected to a mobile router (Mobile Gateway Router) configured and connected with a cellular SIM from Verizon.  The mobile device behind the MGR is configured to talk to a server inside the network via the public IP address of ISP1, so the destination configuration of the mobile device is the public IP address of ISP1 (for this example 1.1.1.1).  The communication path as shown in the diagram is from mobile device to the MGR to the cellular carrier to the Egress port on the firewall E 0/0 with the IP address provided by ISP 1 when it hits the Egress port of the firewall it gets NAT’d to the inside IP address of the inside server TMAPP (192.168.x.x) on port 5050 as shown in the example above. 

The goal is to replace ISP1 with ISP2, but it will take some time to touch all the mobile devices and change the IP address destination to the new public IP address of ISP2 (for this example 2.2.2.2), therefore some mobile devices will be configured with destination of 1.1.1.1 and others will be configured with the new address 2.2.2.2 until all device configurations are changed, we will have to keep both ISPs.  All mobile devices will need to communicate to the same server with actual address of 192.168.x.x.  So, both outside ports E0/0 and E0/2 will have to NAT the traffic on the same port 5050 to the same server? 

Not sure if I complicated this more than it needs to be or it makes sense?  The best thing to do is a cold cutover and switch the ISP providers, but unfortunately it will take few weeks to re-configure all the mobile devices with the new IP address destinations and that is why I wanted to do this translation over time until all mobile devices are changed and then will drop ISP1.

Thanks,

[Aref Alsouqi]

You are welcome. I do still think this wouldn't work with the return traffic. The issue here is not much with the inbound traffic, that would work with the two NAT rules you pasted before, however, for the return traffic from the internal server to the outside word we need some sort of enforcement to take the same path in which the traffic was received. Thinking about it more I think the best option in this case would be to configure the mobile devices with a FQDN rather than an IP address, pointing the DNS resolution to ISP1, and once all the mobile devices are configured with that FQDN, you switch the DNS to point to ISP2.

[skhader]

Hi Aref,

Unfortunately, the mobile device I have does not support or work with FQDN, I have to use an IP address only.  I thought the ASA is smart enough to know where the traffic came from so the return traffic takes the same path.  Are there any other options? How about using dynamic or overloading NAT?  If there is no other option, maybe I will have to temporary use a second firewall but not a preference?  Thanks for the help.

[Sheraz.Salim]

have you consider a defautl floating route. this could be easy way going forward

interface Ethernet0/0
 nameif Outside1
 security-level 0
 ip address 1.1.1.1 255.255.255.192
!
interface Ethernet0/1
 nameif Inside
 security-level 100
 ip address 192.x.x.x 255.255.255.0
!
interface Ethernet0/2
nameif Outside2
 security-level 0
 ip address 2.2.2.2 255.255.255.192
!
static (Inside,Outside1) udp interface 5050 TMAPP 5050 netmask 255.255.255.255  
!
static (Inside,Outside2) udp interface 5050 TMAPP 5050 netmask 255.255.255.255
!
route Outside1 0.0.0.0 0.0.0.0 next-hop
route Outside2 0.0.0.0 0.0.0.0 next-hop 10

now if Ouside1 cutover the Outside2 route will kick in.

[Aref Alsouqi]

I don't believe the ASA would have that functionality, but maybe @Rob Ingram has some ideas.

[Sheraz.Salim]

ASA does have this function.

@skhader you could use this link here the confiuration using the back interface with ip-sla. hope this will help you

[Aref Alsouqi]

Yes the ASA has the SLA monitor and tracking functionality but not to return the traffic out of the interface it was received on.

[Rob Ingram]

@skhader I agree with @Aref Alsouqi initial response, the ASA would only route the return traffic via the default route, there can only be one active and the ASA (afaik) is not intelligent to know which interface the traffic came in on. Failover of default routes I don't think will help.

Perhaps during cutover phase, if you know the source IP addresses define static routes via the other interface (ISP2), leaving the default route via ISP1 for the existing communication. Once the migration is complete, you can then change the default route via ISP2.

[skhader]

Thank you Rob and everyone else helping.  I will try a couple of suggestions and ideas presented here and test.  Thank yo all again for your help.