TCP Load Balancing, Destination NAT

The "ip nat inside destination" command can be used to split up the load from what looks like one global destination, to several inside hosts. This behaves very much like server load balancing, at least without all the health checks.

Below is the topology. I have static default routes from R1, R2, and R3 pointing to R4. R7 has a static route to each serial link.


Here is R4's config:

interface FastEthernet0/0
ip address 192.168.0.4 255.255.255.0
ip nat inside
ip virtual-reassembly
!
interface Serial1/0
ip address 192.168.45.4 255.255.255.0
ip verify unicast reverse-path
ip nat outside
ip virtual-reassembly
serial restart-delay 0
!
interface Serial1/1
ip address 192.168.46.4 255.255.255.0
ip verify unicast reverse-path
ip nat outside
ip virtual-reassembly
!
ip route 0.0.0.0 0.0.0.0 192.168.45.5
ip route 0.0.0.0 0.0.0.0 192.168.46.6
!
ip nat pool POOL 192.168.0.1 192.168.0.3 prefix-length 24 type rotary
ip nat inside destination list 10 pool POOL
!
access-list 10 permit 192.168.45.10
access-list 10 permit 192.168.46.10

From R7 we will verify:

R7#telnet 192.168.45.10  
Trying 192.168.45.10 ... Open

R1>
R1>exit

[Connection to 192.168.45.10 closed by foreign host]
R7#telnet 192.168.45.10
Trying 192.168.45.10 ... Open

R2>exit

[Connection to 192.168.45.10 closed by foreign host]
R7#telnet 192.168.45.10
Trying 192.168.45.10 ... Open

R3>exit

[Connection to 192.168.45.10 closed by foreign host]
R7#telnet 192.168.46.10
Trying 192.168.46.10 ... Open

R1>exit

[Connection to 192.168.46.10 closed by foreign host]
R7#telnet 192.168.46.10
Trying 192.168.46.10 ... Open

R2>exit

[Connection to 192.168.46.10 closed by foreign host]
R7#

R4's NAT table:

R4#sho ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
tcp 192.168.45.10:23   192.168.0.1:23     200.0.0.7:51519    200.0.0.7:51519
tcp 192.168.46.10:23   192.168.0.1:23     200.0.0.7:64139    200.0.0.7:64139
tcp 192.168.46.10:23   192.168.0.2:23     200.0.0.7:11691    200.0.0.7:11691
tcp 192.168.45.10:23   192.168.0.2:23     200.0.0.7:62913    200.0.0.7:62913
tcp 192.168.45.10:23   192.168.0.3:23     200.0.0.7:17295    200.0.0.7:17295

I used two links just to show the flexibility of this configuration. I was playing around with route-map NAT failover/LB and then decided to work on this scenario.

SNAT: Making it work?

This is a poorly documented feature and I really just played around with it until I got it to work. If you see anything missing or unnecessary, please comment. The one thing I worry about is I am using secondary addresses which may or may not be allowed in the lab. If you know another way, PLEASE let me know. Other than that, it was all kind of patchwork but it does the job :-)

Here is the topology:


R6 will be our test host who will telnet to R4 at 4.4.4.4. If all goes well, after we shut the link from R1 to R2 (whos is HSRP Active), R6 session will stay up. We will then look at the NAT translation table on R2 and R3.

Here is the configuration for R2:

interface FastEthernet0/0
ip address 10.0.0.2 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 priority 105
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.202 255.255.255.0 secondary
ip address 172.12.12.2 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload

R3 is pretty much the same except for the IP addresses:

interface FastEthernet0/0
ip address 10.0.0.3 255.255.255.0
ip nat inside
standby 1 ip 10.0.0.1
standby 1 preempt
standby 1 name SNAT
standby 1 track Serial1/0

interface Serial1/0
ip address 172.12.23.203 255.255.255.0 secondary
ip address 172.12.13.3 255.255.255.0
ip nat outside

ip nat Stateful id 1
redundancy SNAT
mapping-id 10

ip nat pool POOL 172.12.23.1 172.12.23.254 prefix-length 24
ip nat inside source list LAN pool POOL mapping-id 10 overload

I had to put secondary addresses on the serial links. These routers need to share an address space so they can use the same address to translate and so R1 and R4 no how to reach the translated address range. This secondary address range is being advertised in ospf:

R1#sho ip route 172.12.23.0
Routing entry for 172.12.23.0/24
Known via "ospf 1", distance 110, metric 128, type intra area
Last update from 172.12.12.2 on Serial1/0, 00:07:58 ago
Routing Descriptor Blocks:
* 172.12.13.3, from 172.12.35.3, 00:07:58 ago, via Serial1/1
Route metric is 128, traffic share count is 1
172.12.12.2, from 2.2.2.2, 00:07:58 ago, via Serial1/0
Route metric is 128, traffic share count is 1

