Showing posts with label NAT. Show all posts
Showing posts with label NAT. Show all posts

Tuesday, March 31, 2020

Aware Software Infrastructure (VASI) NAT on a Stick



Configuration:
>> CSR1

interface GigabitEthernet1
ip address 192.168.123.1 255.255.255.0
negotiation auto
end

ip route 0.0.0.0 0.0.0.0 192.168.123.3

>> CSR2

interface GigabitEthernet1
ip address 192.168.123.2 255.255.255.0
no ip redirects
negotiation auto
end

ip route 0.0.0.0 0.0.0.0 192.168.123.3

>> CSR3

vrf definition BLUE
address-family ipv4
exit-address-family

interface GigabitEthernet1
ip address 192.168.123.3 255.255.255.0
ip nat inside
ip policy route-map PBR
negotiation auto

interface GigabitEthernet2
ip address 34.34.34.3 255.255.255.0
ip nat outside
negotiation auto

interface vasileft1
ip address 6.6.6.1 255.255.255.0
ip nat outside
no keepalive

interface vasiright1
vrf forwarding BLUE
ip address 6.6.6.2 255.255.255.0
no keepalive

ip nat pool NAT-POOL 10.0.12.0 10.0.12.255 prefix-length 24
ip nat inside source static 192.168.123.2 34.34.34.2 no-alias
ip nat outside source list NAT pool NAT-POOL

ip route 0.0.0.0 0.0.0.0 34.34.34.4
ip route 34.34.34.2 255.255.255.255 192.168.123.2
ip route vrf BLUE 0.0.0.0 0.0.0.0 vasiright1
ip route vrf BLUE 10.0.12.0 255.255.255.0 6.6.6.1
ip route vrf BLUE 34.34.34.2 255.255.255.255 vasiright1 6.6.6.1

ip access-list extended NAT
permit ip 192.168.123.0 0.0.0.255 host 34.34.34.2
ip access-list extended PBR
permit ip 192.168.123.0 0.0.0.255 host 34.34.34.2
permit ip host 192.168.123.2 10.0.12.0 0.0.0.255

route-map PBR permit 10
match ip address PBR
set ip next-hop 6.6.6.2

>> CSR4

interface GigabitEthernet2
ip address 34.34.34.4 255.255.255.0
negotiation auto
end


https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/200255-Configure-VRF-Aware-Software-Infrastruct.html

Implementing bidirectional source NAT on IOS-XE platform

Introduction


In few scenarios customers wish to implement Source NAT in a bidirectional way. It means they wish to perform Source NAT while going from Interface 1 to Interface 2 and vice versa.

Problem


Current Solution is to achieve the same using NVI feature on IOS and it works perfectly as port overload can be done in both directions. The other alternative is to use traditional nat inside and outside interfaces and configure NAT accordingly. However performing port overload while defining "ip nat outside source xxx"  is not supported.

Now in IOS XE NVI feature is not supported. Hence we are left with only traditional NAT feature but it is not an scalable solution as we can't do port overload. We need to define pool of "n" IP addresses if we want to perform outside to inside source translation for "n" sources.

Solution


This problem can be resolved by using VASI feature available on XE platform. We need to keep interfaces in different vrf. For instance "Interface 1" can be in vrf A and "interface 2" can be in vrf B or any one of them can be in Global Routing table. At end of the day intention is to keep both interfaces in different Routing Domain.

Please find an sample Configuration to achieve the same below :--

Prerequisite:  We need to enable License appxk9 and then only we can create Vasi interfaces.


Topology :--

192.168.1.0/24------Gi0/0/0   (IOS-XE Router)   Gi0/0/2-----10.10.10.0/24

We have binded Gi0/0/0 and vasileft1 in vrf A
Gi0/0/2 and vasiright1 in vrf B
Pool K1 is used to NAT traffic coming from vrf A 192.168.1.0/24
Pool K2 is used to NAT traffic coming from vrf B 10.10.10.0/24
We need Routing in both VRF to point to each other for source subnets. I have used default routes but it can be replaced with routes for post NAT source IP's.


