Dual ISP inbound NAT

[beerygaz]

I have two ISP's - one via Dialer 0 (ADSL) and one via DHCP (FastEthernet 0/1).  I can selectively route outbound traffic using route-maps and ACLs but I can't figure out how to nat inbound traffic from either public interface to a single internal server.

Currently I have:

ip nat inside source static tcp 192.168.1.1 80 interface FastEthernet0/1 80

But how do I duplicate that for Dialer 0 too?

Research suggests I could use the "extendable" option on the ip nat command but that is only available if I know the static global address, and given that they are both dynamic, I need to use the "interface" option rather than specifying the global IP.

Any ideas on how I crack this one would be much appreciated.

[Martin Hruby]

Hello

The main issue with this, as you pointed out, is that you don't know the inside global address because it's dynamic. For outgoing traffic this is possible if you implement this:

http://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/100658-ios-nat-load-balancing-2isp.html

Returning traffic is permitted due to an existing entry in the translation table. However you don't know the source TCP port if session is initiated from the outside. It would be nice to have this work with the reversible keyword, however it's not working with PAT.

The easiest solution to your issue would be to add a dummy secondary IP address on your web server and duplicate your static NAT entry command. For example you could assign 192.168.1.3 as a secondary IP to your web server (which shouldn't be a problem on most production Windows or Linux operating systems) and configure a new translation rule similar to the one you have:

ip nat inside source static tcp 192.168.1.3 80 interface Dialer1 80

That will accomplish what you want although it's not nice.

Best regards,
Martin

[beerygaz]

Martin, thanks for your advice.  I have come to the same conclusion that the simplest, if inelegant, solution is secondary addresses and a corresponding additional translation rule.  

That meets most of my needs.  The exceptions are IoT devices that don't support a secondary address.  I'm going to have to fiddle with some tcl scripts to dynamically change the running config based on link availability.

Gavin