Also note that the HSRP group name "SNAT" is referenced in the stateful NAT configuration. The mapping ID is then referenced in the NAT statement itself.

Let's telnet from R6 to R4, we will first verify that we route through R2:

R6#telnet R4
Translating "R4"
% Unknown command or computer name, or unable to find computer address
R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#
R4#!here we are!

Shut the interface on R1 to R2:

R1(config)#int s1/0
R1(config-if)#shut

Check back on R4. This may take awhile because HSRP still has to failover:

R4#
R4#
R4#!Hey we're still alive!
R4#
R4#exit

[Connection to 4.4.4.4 closed by foreign host]
R6#trace 4.4.4.4

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 10.0.0.3 56 msec 48 msec 60 msec
2 172.12.13.1 132 msec 68 msec 104 msec
3 172.12.14.4 148 msec * 184 msec

We are going through R3! If we did not have SNAT, our session would have dropped when R4 noticed that our address has changed.

Let's look at our address translations:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
udp 172.12.23.5:37518 10.0.0.6:37518 4.4.4.4:33441 4.4.4.4:33441
udp 172.12.23.5:39661 10.0.0.6:39661 4.4.4.4:33442 4.4.4.4:33442
udp 172.12.23.5:42398 10.0.0.6:42398 4.4.4.4:33437 4.4.4.4:33437
udp 172.12.23.5:36656 10.0.0.6:36656 4.4.4.4:33439 4.4.4.4:33439
udp 172.12.23.5:39090 10.0.0.6:39090 4.4.4.4:33438 4.4.4.4:33438
udp 172.12.23.5:35099 10.0.0.6:35099 4.4.4.4:33440 4.4.4.4:33440
R3#

Exactly the same! Have no idea where these ports came from, but let's watch closer at the interaction between R2 and R3.

R2#clear ip nat translation *
R3#clear ip nat translation *

R6#telnet 4.4.4.4
Trying 4.4.4.4 ... Open

R4#

Here we go:

R2#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23

R3#sho ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.23.6:47684 10.0.0.6:47684 4.4.4.4:23 4.4.4.4:23

Some more commands:

R2#sho ip snat distributed
Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: STANDBY
    : State READY
    : Local Address 10.0.0.2
    : Local NAT id 1
    : Peer Address 10.0.0.3
    : Peer NAT id 1
    : Mapping List 10 

R3#sho ip snat distributed 

Stateful NAT Connected Peers

SNAT: Mode IP-REDUNDANCY :: ACTIVE
    : State READY
    : Local Address 10.0.0.3
    : Local NAT id 1
    : Peer Address 10.0.0.2
    : Peer NAT id 1
    : Mapping List 10 
R3#

R3 has already been updated and is ready to take over when needed.

IPv6 NAT-PT

This is a very simple IPv6 NAT-PT scenario. Here is the topology and addressing:


R1 is an IPv6 only host and R2 is an IPv4 only host.
R1 should use address 2001:23::2 to reach R2.
R2 should use 192.168.13.1 to reach R1.
R3 will be doing NAT-PT

Assign addresses per the diagram. The rest of the configuration is on R3.

R3(config)#int e0/0
R3(config-if)#ipv6 nat
R3(config-if)#int e0/1
R3(config-if)#ipv6 nat
R3(config)#ipv6 nat v4v6 source 192.168.23.2 2001:23::2
R3(config)#ipv6 nat v6v4 source 2001:13::1 192.168.13.1
R3(config)#ipv6 nat prefix 2001:23::/96

Remember to assing default gateways on R1 and R2:

R1(config)#ipv6 route 0::/0 2001:13::3

R2(config)#ip route 0.0.0.0 0.0.0.0 192.168.23.3

Let's ping from R1 while debugging on R3:

R3#debug ipv6 nat
IPv6 NAT-PT debugging is on

R1#ping 2001:23::2 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:23::2, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 4/4/4 ms
R1#

R3#
*Mar 1 13:51:12.323: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
*Mar 1 13:51:12.327: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst (192.168.13.1) -> (2001:13::1)
R3#

Now let's try the other way:

R2#ping 192.168.13.1 re 1

Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 192.168.13.1, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 8/8/8 ms
R2#

R3#
*Mar 1 13:53:00.991: IPv6 NAT: src (192.168.23.2) -> (2001:23::2), dst(192.168.13.1) -> (2001:13::1)
*Mar 1 13:53:00.995: IPv6 NAT: icmp src (2001:13::1) -> (192.168.13.1), dst (2001:23::2) -> (192.168.23.2)
R3#

You can view the translations on R3:

R3#sho ipv6  nat translations
Prot  IPv4 source              IPv6 source
      IPv4 destination         IPv6 destination