vrf definition A
!
address-family ipv4
exit-address-family
!
vrf definition B
!
address-family ipv4
exit-address-family
!


license boot level appxk9

interface GigabitEthernet0/0/0
vrf forwarding A
ip address 192.168.1.10 255.255.255.0
ip nat inside
negotiation auto
!

interface GigabitEthernet0/0/2
vrf forwarding B
ip address 10.10.10.1 255.255.255.252
ip nat inside
negotiation auto
!

interface vasileft1
vrf forwarding A
ip address 172.16.1.1 255.255.255.0
ip nat outside
no keepalive
!
interface vasiright1
vrf forwarding B
ip address 172.16.2.1 255.255.255.0
ip nat outside
no keepalive
!
!

!
ip nat pool K1 11.11.11.11 11.11.11.11 prefix-length 24
ip nat pool K2 22.22.22.22 22.22.22.22 prefix-length 24
ip nat inside source list 100 pool K1 vrf A overload
ip nat inside source list 101 pool K2 vrf B overload



ip route vrf A 0.0.0.0 0.0.0.0 vasileft1
ip route vrf B 0.0.0.0 0.0.0.0 vasiright1
!
!
access-list 100 permit ip 192.168.1.0 0.0.0.255 10.10.10.0 0.0.0.255
access-list 101 permit ip 10.10.10.0 0.0.0.255 192.168.1.0 0.0.0.255

Saturday, February 22, 2020

Cisco IOS NAT on a Stick Configuration Example

NAT (Network Address Translation) is most commonly used to let users on our LAN access the Internet using a single public IP address but it can be used for some more interesting scenarios. Recently I encountered an interesting CCIE R&S task that had the following requirement:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface"
This sounds easy enough but there’s no such thing as a “traceroute source loopback 0” command or anything alike. To make this work we have to configure the NAT on a stick feature. In this tutorial, I’ll show you this is done. First of all, this is the topology that we will use:
Two Routers R2 Loopback Interface
There are only two routers that are directly connected to each other. R2 has a loopback 0 interface with IP address 2.2.2.0 /24. Let’s configure these IP addresses first:
R1(config)#interface fa0/0
R1(config-if)#no shutdown
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R2(config)#interface fa0/0
R2(config-if)#no shutdown
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#interface loopback0
R2(config-if)#ip address 2.2.2.2 255.255.255.0
Before we dive into the NAT configuration let’s do a trace and look at the output:
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 192.168.12.2 0 msec 4 msec *
As expected R2 responds with the IP address on its FastEthernet interface. The task requires this output to show the 2.2.2.2 address from the loopback interface. To achieve this we’ll configure NAT on R2:
R2(config)#access-list 100 permit icmp any any time-exceeded
R2(config)#access-list 100 permit icmp any any port-unreachable

R2(config)#ip nat inside source list 100 interface loopback0 overload

R2(config)#interface fastethernet 0/0
R2(config-if)#ip nat inside

R2(config)#interface loopback 0
R2(config-if)#ip nat outside
The configuration above defines the FastEthernet interface as NAT inside and the loopback interface as NAT outside. An access-list is used to permit the ICMP time-exceeded and port-unreachable packets that are used as a response to a traceroute. The NAT configuration itself is complete but we still have a problem with this setup, take a look at the following picture:
Cisco Traceroute ReplyIf you look closely at the image above you can see that whenever R1 does a trace, R2 will reply with its FastEthernet 0/0 interface. In order for NAT to work traffic has to flow from the inside interface to the outside interface. To fix this we can configure policy based routing on R2 to forward traffic to the loopback 0 interface:
R2(config)#route-map FORWARD_TO_L0
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback0
R2(config)#ip local policy route-map FORWARD_TO_L0
This route-map matches on the interface that we created before and forwards the traffic towards the loopback 0 interface. We also require the ip local policy command to apply the route-map to self-generated traffic. Let’s enable a debug on R2 and try that traceroute again from R1:
R2#debug ip policy 
Policy routing debugging is on

