First off, this is not the first time I did this... but it is the first time in 12.4... and it seems there have been changes that are causing me issues.
Here is a sample of what I had done in 12.3 which worked perfectly.
description Internal Side
ip address 10.0.2.254 255.255.255.0
ip nat inside
description Internet Side
ip address 126.96.36.199 255.255.255.240 secondary
ip address 188.8.131.52 255.255.255.240
ip nat outside
ip nat inside source static tcp 10.0.2.2 80 184.108.40.206 80 extendable
ip nat inside source static tcp 10.0.2.2 80 220.127.116.11 80 route-map biWAN-PAE extendable
ip route 0.0.0.0 0.0.0.0 18.104.22.168 permanent
route-map biWAN-PAE permit 10
set ip next-hop 22.214.171.124
Now when I try to do this in 12.4, it simply won't work. First it won't allow the two "ip nat inside source static" commands as-is. I need to define them with a route-map each. So I created another route-map with a "set ip next-hop" for the 126.96.36.199 gateway. But all my traffic is headed to 188.8.131.52 regardless of what translation/route-map it uses.
My thought at this point is to setup a loopback interface for all 'outside' traffic and try to setup a route-map on the loopback interface so I can have the route-map ACLs working on public IP addresses...
Thoughts on this?
Thanks! -Cheers, Peter.
First of all my question to you would be : "why are you implementing NAT in this fashion?"
You do not have multiple exit interfaces, just multiple public ip's. So whats the benefit of using two public ip's to access the same Internal server. I mean if that ISP link or the interface goes down, then both these public ip's would not work.
Secondly, while sending the traffic out, routing always happens before NAT. So even if you have "set ip next-hop" statement added in the route-map which is called on a NAT statement, it will not do anything because routing decision has been already made. So as a best practice, don't use "set ip next-hop" command in route-maps which are being used for NAT.
"set ip next-hop" command should only be used when PBR is implemented and the route-map is called under an interface using the "ip policy route-map" command.
Only after understanding your actual requirement, we can suggest a solution or a workaround.
I am not worried so much about the interface failure as I am about Internet access failure. The two IP blocks are provided over two different links which are consolidated via a ethernet switch.
I have read about the route being before nat... but I am thinking that there must be some way to route after nat. Either by using a loopback interface or such, but I just have not come to a solution.