---   ---                      ---
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      192.168.23.2             2001:23::2

---   192.168.13.1             2001:13::1
      ---                      ---

That's it!

NAT on a Stick

NAT on a stick can get pretty confusing. Here is a lab I put together with the help of an example on Cisco site. I don't know if it is accessible through the DocCD so here is the link:

Network Address Translation on a Stick

The topology is a little different because I am using routers without any cable devices:


R2 is a host on the 10.0.0.0/24 network. It is using 10.0.0.1 (R1) as the gateway. R1 then NATs this address to 192.168.2.X before sending the packet on its way to R3. That's the basic rundown but the configuration is a little more complex.

First things first...Since 192.168.2.0 will be our translated address range make sure R4 and R3 both have routes to this range. R3 will use 192.168.1.1 as the next hop and R4 will use 100.0.0.3.

The rest of the configuration is on R1. Assign two addresses to R1 and configure it as our inside interface. 10.0.0.1 is used as a gateway address for hosts on the LAN and 192.168.1.1 is used to communicate with R3.

interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.0 secondary
ip address 10.0.0.1 255.255.255.0
ip nat inside

Create the loopback that will be used as our outside interface. Keep in mind we are using a /30 network, you will see why a little later on.

interface Loopback0
ip address 10.0.1.1 255.255.255.252
ip nat outside

Next define an ACL to match our inside hosts then configure the NAT pool and NAT statements:

access-list 10 permit 10.0.0.0 0.0.0.255
ip nat pool NAT 192.168.2.100 192.168.2.200 prefix-length 24
ip nat inside source list 10 pool NAT

Now this is where it get's a little tricky. I am trying to do this in a logical order, but in reality I just have to memorize what needs to be configured to finish this thing off.

Since the 192.168.2.0 network does not exist on any interface we tell R1 that it exists of F0/0 like this:

ip route 192.168.2.0 255.255.255.0 FastEthernet0/0

Finally, we add our policy routing configuration. Remember the ACL has to match traffic in both directions:

access-list 100 permit ip any 192.168.2.0 0.0.0.255
access-list 100 permit ip 10.0.0.0 0.0.0.255 any

route-map NAT-LOOP permit 10
match ip address 100
set ip next-hop 10.0.1.2

interface FastEthernet0/0
ip policy route-map NAT-LOOP

So now R1 knows to policy route any traffic coming from 10.0.0.0/24 or going towards 192.168.2.0/24. The next hop address is 10.0.1.2 which technically exists on the Loopback 0 network. Since our loopback has the NAT outside statement, translation occurs here.

Let's test:

R2#ping 100.0.0.4

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/60/112 ms
R2#

R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.2.100:8 10.0.0.2:8 100.0.0.4:8 100.0.0.4:8
--- 192.168.2.100 10.0.0.2 --- ---
R1#

Key things to remember about NAT on a Stick:

-Ensure upstream routers have to routes back to the NAT (outside) address
-ACL for policy routing is 2-way
-Loopback is used for outside interface, but the NAT pool is on a separate network.
-Use a route pointing to the LAN interface to tell the router where the outside network resides.

There are probably some variations of this configuration that will work. I am going to play around with some now, but that should be enough to get started.

NAT - Policy NAT with route-maps

Here is the topology. I use this for a lot of NAT scenarios. I have a dynamips file all ready to go for it :) The frame-relay network is 172.12.123.x where x is the router number. You can use whatever internal routing method you want.


Requirements:

When R5 telnets to 172.12.123.1 it should go through R2.
When R5 telnets to 172.12.123.1 port 3001 it should go through R3.

We will look at our NAT translations on R4 to verify.

First set up your outside interfaces (R4 to R2,R3) and inside interface (R4 to R5).

Next create an ACL top match out two types of traffic:

R4(config)#access-list 102 permit tcp host 172.12.45.5 host 172.12.123.1 eq telnet
R4(config)#access-list 103 permit tcp host 172.12.45.5 host 172.12.123.1 eq 3001

Next create your route-maps. F0/0 is connects R4 to R2, F2/0 connects R4 to R3:

route-map gotoR2
match ip address 102
set interface f0/0

route-map gotoR3
match ip address 103
set interface f2/0

Now create your NAT rules:

R4(config)#ip nat inside source route-map gotoR2 interface f0/0
R4(config)#ip nat inside source route-map gotoR3 interface f2/0

Let's head to R5 and do the telnet:

R5#telnet 172.12.123.1
Trying 172.12.123.1 ... Open


User Access Verification

Password:
R1>exit

Now check R4:

R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23

Perfect. Now let's head back to R5 and telnet to port 3001 (remember to set up a rotary line on R1's vty)

R5#telnet 172.12.123.1 3001
Trying 172.12.123.1, 3001 ... Open


User Access Verification