R2#debug ip nat
IP NAT debugging is on
Time to trace!
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 2.2.2.2 0 msec 4 msec *
Excellent, we now see IP address 2.2.2.2 from R2 in our traceroute. Let’s take a look at the debug on R2:
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: local to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [17]
The first line is the ICMP packet from R2 towards R1 that it wants to send as a reply to the traceroute. It matches the route-map so it is being policy based routed towards the loopback 0 interface. Since the loopback 0 interface is configured for NAT outside, IP address 192.168.12.2 is translated to 2.2.2.2 and then routed towards R1. Basically it looks like this:
Cisco NAT on a Stick Example
Great! it’s working as it should…what if we make this scenario a little bit more interesting by changing the task as following:
"Make sure that whenever R2 responds to a traceroute it replies with the IP address on the loopback 0 interface, you are not allowed to configure NAT on the FastEthernet interface but you may configure an additional interface and IP address."
No problem! We can still make this work but we’ll have to use another interface that is configured with the “IP NAT inside” command. Traffic still has to flow from a NAT inside interface to a NAT outside interface in order to be translated. To accomplish this we will create a new loopback interface that has the “IP NAT inside” command. We will send traffic from the FastEthernet interface to the new loopback and then forward it to the first loopback interface. I know this sounds funky so let me help you visualize it:
Cisco NAT on a Stick Two Loopback Interfaces
Just follow the arrows starting at R1.  This is what we have to configure:
  1. Configure policy based routing so that the ICMP replies are forwarded from the FastEthernet interface to the new loopback 1 (NAT inside) interface.
  2. Configure policy based routing so that the ICMP replies are forwarded from the loopback 1 interface to the loopback 0 (NAT outside) interface.
First we’ll remove the NAT configuration from the FastEthernet interface and I’ll also get rid of the policy based routing configuration:
R2(config)#interface fa0/0
R2(config-if)#no ip nat inside
R2(config)#no ip local policy route-map FORWARD_TO_L0
Let’s create a new loopback interface. I just made up an IP address, it really doesn’t matter what we configure here as long as there’s something. Don’t forget to add IP NAT inside:
R2(config)#interface loopback 1
R2(config-if)#ip address 22.22.22.22 255.255.255.0
R2(config-if)#ip nat inside
We will create a new route-map that forwards ICMP traffic to the loopback 1 interface:
R2(config)#ip local policy route-map FORWARD_TO_L1
R2(config)#route-map FORWARD_TO_L1
R2(config-route-map)#match ip address 100
R2(config-route-map)#set interface loopback 1
The route-map that we created before can now be applied to the loopback 1 interface. This ensures that traffic is forwarded to the loopback 0 interface:
R2(config)#interface loopback1
R2(config-if)#ip policy route-map FORWARD_TO_L0
That should do it. Let’s try our trace again:
R1#traceroute 192.168.12.2

Type escape sequence to abort.
Tracing the route to 192.168.12.2

  1 2.2.2.2 4 msec 4 msec *
Excellent, it’s working! What does the debug look like now?
R2#
IP: s=192.168.12.2 (local), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L1, item 10, permit
IP: s=192.168.12.2 (local), d=192.168.12.1 (Loopback1), len 56, policy routed
IP: local to Loopback1 192.168.12.1
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1, len 56, policy match
IP: route map FORWARD_TO_L0, item 10, permit
IP: s=192.168.12.2 (Loopback1), d=192.168.12.1 (Loopback0), len 56, policy routed
IP: Loopback1 to Loopback0 192.168.12.1
NAT: s=192.168.12.2->2.2.2.2, d=192.168.12.1 [21]
Look closely at the debug and you can see that the ICMP traffic is forwarded to the loopback 1 interface, then to the loopback 0 interface and because it flowed from a NAT inside to a NAT outside interface it can now be translated.
hostname R1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
end
hostname R2
!
ip cef
!
interface Loopback0
 ip address 2.2.2.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
