Network Address Translation (NAT)

In today’s techtorial we will be looking at a common way to utilize NAT in order to accomplish a given task we might be asked to do in the lab.  Take a look at the below diagram to get an idea of the topology.

We are going to be hacking away at some very specific tasks.

1. From R5, we should be able to telnet to 10.10.10.10 and get to a login prompt on R2
2. From R5, we should be able to telnet to 10.10.10.10:80 and get a login prompt on R4
3. If we telnet to 10.10.10.10 port 23 or port 80 from R1, R2, or R4 we should not have this behavior

*NOTE* You may add 1 interface and 1 ip address for this task. You may not use static routes.

Clearly the task is looking for a NAT solution. The question is, how do we go about doing this?  The first thing we need to be thinking about is the address 10.10.10.10.  We don’t have it in our topology at all.  However, we are allowed to add in a single interface and a single IP address.  A loopback sounds good to me.

R1(config)#int lo10
R1(config-if)#ip add 10.10.10.10 255.255.255.255

The next thing we need to start thinking about is how we are going to accomplish this task with NAT, and how NAT works.  We have already setup EIGRP on all the routers here.  We are advertising the 10.10.10.10/32 into EIGRP as well.  Without the advertisement R5 would of course have no idea how to get to 10.10.10.10 in the first place.  So let’s get into the NAT configuration

interface FastEthernet0/0
ip nat outside
interface FastEthernet0/1.12
ip nat inside
interface FastEthernet0/1.14
ip nat inside
ip nat inside source static tcp 100.100.12.2 23 10.10.10.10 23 extendable
ip nat inside source static tcp 100.100.14.4 23 10.10.10.10 80 extendable

So what’s the logic behind this?  This is the logic that confused me for a long time.  I mean, if I want to translate things DESTINED for 10.10.10.10 you might think to use an outside destination based NAT rule right? The problem is, no such thing exists in IOS…at least on a router.

R1(config)#ip nat outside ?
source  Source address translation

However, what we have to realize is that when we setup a NAT translation, we are actually setting up a bi-directional rule. So, let’s break down the first NAT translation.  We have ip nat outside on our interface facing R5 and we have ip nat inside on the interfaces facing R2 and R4.  OK.  Now take a look at the rule.

ip nat inside source static tcp 100.100.12.2 23 10.10.10.10 23 extendable

So what we are saying here is actually a couple of different things.  First, if we see a packet on an interface marked as “ip nat inside” with a SOURCE ip address of 100.100.12.2 with a SOURCE port of TCP 23, translate that to a SOURCE ip address of 10.10.10.10 with a SOURCE port of 23.  Fair enough.  The other more subtle rule is the reverse!!! We are also saying at the same time if anything comes into an interface marked as “ip nat outside” with a DESTINATION address of 10.10.10.10 DESTINATION port 23 translate that to a DESTINATION address of 100.100.12.2 with a DESTINATION port of 23.  This logic is part of the NAT rule inherently.  The same logic goes for the second rule, except we are using port 80 instead.  So check it out…

Before we do anything…

R1(config)#do sh ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
tcp 10.10.10.10:23     100.100.12.2:23    ---                ---
tcp 10.10.10.10:80     100.100.14.4:23    ---                ---

At this point we only see the inside global and inside local for each rule.  Since we have not translated anything yet, we don’t see anything on the outside side.  Inside global means “what is the address of my inside interface as viewed by the outside (global) domain?”  Inside local says “what is the address of my inside interface as viewed by the inside “local” domain?”  Outside local says “what is the address of my outside interface as viewed from the inside domain?” and finally Outside global says “what is the address of my outside interface as viewed by the outside (global) domain?”  Let’s get some telnet going from R5 to test…Note I have already setup a username of cisco password cisco on R2 and R4 and set the vty lines to login local. To see whats going on here, we will turn on debug ip nat on R1 as well

R1(config)#do debug ip nat
IP NAT debugging is on
R5>telnet 10.10.10.10
Trying 10.10.10.10 ... Open
User Access Verification
Username: cisco
Password:
R2>

Awesome! Our first test worked as planned.  On R1 we see the following part of the debug…

R1#
*Jul 22 08:41:45.307: NAT*: s=100.100.15.5, d=10.10.10.10->100.100.12.2 [43266]
*Jul 22 08:41:45.307: NAT*: s=100.100.12.2->10.10.10.10, d=100.100.15.5 [63913]

What we see here is that a packet came in sourced from 100.100.15.5 (R5 fa0/0) destined to 10.10.10.10.  Our router then translated the DESTINATION address to 100.100.12.2 (R2 Fa0/0).  On the way back, R2 sent data back to R5 sourced from 100.100.12.2 and destined to 100.100.15.5.  Because this matched the NAT rule, we translated the SOURCE address to 10.10.10.10. Let’s test our connection to R4 now.

R5>telnet 10.10.10.10 80
Trying 10.10.10.10, 80 ... Open
User Access Verification
Username: cisco
Password:
R4>exit

Beautiful!!!  Telnetting to 10.10.10.10 on port 80 fired us right over to R4 port 23 as expected.  And the debug from R1 shows…(drumroll please)

*Jul 22 08:48:56.175: NAT*: TCP s=38201, d=80->23
*Jul 22 08:48:56.175: NAT*: s=100.100.15.5, d=10.10.10.10->100.100.14.4 [38939]
*Jul 22 08:48:56.179: NAT*: TCP s=23->80, d=38201
*Jul 22 08:48:56.179: NAT*: s=100.100.14.4->10.10.10.10, d=100.100.15.5 [59816]

Here we see that as the packet came in to R1 from R5 it had a source TCP port of 38201 (telnet sources things from random TCP ports > 1024 typically) and a destination port of 80.  Our NAT rule translated the destination TCP port to 23.  Furthermore, we translated the destination address of 10.10.10.10 to 100.100.14.4.  Coming back the other way from R4 we see the destination port number was translated from 80 back to 38201 and the destination address was translated from 10.10.10.10 back to 100.100.15.5.

That’s it for this blog.  Until next time, keep studying hard and you will meet your goal!!!

Joe Astorino – CCIE #24347

Network Address Translation (NAT), 4.0 out of 5 based on 5 ratings

Tags: CCIE R&S, NAT