Password:
R1>

R4 we now see both translations. Notice the port numbers. Cisco calls these "fully extended" translation entries.

R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:16208 172.12.45.5:16208 172.12.123.1:23 172.12.123.1:23
tcp 172.12.34.4:29692 172.12.45.5:29692 172.12.123.1:3001 172.12.123.1:3001

Not too bad, eh? NAT is still pretty initmadating for me. I can get easy scenarios out of the way, but some examples such as this still have the potential to cause me trouble. Hopefully, by practicing and doing these scenarios without any help, I can get it down pat...pun intended :)

NAT - Port forwarding telnet

Here is the topology:

R1---->R3---->R4---->R5

R1 and R3 are on the 172.12.123.0/24 network.
R3 and R4 are on the 172.12.34.0/24 network.
R4 and R5 are on the 172.12.45.0/24 network.

The goal of this scenario is:

R1 uses R4's address and port 23 to telnet to R4
R1 uses R4's address and port 3001 to telnet to R5.
R1 does not have knowledge of R4-R5 network so NAT is necessary.
R5 uses R4 as default route.

When R1 enters "telnet 172.12.34.4" it should enter R4.
When R1 enters "telnet 172.12.34.4 3001" it should enter R5.

First set up R4 and R5 for vty access, remember to use rotary command on R5 to set up port 3001.

R4(config)#line vty 0 4
R4(config-line)#password cisco
R4(config-line)#login

R5(config)#line vty 5
R5(config-line)#rotary 1
R5(config-line)#password cisco
R5(config-line)#login

Also make R4's interface to R3 "ip nat outside", and R4's interface to R5 "ip nat inside."

On R4 we only need one more command now:

R4(config)#ip nat inside source static tcp 172.12.45.5 3001 172.12.34.4 3001

Now Let's try it:

R1#telnet 172.12.34.4
Trying 172.12.34.4 ... Open

User Access Verification

Password:
R4>

Perfect, we are in R4 now. Let's exit and try port 3001:

R1#telnet 172.12.34.4 3001
Trying 172.12.34.4, 3001 ... Open

User Access Verification

Password:
R5>

We are in R5 here. This was a lot easier than I thought :)

NAT - Redundancy with route-maps

Here is the topology:

R1 has a loopback 100.0.0.1
R4 has a connection R2 via interface f0/0
R4 has a connection R3 via interface f2/0

R5 uses R4 as its default gateway, R1 has no route back to this network, but R1 does have a route to R4. So R4 is where we NAT.

We want R5 to have reachability to R1 when either of the R4 uplinks are down. Here's how. First create an ACL to match the R5 network:

ip access-list standard VLAN45
permit 172.12.45.0 0.0.0.255

Next create 2 route-maps that match the interface that will be used for routing the packet outbound and the ACL:

route-map FE0 permit 10
match ip address VLAN45
match interface FastEthernet0/0

route-map FE2 permit 10
match ip address VLAN45
match interface FastEthernet2/0

Next we create our nat statements:

ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload

Remember to enable nat inside/outside on the proper interface of R4.

Let's try it from R5:

R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open


User Access Verification

Password:
R1>

Let's check translations on R4. Notice the current address being used for NAT is 172.12.24.4 which is R4's interface towards R2. This is the best route in the route table towards R1.

R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.24.4:64118 172.12.45.5:64118 100.0.0.1:23 100.0.0.1:23
R4#

Now let's shut the interface to R2 on R4:

R4(config)#int f0/0
R4(config-if)#shut
R4(config-if)#^Z
R4#show ip nat translations

R4#

Telnet again from R5:

R5#telnet 100.0.0.1
Trying 100.0.0.1 ... Open


User Access Verification

Password:

Check translations on R4. Now we are using R4's interface towards R3 for routing and address translation. This is the backup route for R4 towards R1.

R4#show ip nat translations
Pro Inside global Inside local Outside local Outside global
tcp 172.12.34.4:13668 172.12.45.5:13668 100.0.0.1:23 100.0.0.1:23
R4#

The key thing to remember with this configuration is that the route-map used in this example is used as the "source" in the NAT statement. As opposed to matching just an address list or a static IP we are matching an address list and the interface out of which the packet will be routed.

Without the "match interface" in the route-map, the router does not perform translation when using the backup interface. I think this is because if you did not have the "match interface", then whatever NAT statement appears first in your running-config would be used. In this case I have the following order of statements:

ip nat inside source route-map FE0 interface FastEthernet0/0 overload
ip nat inside source route-map FE2 interface FastEthernet2/0 overload

If I did not have a "match interface" in my route-maps, than when f0/0 went down, the router would still try to use the first rule for translation! It wouldn't care what interface was used for routing, it would just use the first route-map that matched all conditions, in this case the only condition would be the source address.