!
interface Loopback1
 ip address 22.22.22.22 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
 ip policy route-map FORWARD_TO_L0
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
!
ip local policy route-map FORWARD_TO_L1
!
ip nat inside source list 100 interface Loopback0 overload
!
access-list 100 permit icmp any any time-exceeded
access-list 100 permit icmp any any port-unreachable
!
route-map FORWARD_TO_L0 permit 10
 match ip address 100
 set interface Loopback0
!
route-map FORWARD_TO_L1 permit 10
 match ip address 100
 set interface Loopback1
!
end
That’s all I have for you now, hopefully you enjoyed this tutorial! If you have any questions feel free to leave a comment.

IP NAT inside source vs IP NAT outside source

On Cisco IOS routers we can use the ip nat inside sourceand ip nat outside source commands. Most of us are familiar with the ip nat inside source command because we often use it to translate private IP addressses on our LAN to a public IP address we received from our ISP.
What about the ip nat outside source command? Does it work in the same way as ip nat inside source?
This is the difference between the two commands:
ip nat inside source:
  • Translates the source IP address of packets that travel from inside to outside.
  • Translates the destination IP address of packets that travel from outside to inside.
ip nat outside source:
  • Translates the source IP address of packets that travel from outside to inside.
  • Translates the destination IP address of packets that travel from inside to outside.

Configuration

Let’s look at these two commands in action. I use the following topology to demonstrate this:
R1 H1 H2 Nat Inside Outside Source Topology
IP routing is disabled on H1 and H2, they use R1 as their default gateway.
hostname H1 
! 
no ip routing 
! 
no ip cef 
! 
interface GigabitEthernet0/1 
 ip address 192.168.1.1 255.255.255.0 
! 
ip default-gateway 192.168.1.254 
! 
end
hostname H2 
! 
no ip routing 
! 
no ip cef 
! 
interface GigabitEthernet0/1 
 ip address 192.168.2.2 255.255.255.0 
! 
ip default-gateway 192.168.2.254 
! 
end
hostname R1 
! 
ip cef 
! 
interface GigabitEthernet0/1 
 ip address 192.168.1.254 255.255.255.0 
 ip nat inside 
 ip virtual-reassembly in 
! 
interface GigabitEthernet0/2 
 ip address 192.168.2.254 255.255.255.0 
 ip nat outside 
 ip virtual-reassembly in 
! 
end
Let’s enable NAT debugging on R1 so we can see everything in action:
R1#debug ip nat 
IP NAT debugging is on

IP NAT inside source

Let’s start with ip nat inside source, the command we are most familiar with. I’ll configure an entry that translates 192.168.1.1 to 192.168.2.200:
R1(config)#ip nat inside source static 192.168.1.1 192.168.2.200
Let’s send a ping from H1 to 192.168.2.2:
H1#ping 192.168.2.2 repeat 1 
Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 192.168.2.2, timeout is 2 seconds: 
! 
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R1 produces the following debug output:
R1# 
NAT*: s=192.168.1.1->192.168.2.200, d=192.168.2.2 [3] 
NAT*: s=192.168.2.2, d=192.168.2.200->192.168.1.1 [3]
  • The source IP address 192.168.1.1 is translated to 192.168.2.200 when the IP packet travels from the inside to the outside.
  • The destination IP address 192.168.2.200 is translated to 192.168.1.1 when the return IP packet travels from the outside to inside.
We can also try a ping from H2. Let’s see what happens when we ping 192.168.2.200:
H2#ping 192.168.2.200 repeat 1 
Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 192.168.2.200, timeout is 2 seconds: 
! 
Success rate is 100 percent (1/1), round-trip min/avg/max = 5/5/5 ms
R1 produces the following debug output:
R1# 
NAT*: s=192.168.2.2, d=192.168.2.200->192.168.1.1 [8] 
NAT*: s=192.168.1.1->192.168.2.200, d=192.168.2.2 [8]
  • The destination IP address is translated from 192.168.2.200 to 192.168.1.1 when the IP packet travels from the outside to the inside.
  • The source IP address is translated from 192.168.1.1 to 192.168.2.200 when the return IP packet travels from the inside to the outside.
Can I ping the 192.168.1.1 IP address from H2? Let’s find out:
H2#ping 192.168.1.1 repeat 1 
Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: 
! 
Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms
This is what we see on R1:
R1# 
NAT*: s=192.168.1.1->192.168.2.200, d=192.168.2.2 [6]
The source IP address 192.168.1.1 is translated to 192.168.2.00 when it travels from the inside to the outside.

IP NAT outside source

Let’s find out how the ip nat outside source command works. I’ll use the following command:
R1(config)#R1(config)#ip nat outside source static 192.168.2.2 192.168.2.200
This translates source IP address 192.168.2.2 to 192.168.2.200 when the IP packet travels from the outside to the inside.
Let’s try a ping from H2 to 192.168.1.1:
H2#ping 192.168.1.1 repeat 1 
Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: 
! 
Success rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms
We see the following NAT translations on R1:
R1# 
NAT: s=192.168.2.2->192.168.2.200, d=192.168.1.1 [9] 
NAT: s=192.168.1.1, d=192.168.2.200->192.168.2.2 [9]
  • Source IP address 192.168.2.2 is translated to 192.168.2.200 when the IP packet travels from the outside to the inside.
  • Destination IP address 192.168.2.200 is translated to 192.168.2.2 when the return IP packet travels from the inside to the outside.
What about a ping from H1 to 192.168.2.200?
H1#ping 192.168.2.200 repeat 1 
Type escape sequence to abort. 
Sending 1, 100-byte ICMP Echos to 192.168.2.200, timeout is 2 seconds: 
! 
Success rate is 100 percent (1/1), round-trip min/avg/max = 6/6/6 ms
Here’s the debug on R1:
R1# 
NAT: s=192.168.1.1, d=192.168.2.200->192.168.2.2 [11] 
NAT*: s=192.168.2.2->192.168.2.200, d=192.168.1.1 [11]
  • Destination IP address 192.168.2.200 is translated to 192.168.2.2 when the IP packet travels from the inside to the outside.
  • Source IP address 192.168.2.2 is translated to 192.168.2.200 when the return IP packet travels from the outside to the inside.

Conclusion

You have now learned the difference between the ip nat inside source and ip nat outside source commands:
  • ip nat inside source:
    • translates the source IP address when a packet travels from the inside to the outside.
    • translates the destination IP address when a packet travels from the outside to the inside.
  • ip nat outside source:
    • translates the source IP address when a packet travels from the outside to the inside.
    • translates the destination IP address when a packet travels from the inside to the outside.
I hope you enjoyed this lesson. If you have any questions feel free to leave a comment!

NAT with two outside interfaces

If you are connected to two ISPs and looking to use NAT, you might have discovered that with the “ip nat inside source” command you can only specify one outgoing interface. Since you have two outgoing interfaces, you’ll need to use a route-map to get this working. I will show you how to do this using the following topology:
NAT Two Outside Interfaces
Above we have a ‘host’ router that will be our client on the internal network. NAT is of course our NAT/PAT router and on the right we have two ISPs.

Configuration

Let’s configure the host first:
Host(config)#no ip routing 
Host(config)#ip default-gateway 192.168.12.2
First I will disable ip routing so it becomes an ordinary host device. We’ll configure the NAT router as the default gateway. Now we can configure the NAT router:
NAT(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3
NAT(config)#ip route 0.0.0.0 0.0.0.0 192.168.24.4
I will create two equal static routes, one for ISP1 and another one for ISP2. This allows us to do load balancing.
To make your default routes reliable, I can highly recommend you to configure object tracking and IP SLA.
These two static routes will allow us to perform load-balancing:
NAT#show ip route static 
S*   0.0.0.0/0 [1/0] via 192.168.24.4
               [1/0] via 192.168.23.3
With our routing operational, we can continue to configure NAT. First I’ll configure the correct inside and outside interfaces:
NAT(config)#interface fastEthernet 0/0
NAT(config-if)#ip nat inside

NAT(config)#interface fastEthernet 0/1
NAT(config-if)#ip nat outside            

NAT(config)#interface fastEthernet 1/0
NAT(config-if)#ip nat outside
Next step is to configure an access-list to determine what hosts should be NATed. I’ll make sure that the entire 192.168.12.0/24 will be translated:
NAT(config)#access-list 1 permit 192.168.12.0 0.0.0.255
Now we can create the NAT rules and route-maps:
NAT(config)#ip nat inside source route-map ISP1 int fa 0/1 overload  
NAT(config)#ip nat inside source route-map ISP2 int fa 1/0 overload 

NAT(config)#route-map ISP1 permit 10
NAT(config-route-map)#match ip address 1
NAT(config-route-map)#match interface fastEthernet 0/1

NAT(config)#route-map ISP2 permit 10
NAT(config-route-map)#match ip address 1
NAT(config-route-map)#match interface fastEthernet 1/0
For each ISP we have a route-map. When you match the access-list and the correct outgoing interface then it will be translated to the IP address of the correct outgoing interface.

Verification

To see if it’s working we’ll generate some traffic on the host. I will enable debugging on the ISPs so that we can see what is going on realtime:
ISP1#debug ip packet 
IP packet debugging is on
ISP2#debug ip packet 
IP packet debugging is on
Now let’s send some pings:
Host#ping 2.2.2.2    

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.U.U.
Success rate is 0 percent (0/5)
The IP address that I’m pinging doesn’t exist but it will end up at one of the ISPs because of the default routes on the NAT router. We can verify that the packets made it to ISP1 and have been translated:
ISP1#
IP: s=192.168.23.2 (FastEthernet0/0), d=2.2.2.2, len 100, unroutable
IP: tableid=0, s=192.168.23.3 (local), d=192.168.23.2 (FastEthernet0/0), routed via FIB
As you can see above ISP1 received IP packets with from IP address 192.168.23.2. Let’s send some more pings so ISP2 also receives some traffic:
Host#ping 3.3.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
ISP2#
IP: s=192.168.24.2 (FastEthernet0/0), d=3.3.3.3, len 100, unroutable
IP: tableid=0, s=192.168.24.4 (local), d=192.168.24.2 (FastEthernet0/0), routed via FIB
And ISP2 receives traffic from IP address 192.168.24.2. It’s even better to check the NAT translation table on our NAT router:
NAT#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
icmp 192.168.23.2:5    192.168.12.1:5     2.2.2.2:5          2.2.2.2:5
icmp 192.168.24.2:6    192.168.12.1:6     3.3.3.3:6          3.3.3.3:6
Above you can see that traffic towards ISP1 has been translated to 192.168.23.2 and traffic towards ISP2 has been translated to 192.168.24.2.
hostname Host
!
no ip routing
!
no ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.1 255.255.255.0
!
ip default-gateway 192.168.12.2
!
end
hostname ISP1
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
!
end
hostname ISP2
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.24.4 255.255.255.0
!
end
hostname NAT
!
ip cef
!
interface FastEthernet0/0
 ip address 192.168.12.2 255.255.255.0
 ip nat inside
 ip virtual-reassembly in
!
interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
!
interface FastEthernet1/0
 ip address 192.168.24.2 255.255.255.0
 ip nat outside
 ip virtual-reassembly in
!
ip nat inside source route-map ISP1 interface FastEthernet0/1 overload
ip route 0.0.0.0 0.0.0.0 192.168.23.3
ip route 0.0.0.0 0.0.0.0 192.168.24.3
!
access-list 1 permit 192.168.12.0 0.0.0.255
!
route-map ISP2 permit 10
 match ip address 1
 match interface fastEthernet 1/0
!
route-map ISP1 permit 10
 match ip address 1
 match interface FastEthernet0/1
!
end

That’s all I wanted to show you, I hope this has been helpful to you to configure NAT with two outside interfaces. If you have any questions feel free to ask!